{"id":8196,"date":"2020-03-04T14:30:46","date_gmt":"2020-03-04T22:30:46","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=8196"},"modified":"2023-05-25T03:17:37","modified_gmt":"2023-05-25T10:17:37","slug":"part-2-n1ql-to-query-or-to-analyze","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/part-2-n1ql-to-query-or-to-analyze\/","title":{"rendered":"Parte 2: N1QL: \u00bfConsultar o analizar?"},"content":{"rendered":"

Cuando necesites consultar documentos usando SQL, hay dos opciones disponibles en Couchbase. La opci\u00f3n Servicio de consulta<\/a> y el Servicio de an\u00e1lisis<\/a>. Nuestro blog, N1QL: \u00bfConsultar o analizar?<\/a> ofrece una visi\u00f3n detallada de ambos servicios. Recomiendo encarecidamente leerlo antes de \u00e9ste. Este art\u00edculo pretende ampliar el blog anterior a\u00f1adiendo algunos ejemplos concretos y pr\u00e1cticos. Para cada ejemplo, explicaremos c\u00f3mo escribir la consulta en ambos servicios y veremos las diferencias de rendimiento. El objetivo es que los lectores se vayan con m\u00e1s conocimientos que les ayuden a identificar r\u00e1pidamente patrones y casos de uso que se ajusten mejor a cada servicio.<\/p>\n

Resumen<\/h3>\n

Antes de pasar a los ejemplos. Vamos a refrescarnos las caracter\u00edsticas clave de alto nivel de los dos servicios.<\/p>\n\n\n\n\n\n\n
\n
Servicio de consulta<\/b><\/h5>\n<\/td>\n
\n
Servicio de an\u00e1lisis<\/b><\/h5>\n<\/td>\n<\/tr>\n
Se utiliza para la manipulaci\u00f3n de datos dentro de la l\u00f3gica de la aplicaci\u00f3n.<\/td>\nSe utiliza para informes, an\u00e1lisis (hist\u00f3ricos, interactivos) y cuadros de mando.<\/td>\n<\/tr>\n
M\u00e1s eficaz para consultas cortas y operativas que recuperan o manipulan peque\u00f1as cantidades de datos.<\/td>\nM\u00e1s eficaz para consultas ad hoc m\u00e1s largas y complejas que suelen recuperar y procesar grandes cantidades de datos.<\/td>\n<\/tr>\n
Admite operaciones SELECT, INSERT, UPDATE, DELETE y MERGE.<\/td>\nS\u00f3lo admite operaciones SELECT.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

V\u00e9ase https:\/\/www.couchbase.com\/blog\/n1ql-to-query-or-to-analyze\/<\/a> para ver una tabla completa.<\/em><\/p>\n

Configurar<\/h3>\n

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\u00e1s configuraciones son las predeterminadas. Si no tienes acceso a un cluster, puedes ejecutar r\u00e1pidamente Couchbase 6.5 en un contenedor Docker ejecutando el siguiente comando:<\/p>\n

docker run -d --name db -p 8091-8096:8091-8096 -p 11210-11211:11210-11211 couchbase:enterprise-6.5.0<\/pre>\n
Si vas por la ruta Docker, ve a https:\/\/localhost:8091 en tu navegador despu\u00e9s 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.<\/p>\n
Descargo de responsabilidad<\/h5>\n
Veremos los tiempos de respuesta para los ejemplos que siguen. Es importante tener en cuenta que tu rendimiento puede variar mucho dependiendo de c\u00f3mo est\u00e9 configurado tu entorno Couchbase. Sin embargo, deber\u00edas poder observar diferencias similares entre los servicios Query y Analytics independientemente de tu entorno.<\/p>\n
Instalar el cubo de muestras de viaje<\/h4>\n
En el panel de administraci\u00f3n de Couchbase, vaya a Configuraci\u00f3n -> Cubos de muestra. Instale el bucket de ejemplo de viajes. La documentaci\u00f3n detallada sobre c\u00f3mo hacerlo se puede encontrar en nuestro sitio de documentaci\u00f3n<\/a>.<\/p>\n
Configuraci\u00f3n del servicio de consulta<\/h4>\n
Al instalar el Cubo de muestra tambi\u00e9n se crean los \u00edndices necesarios. Esto significa que no se necesita ninguna configuraci\u00f3n adicional para el Servicio de consulta.<\/p>\n
Configuraci\u00f3n del servicio Analytics<\/h4>\n
Para el servicio de an\u00e1lisis, necesitamos rellenar conjuntos de datos para cada \"tipo\" de documento de nuestro bucket. Vaya a Analytics Workbench (https:\/\/localhost:8091\/ui\/index.html#!\/cbas\/workbench) y ejecute las siguientes consultas para crear los conjuntos de datos:<\/p>\n
CREATE DATASET routes ON `travel-sample` WHERE `type` = \"route\";\r\nCREATE DATASET landmarks ON `travel-sample` WHERE `type` = \"landmark\";\r\nCREATE DATASET hotels ON `travel-sample` WHERE `type` = \"hotel\";\r\nCREATE DATASET airlines ON `travel-sample` WHERE `type` = \"airline\";\r\nCREATE DATASET airports ON `travel-sample` WHERE `type` = \"airport\";\r\nCONNECT LINK Local;<\/pre>\n
Esto crear\u00e1 conjuntos de datos para rutas, puntos de referencia, hoteles, aerol\u00edneas y aeropuertos utilizando el bucket travel-sample. Por \u00faltimo, la ejecuci\u00f3n de la sentencia CONNECT comenzar\u00e1 a rellenar cada uno de los conjuntos de datos.<\/p>\n
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\u00e1gina N1QL para An\u00e1lisis vs. N1QL para Consultas<\/a> p\u00e1gina de referencia en nuestros documentos.<\/p>\n
Caso pr\u00e1ctico: Obtener todas las rutas de LAX a SFO<\/h3>\n
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.<\/p>\n
\u00bfQu\u00e9 servicio es mejor?<\/h5>\n
Se trata en definitiva de una consulta operativa que devolver\u00e1 una cantidad limitada de datos. Es una consulta simple que no realiza agregaciones ni funciones complejas sobre nuestros datos. S\u00f3lo hay un filtro simple sobre el origen y el destino. Por lo tanto, el Servicio de Consultas (https:\/\/localhost:8091\/ui\/index.html#!\/query\/workbench) es la elecci\u00f3n obvia.<\/p>\n
select * from `travel-sample`\r\nwhere type = \"route\"\r\nand sourceairport = \"LAX\"\r\nand destinationairport = \"SFO\"<\/pre>\n
Rendimiento:<\/strong>\u00a0 4 milisegundos<\/p>\n
Esta es una consulta simple y tambi\u00e9n devuelve s\u00f3lo 7 documentos. Esta es una consulta operativa t\u00edpica que una aplicaci\u00f3n podr\u00eda enviar a Couchbase. El rendimiento es fiable, r\u00e1pido y consistente.<\/p>\n
Servicio de An\u00e1lisis Equivalente<\/strong><\/h5>\n
Hagamos la misma consulta para el servicio Analytics a modo de demostraci\u00f3n. El servicio Analytics es excesivo para una consulta sencilla como \u00e9sta. Por lo tanto, si estuvi\u00e9ramos creando una aplicaci\u00f3n para este caso de uso, no elegir\u00edamos el servicio Analytics. Esperar\u00edamos que su rendimiento fuera inferior al del servicio de consultas.<\/p>\n
select * from routes\r\nwhere sourceairport = \"LAX\"\r\nand destinationairport = \"SFO\"<\/pre>\n
Rendimiento:<\/strong> ~36 milisegundos<\/p>\n
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\u00edamos que el servicio de consulta funcionara incluso mejor que la diferencia de m\u00e1s de 30 milisegundos que muestra esta sencilla prueba.<\/p>\n
Caso pr\u00e1ctico: Las ciudades con m\u00e1s hoteles<\/h3>\n
\u00bfQu\u00e9 servicio es mejor?<\/h5>\n
Para este caso de uso, queremos averiguar el n\u00famero de hoteles disponibles en cada ciudad y ordenar los resultados por las ciudades con m\u00e1s hoteles en primer lugar. Para ello, tendremos que escanear todos nuestros hoteles y recopilar los recuentos por pa\u00eds y ciudad y, a continuaci\u00f3n, ordenarlos. Siguiendo la l\u00f3gica que expusimos al principio, el Servicio de An\u00e1lisis (https:\/\/localhost:8091\/ui\/index.html#!\/cbas\/workbench) deber\u00eda funcionar mejor para este caso de uso. Pongamos a prueba esta teor\u00eda.<\/p>\n
select \r\n  country, \r\n  city, \r\n  count(id) \r\nfrom hotels \r\ngroup by country, city\r\norder by count(id) desc<\/pre>\n
Rendimiento:<\/strong> ~36 milisegundos<\/p>\n
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\u00e1s sencilla y peque\u00f1a 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\u00e1s compleja que nuestro primer ejemplo, sigue siendo relativamente sencilla para el servicio Analytics.<\/p>\n
Servicio de consulta equivalente<\/h5>\n
Hagamos la misma consulta para el servicio de consulta. En teor\u00eda, se trata de una consulta m\u00e1s pesada que la del ejemplo anterior. Tambi\u00e9n procesa y devuelve muchos m\u00e1s datos que el primer ejemplo. Es de esperar que el servicio de consulta no funcione tan bien como el servicio de an\u00e1lisis.<\/p>\n
select \r\n  country, \r\n  city, \r\n  count(id)\r\nfrom `travel-sample`\r\nwhere type = \"hotel\"\r\ngroup by country, city\r\norder by count(id) desc<\/pre>\n
Rendimiento:<\/strong> ~90 milisegundos<\/p>\n
Aqu\u00ed tenemos una divergencia realmente grande en el rendimiento. Como era de esperar, el servicio Analytics es capaz de procesar la consulta 2 veces m\u00e1s r\u00e1pido de media que el servicio Query.<\/p>\n
Caso pr\u00e1ctico: Obtener las aerol\u00edneas con m\u00e1s rutas<\/h3>\n
\u00bfQu\u00e9 servicio es mejor?<\/h5>\n
Esta consulta plantea una pregunta similar a la de nuestro ejemplo anterior. Sin embargo, en este caso necesitaremos una uni\u00f3n, ya que los datos de las l\u00edneas a\u00e9reas residen en un tipo de documento distinto de los datos de las rutas. Esperamos que Servicio de an\u00e1lisis<\/strong> funcione mejor con esta consulta porque est\u00e1 haciendo una agregaci\u00f3n y un JOIN.<\/p>\n
select a.id,\r\n  a.callsign,\r\n  a.name,\r\n  a.country,\r\n  count(r.id) as route_count\r\nfrom airlines a\r\njoin routes r on CONCAT(\"airline_\", to_string(a.id)) = r.airlineid\r\ngroup by a.id, a.callsign, a.name, a.country\r\norder by route_count desc\r\nlimit 100<\/pre>\n
Rendimiento: <\/strong>82 milisegundos<\/p>\n
Aqu\u00ed podemos ver que esta consulta est\u00e1 empezando a presionar el servicio de Analytics un poco. Nuestra primera consulta Analytics tom\u00f3 36 milisegundos en promedio y \u00e9ste est\u00e1 empujando hasta 82 milisegundos. La principal diferencia con esta consulta es la adici\u00f3n de un JOIN.<\/p>\n
Servicio de consulta equivalente<\/h5>\n
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\u00ed 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\u00e1lisis. 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\u00f1\u00eda a\u00e9rea\" con documentos de tipo = \"ruta\". Para ello necesitamos una subconsulta.<\/p>\n
select a.id,\r\n  a.callsign,\r\n  a.name,\r\n  a.country,\r\n  count(r.id) as route_count\r\nfrom `travel-sample` a\r\njoin (select id, airlineid from `travel-sample` where type = \"route\") r on CONCAT(\"airline_\", to_string(a.id)) = r.airlineid\r\nwhere a.type = \"airline\"\r\ngroup by a.id, a.callsign, a.name, a.country\r\norder by route_count desc\r\nlimit 100<\/pre>\n
Rendimiento:<\/strong> 2 segundos<\/p>\n
El rendimiento del Servicio de An\u00e1lisis es dr\u00e1sticamente mejor para este caso de uso debido al JOIN. Otra ventaja a\u00f1adida del servicio Analytics para este caso es que la escritura del JOIN es m\u00e1s sencilla, ya que no necesitamos crear una subconsulta contra la que unir.<\/p>\n
Caso pr\u00e1ctico: Obtener el rango percentil de las aerol\u00edneas con m\u00e1s rutas<\/h3>\n
\u00bfQu\u00e9 servicio es mejor?<\/h5>\n
Este ejemplo se basa en el anterior a\u00f1adiendo el rango percentil de los recuentos de rutas. Esperamos que el rendimiento sea mejor con Anal\u00edtica<\/strong> ya que estamos a\u00f1adiendo a\u00fan m\u00e1s complejidad y c\u00e1lculo a la consulta. Veamos qu\u00e9 impacto tiene a\u00f1adir una funci\u00f3n Ventana a nuestra consulta.<\/p>\n
select\r\n  a.id,\r\n  a.callsign,\r\n  a.name,\r\n  a.country,\r\n  count(r.id) as route_count,\r\n  PERCENT_RANK() OVER (\r\n   ORDER BY count(r.id)\r\n   ) AS `rank`\r\nfrom airlines a\r\njoin routes r on CONCAT(\"airline_\", to_string(a.id)) = r.airlineid\r\ngroup by a.id, a.callsign, a.name, a.country\r\norder by route_count desc\r\nlimit 100<\/pre>\n
Rendimiento:<\/strong> 85 milisegundos<\/p>\n
La adici\u00f3n de una funci\u00f3n Ventana no supuso ning\u00fan esfuerzo para el servicio Analytics, ya que apenas se aprecia una diferencia de rendimiento.<\/h5>\n
Servicio de consulta equivalente<\/h5>\n
select\r\n  a.id,\r\n  a.callsign,\r\n  a.name,\r\n  a.country,\r\n  count(r.id) as route_count,\r\n  PERCENT_RANK() OVER ( ORDER BY count(r.id) ) AS `rank`\r\nfrom `travel-sample` a\r\njoin (select id, airlineid from `travel-sample` where type = \"route\") r on CONCAT(\"airline_\", to_string(a.id)) = r.airlineid\r\nwhere a.type = 'airline'\r\ngroup by a.id, a.callsign, a.name, a.country order by route_count desc\r\nlimit 100<\/pre>\n
Rendimiento:<\/strong> 2 segundos<\/p>\n
Cuando a\u00f1adimos la funci\u00f3n Window a nuestra consulta del servicio Query, tampoco podemos detectar un impacto en el rendimiento. La principal conclusi\u00f3n que podemos extraer de estos resultados es que el JOIN es el factor de rendimiento m\u00e1s importante y la agregaci\u00f3n (COUNT en este caso) es el segundo m\u00e1s importante.<\/p>\n
Conclusi\u00f3n<\/h3>\n
Esperamos que este art\u00edculo te haya ayudado a entender mejor las dos opciones de SQL en Couchbase y cu\u00e1ndo aplicarlas. Aseg\u00farate de consultar los siguientes recursos sobre Query y Analytics.<\/p>\n