Cuando necesites consultar documentos usando SQL, hay dos opciones disponibles en Couchbase. La opción Servicio de consulta y el Servicio de análisis. Nuestro blog, N1QL: ¿Consultar o analizar? ofrece una visión detallada de ambos servicios. Recomiendo encarecidamente leerlo antes de éste. Este artículo pretende ampliar el blog anterior añadiendo algunos ejemplos concretos y prácticos. Para cada ejemplo, explicaremos cómo escribir la consulta en ambos servicios y veremos las diferencias de rendimiento. El objetivo es que los lectores se vayan con más conocimientos que les ayuden a identificar rápidamente patrones y casos de uso que se ajusten mejor a cada servicio.
Resumen
Antes de pasar a los ejemplos. Vamos a refrescarnos las características clave de alto nivel de los dos servicios.
Servicio de consulta |
Servicio de análisis |
| Se utiliza para la manipulación de datos dentro de la lógica de la aplicación. | Se utiliza para informes, análisis (históricos, interactivos) y cuadros de mando. |
| Más eficaz para consultas cortas y operativas que recuperan o manipulan pequeñas cantidades de datos. | Más eficaz para consultas ad hoc más largas y complejas que suelen recuperar y procesar grandes cantidades de datos. |
| Admite operaciones SELECT, INSERT, UPDATE, DELETE y MERGE. | Sólo admite operaciones SELECT. |
Véase https://www.couchbase.com/blog/n1ql-to-query-or-to-analyze/ para ver una tabla completa.
Configurar
Para este tutorial usaremos Couchbase 6.5 y los datos de ejemplo proporcionados en el Admin UI de Couchbase. Mi entorno es un cluster de 3 nodos Couchbase 6.5 con 1536 MB asignados al servicio Analytics. Todas las demás configuraciones son las predeterminadas. Si no tienes acceso a un cluster, puedes ejecutar rápidamente Couchbase 6.5 en un contenedor Docker ejecutando el siguiente comando:
|
1 |
docker ejecute -d --nombre db -p 8091-8096:8091-8096 -p 11210-11211:11210-11211 couchbase:empresa-6.5.0 |
Si vas por la ruta Docker, ve a http://localhost:8091 en tu navegador después de que el contenedor arranque y configura tu instancia de Couchbase usando las opciones por defecto en cada paso. No importa el nombre que le des a tu instancia de Couchbase.
Descargo de responsabilidad
Veremos los tiempos de respuesta para los ejemplos que siguen. Es importante tener en cuenta que tu rendimiento puede variar mucho dependiendo de cómo esté configurado tu entorno Couchbase. Sin embargo, deberías poder observar diferencias similares entre los servicios Query y Analytics independientemente de tu entorno.
Instalar el cubo de muestras de viaje
En el panel de administración de Couchbase, vaya a Configuración -> Cubos de muestra. Instale el bucket de ejemplo de viajes. La documentación detallada sobre cómo hacerlo se puede encontrar en nuestro sitio de documentación.
Configuración del servicio de consulta
Al instalar el Cubo de muestra también se crean los índices necesarios. Esto significa que no se necesita ninguna configuración adicional para el Servicio de consulta.
Configuración del servicio Analytics
Para el servicio de análisis, necesitamos rellenar conjuntos de datos para cada "tipo" de documento de nuestro bucket. Vaya a Analytics Workbench (http://localhost:8091/ui/index.html#!/cbas/workbench) y ejecute las siguientes consultas para crear los conjuntos de datos:
|
1 2 3 4 5 6 |
CREAR DATASET rutas EN `viaje-muestra` DONDE `tipo` = "ruta"; CREAR DATASET hitos EN `viaje-muestra` DONDE `tipo` = "hito"; CREAR DATASET hoteles EN `viaje-muestra` DONDE `tipo` = "hotel"; CREAR DATASET líneas aéreas EN `viaje-muestra` DONDE `tipo` = "aerolínea"; CREAR DATASET aeropuertos EN `viaje-muestra` DONDE `tipo` = "aeropuerto"; CONECTAR ENLACE Local; |
Esto creará conjuntos de datos para rutas, puntos de referencia, hoteles, aerolíneas y aeropuertos utilizando el bucket travel-sample. Por último, la ejecución de la sentencia CONNECT comenzará a rellenar cada uno de los conjuntos de datos.
En los ejemplos que siguen, utilizaremos consultas N1QL simples. Para un desglose detallado de las diferencias de lenguaje N1QL entre Query y Analytics, consulte la página N1QL para Análisis vs. N1QL para Consultas página de referencia en nuestros documentos.
Caso práctico: Obtener todas las rutas de LAX a SFO
Ahora estamos listos para escribir nuestra primera consulta. Para este caso de uso, queremos encontrar todas las rutas disponibles para un aeropuerto de origen y destino determinados.
¿Qué servicio es mejor?
Se trata en definitiva de una consulta operativa que devolverá una cantidad limitada de datos. Es una consulta simple que no realiza agregaciones ni funciones complejas sobre nuestros datos. Sólo hay un filtro simple sobre el origen y el destino. Por lo tanto, el Servicio de Consultas (http://localhost:8091/ui/index.html#!/query/workbench) es la elección obvia.
|
1 2 3 4 |
seleccionar * de `viaje-muestra` donde tipo = "ruta" y fuenteaeropuerto = "LAX" y destinoaeropuerto = "OFS" |
Rendimiento: 4 milisegundos
Esta es una consulta simple y también devuelve sólo 7 documentos. Esta es una consulta operativa típica que una aplicación podría enviar a Couchbase. El rendimiento es fiable, rápido y consistente.
Servicio de Análisis Equivalente
Hagamos la misma consulta para el servicio Analytics a modo de demostración. El servicio Analytics es excesivo para una consulta sencilla como ésta. Por lo tanto, si estuviéramos creando una aplicación para este caso de uso, no elegiríamos el servicio Analytics. Esperaríamos que su rendimiento fuera inferior al del servicio de consultas.
|
1 2 3 |
seleccionar * de rutas donde fuenteaeropuerto = "LAX" y destinoaeropuerto = "OFS" |
Rendimiento: ~36 milisegundos
Como se puede ver en este ejemplo. El servicio de consulta es el que mejor funciona en este caso de uso, como era de esperar. Bajo una carga pesada, esperaríamos que el servicio de consulta funcionara incluso mejor que la diferencia de más de 30 milisegundos que muestra esta sencilla prueba.
Caso práctico: Las ciudades con más hoteles
¿Qué servicio es mejor?
Para este caso de uso, queremos averiguar el número de hoteles disponibles en cada ciudad y ordenar los resultados por las ciudades con más hoteles en primer lugar. Para ello, tendremos que escanear todos nuestros hoteles y recopilar los recuentos por país y ciudad y, a continuación, ordenarlos. Siguiendo la lógica que expusimos al principio, el Servicio de Análisis (http://localhost:8091/ui/index.html#!/cbas/workbench) debería funcionar mejor para este caso de uso. Pongamos a prueba esta teoría.
|
1 2 3 4 5 6 7 |
seleccione país, ciudad, cuente(id) de hoteles grupo por país, ciudad pedir por cuente(id) desc |
Rendimiento: ~36 milisegundos
Curiosamente, el rendimiento de esta consulta es casi el mismo que el de nuestro ejemplo anterior de Analytics (36 ms), a pesar de que la consulta anterior era mucho más sencilla y pequeña desde el punto de vista computacional. Esto nos indica que el rendimiento de referencia en mi entorno de 3 nodos puede estar en torno a los 36 milisegundos para las consultas de Analytics. Aunque esta consulta es más compleja que nuestro primer ejemplo, sigue siendo relativamente sencilla para el servicio Analytics.
Servicio de consulta equivalente
Hagamos la misma consulta para el servicio de consulta. En teoría, se trata de una consulta más pesada que la del ejemplo anterior. También procesa y devuelve muchos más datos que el primer ejemplo. Es de esperar que el servicio de consulta no funcione tan bien como el servicio de análisis.
|
1 2 3 4 5 6 7 8 |
seleccione país, ciudad, cuente(id) de `viaje-muestra` donde tipo = "hotel" grupo por país, ciudad pedir por cuente(id) desc |
Rendimiento: ~90 milisegundos
Aquí tenemos una divergencia realmente grande en el rendimiento. Como era de esperar, el servicio Analytics es capaz de procesar la consulta 2 veces más rápido de media que el servicio Query.
Caso práctico: Obtener las aerolíneas con más rutas
¿Qué servicio es mejor?
Esta consulta plantea una pregunta similar a la de nuestro ejemplo anterior. Sin embargo, en este caso necesitaremos una unión, ya que los datos de las líneas aéreas residen en un tipo de documento distinto de los datos de las rutas. Esperamos que Servicio de análisis funcione mejor con esta consulta porque está haciendo una agregación y un JOIN.
|
1 2 3 4 5 6 7 8 9 10 |
seleccione a.id, a.Indicativo, a.nombre, a.país, cuente(r.id) como recuento_de_rutas de líneas aéreas a únase a rutas r en CONCAT("aerolínea_", to_string(a.id)) = r.airlineid grupo por a.id, a.Indicativo, a.nombre, a.país pedir por recuento_de_rutas desc límite 100 |
Rendimiento: 82 milisegundos
Aquí podemos ver que esta consulta está empezando a presionar el servicio de Analytics un poco. Nuestra primera consulta Analytics tomó 36 milisegundos en promedio y éste está empujando hasta 82 milisegundos. La principal diferencia con esta consulta es la adición de un JOIN.
Servicio de consulta equivalente
Recuerde que al principio creamos "Conjuntos de datos" de Analytics independientes para cada tipo de documento de los datos de la muestra de viajes. Cada conjunto de datos funciona como su propia tabla. Así que unirlos en una consulta es sencillo si alguna vez ha escrito uniones SQL. El servicio de consulta no tiene el mismo concepto de "conjunto de datos" que el servicio de análisis. Por lo tanto, tenemos que escribir la consulta de forma un poco diferente para tener en cuenta todos los datos que residen en el mismo bucket. Tenemos que unir documentos de tipo = "compañía aérea" con documentos de tipo = "ruta". Para ello necesitamos una subconsulta.
|
1 2 3 4 5 6 7 8 9 10 11 |
seleccione a.id, a.Indicativo, a.nombre, a.país, cuente(r.id) como recuento_de_rutas de `viaje-muestra` a únase a (seleccione id, airlineid de `viaje-muestra` donde tipo = "ruta") r en CONCAT("aerolínea_", to_string(a.id)) = r.airlineid donde a.tipo = "aerolínea" grupo por a.id, a.Indicativo, a.nombre, a.país pedir por recuento_de_rutas desc límite 100 |
Rendimiento: 2 segundos
El rendimiento del Servicio de Análisis es drásticamente mejor para este caso de uso debido al JOIN. Otra ventaja añadida del servicio Analytics para este caso es que la escritura del JOIN es más sencilla, ya que no necesitamos crear una subconsulta contra la que unir.
Caso práctico: Obtener el rango percentil de las aerolíneas con más rutas
¿Qué servicio es mejor?
Este ejemplo se basa en el anterior añadiendo el rango percentil de los recuentos de rutas. Esperamos que el rendimiento sea mejor con Analítica ya que estamos añadiendo aún más complejidad y cálculo a la consulta. Veamos qué impacto tiene añadir una función Ventana a nuestra consulta.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
seleccione a.id, a.Indicativo, a.nombre, a.país, cuente(r.id) como recuento_de_rutas, RANGO_PORCENTAJE() EN ( PEDIR POR cuente(r.id) ) AS `rango` de líneas aéreas a únase a rutas r en CONCAT("aerolínea_", to_string(a.id)) = r.airlineid grupo por a.id, a.Indicativo, a.nombre, a.país pedir por recuento_de_rutas desc límite 100 |
Rendimiento: 85 milisegundos
La adición de una función Ventana no supuso ningún esfuerzo para el servicio Analytics, ya que apenas se aprecia una diferencia de rendimiento.
Servicio de consulta equivalente
|
1 2 3 4 5 6 7 8 9 10 11 12 |
seleccione a.id, a.Indicativo, a.nombre, a.país, cuente(r.id) como recuento_de_rutas, RANGO_PORCENTAJE() EN ( PEDIR POR cuente(r.id) ) AS `rango` de `viaje-muestra` a únase a (seleccione id, airlineid de `viaje-muestra` donde tipo = "ruta") r en CONCAT("aerolínea_", to_string(a.id)) = r.airlineid donde a.tipo = aerolínea grupo por a.id, a.Indicativo, a.nombre, a.país pedir por recuento_de_rutas desc límite 100 |
Rendimiento: 2 segundos
Cuando añadimos la función Window a nuestra consulta del servicio Query, tampoco podemos detectar un impacto en el rendimiento. La principal conclusión que podemos extraer de estos resultados es que el JOIN es el factor de rendimiento más importante y la agregación (COUNT en este caso) es el segundo más importante.
Conclusión
Esperamos que este artículo te haya ayudado a entender mejor las dos opciones de SQL en Couchbase y cuándo aplicarlas. Asegúrate de consultar los siguientes recursos sobre Query y Analytics.
- Blog: N1QL: ¿Consultar o analizar?
- Referencia lingüística: N1QL para Análisis vs. N1QL para Consultas
- Documentación: Introducción al análisis
- Documentación: Fundamentos de la consulta
