Couchbase Analytics está diseñado para soportar consultas ad hoc aprovechando un eficiente procesamiento paralelo. Esto es especialmente útil cuando los resultados de una consulta te llevan a buscar respuestas en otra consulta. (Para los analistas, en otras palabras, ¡todo el tiempo!) Como ocurre con cualquier plataforma de datos, estas consultas secundarias a veces pueden dar lugar a tiempos de ejecución significativamente distintos de los de la primera. Recientemente hemos trabajado con un cliente que observó una notable disminución del rendimiento tras realizar un pequeño cambio en su consulta. A continuación se describe el proceso que seguimos para aislar y resolver el problema.
Los datos
Como siempre, el primer paso para entender una consulta es familiarizarse con los datos subyacentes. En este caso, los datos se componen de documentos JSON, cada uno de los cuales es una descripción de los cargos por servicios de los clientes. Los cargos de cada sesión se incluyen en una matriz:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
{ "cliente": 1000002, "dtype": "sesión", "sessionCharges": [ { "cantidad": 1, "revCode": "B", "svc": 44284, "amt": 40, "svcDate": 1592889276 }, { "cantidad": 1, "revCode": "A", "svc": 28078, "amt": 24, "svcDate": 1592891076 }, { "cantidad": 1, "revCode": "B", "svc": 38968, "amt": 26, "svcDate": 1592893416 } ] } |
Un par de notas sobre el diseño del modelo de datos:
- Los nombres de campo son lo bastante largos para ser descriptivos, pero lo bastante cortos para ahorrar espacio. Los nombres de campo de la matriz podrían haberse escrito fácilmente como "quantity", "revenueCode", "service", "amount", "serviceDate". Sin embargo, para 100 millones de instancias se habrían necesitado 3,73 GB de espacio adicional antes de la compresión.
- Utilizaban fechas de época, sin milisegundos. Si estas fechas se almacenaran en formato ISO 8601 ("2020-07- 24T18:17:49" o con milisegundos "2020-07-24T18:17:49.000") requerirían el doble de espacio de almacenamiento.
Consulta inicial
La consulta inicial se diseñó para recuperar la combinación cliente/servicio con mayores ingresos dentro de cada una de las categorías de códigos de ingresos:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
seleccione latestService, cliente, revCode, servicio, redondo(totalDollar) dólares, totalQuant de ( seleccione s.cliente, c.svc como servicio, c.revCode, suma(c.amt) como totalDollar, suma(c.Cantidad) como totalQuant, milis_to_str(max(c.svcDate)*1000, '1111-11-11') como latestService de sesiones s sin anestesia s.sessionCharges c grupo por s.cliente, c.revCode, c.svc ) a donde rango() en (partición por revCode pedir por totalDollar desc) = 1 pedir por revCode, totalDollar; |
Algunas notas sobre el diseño de la consulta:
- Se accede al contenido de la matriz mediante el verbo "unnest". Esto permite agregar los valores y devolverlos como un registro aplanado.
- La última fecha de servicio se convierte de época a fecha legible por humanos mediante la función millis_to_str().
- La función de ventana "rank() over partition" se utiliza en la cláusula where de la consulta externa como medio eficaz de devolver sólo el valor superior dentro de cada código de ingresos.
- La función round() es cosmética, pero se utiliza habitualmente en informes en los que los céntimos no son significativos.
La desaceleración
Surgieron problemas cuando se añadió un cálculo de descuento por volumen (20% de descuento cuando la cantidad acumulada de un servicio es igual o superior a 10). Esta nueva consulta tardaba seis veces más en ejecutarse.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
seleccione latestService, cliente, revCode, servicio, redondo(totalDollar) dólares, redondo(adjDollar) dólaresAdj, totalQuant de ( seleccione s.cliente, c.svc como servicio, c.revCode, suma(c.amt) como totalDollar, caso cuando suma(c.Cantidad) < 10 entonces suma(c.amt) si no suma(c.amt) * .8 fin como adjDollar, suma(c.Cantidad) como totalQuant, milis_to_str(max(c.svcDate)*1000, '1111-11-11') como latestService de sesiones s sin anestesia s.sessionCharges c grupo por s.cliente, c.svc, c.revCode ) a donde rango() en (partición por revCode pedir por totalDollar desc) = 1 pedir por revCode, totalDollar; |
¿Cómo podemos averiguar la causa?
Explícate
La consola de consulta Analytics facilita la inspección del plan de ejecución de cualquier consulta, simplemente haciendo clic en el botón "Plan". La figura (1) muestra el plan de ejecución de esta consulta. No se preocupe por la minúscula escala del diagrama; puede utilizar los controles para ampliarlo y contraerlo. También puede hacer clic en cada paso individual para obtener información detallada.
Figura 1
Si lo prefiere, también puede hacer clic en el botón "Texto del plan" para generar un documento JSON que describa el plan:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
{ "operador": "distribuir-resultado", "expresiones": [ "$$157" ], "operatorId": "1.1", "operador-físico": "DISTRIBUIR_RESULTADO", "modo de ejecución": "PARTICIONADO", "entradas": [ { "operador": "intercambio", "operatorId": "1.2", "operador-físico": "INTERCAMBIO_UNO_A_UNO", "modo de ejecución": "PARTICIONADO", "entradas": [ { "operador": "proyecto", "variables": [ "$$157" ], "operatorId": "1.3", "operador-físico": "STREAM_PROJECT", "modo de ejecución": "PARTICIONADO", "entradas": [ { "operador": "asignar", "variables": [ "$$157" ], ... etc. |
A medida que las consultas se hacen más complejas, el anidamiento puede llegar a ser muy profundo (y algo difícil de leer). Un truco que utilizan a menudo nuestros ingenieros es anteponer el comando "explicar texto" a la consulta:
|
1 2 3 |
explique texto seleccione ... etc.; |
Esto proporciona una descripción detallada del plan sin los paréntesis garabateados:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
distribuya resultado [$$157] -- DISTRIBUIR_RESULTADO |PARTICIONADO| intercambiar -- INTERCAMBIO_DE_UNO_A_UNO |PARTICIONADO| proyecto ([$$157]) -- STREAM_PROJECT |PARTICIONADO| asignar [$$157] <- [{"latestService": millis-a-local(numérico-multiplicar($$168, 1000), "1111-11-11"), "cliente": $$cliente, "revCode": $$revCode, "servicio": $$svc, "dólares": redondo($$166), "dollarsAdj": redondo($$126), "totalQuant": $$167}] -- ASIGNAR |PARTICIONADO| intercambiar -- SORT_MERGE_INTERCAMBIO [$$revCode(ASC), $$166(ASC) ] |PARTICIONADO| pedir (ASC, $$revCode) (ASC, $$166) -- ESTABLE_ORDENAR [$$revCode(ASC), $$166(ASC)] |PARTICIONADO| intercambiar -- INTERCAMBIO_DE_UNO_A_UNO |PARTICIONADO| etc. |
Esto es lo que utilizaremos para buscar pistas.
Hagamos una lista
Estamos bastante seguros de que la ralentización se introdujo cuando añadimos la sentencia CASE que define el campo adjDollars, así que empecemos buscando la lógica case. La encontramos en la línea 33:
|
1 |
asignar [$$125] <- [interruptor-caso(TRUE, lt($$165, 10), $$117, $$124)] |
A medida que seguimos la lógica en las líneas siguientes, vemos que el plan de ejecución continúa asignando e intercambiando variables de forma particionada. En la línea 44, sin embargo, vemos lo siguiente:
|
1 |
agregado [$$117] <- [listify($$196)] |
En los casos en los que el rendimiento de la consulta o el consumo de memoria son una preocupación, la función "listify" puede ser una señal de alarma. (Tiene su utilidad, sobre todo en la transformación interna de agregados de matrices, pero también puede ser utilizada por el plan de ejecución como función de último recurso. En nuestro caso, vemos que la variable $$117 es el resultado de este proceso de listificación. Este $$117, podemos verlo en el switch-case anterior, está asociado al objeto sum(c.amt) de la consulta. Así que vamos a intentar mover el cálculo de las sumas fuera del caso switch interior y hacerlas parte de un LET:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
explique texto seleccione latestService, cliente, revCode, servicio, redondo(totalDollar) dólares, redondo(adjDollar) dólaresAdj, totalQuant de ( seleccione s.cliente, c.svc como servicio, c.revCode, totalDollar, caso cuando totalQuant < 10 entonces totalDollar si no totalDollar * .8 fin como adjDollar, totalQuant, milis_to_str(max(c.svcDate)*1000, '1111-11-11') como latestService de sesiones s sin anestesia s.sessionCharges c grupo por s.cliente, c.svc, c.revCode deje totalQuant = suma(c.Cantidad), totalDollar = suma(c.amt) ) a donde rango() en (partición por revCode pedir por totalDollar desc) = 1 pedir por revCode, totalDollar; |
Una vez hecho esto y reexaminado el plan de explicación, vemos que su longitud se ha reducido a la mitad, y que el proceso de ejecución ya no incluye las funciones listify. La ejecución de la consulta, por tanto, debería mostrar un rendimiento mucho mejor, como de hecho ocurre. Problema resuelto.
Una nota final: nuestros ingenieros siempre están buscando formas de mejorar nuestro optimizador de consultas. Si en el curso de la optimización de una de sus consultas encuentra en el texto explicativo una función "listify" maliciosa (lo que ya es raro, y cada vez más raro), por favor, abra un ticket de soporte en support.couchbase.com, subiendo su plan explicativo para que puedan echarle un vistazo. De hecho, directamente como resultado de su trabajo con el cliente mencionado anteriormente, este ejemplo en particular (switch-case utilizado con una función agregada) será, a partir de la versión 6.6 de Couchbase, automáticamente reescrito por el optimizador.
Documentos y recursos
El sitio de documentación de Couchbase contiene enlaces a la referencia del lenguaje N1QL for Analytics: https://docs.couchbase.com/server/current/analytics/introduction.html. También puede encontrar allí un enlace a un tutorial sobre el lenguaje y al libro de Don Chamberlin (coinventor del lenguaje SQL): https://www.couchbase.com/sql-plus-plus-for-sql-users.
Muchas gracias a Dmitry Lychagin y Mike Carey por su cuidadosa revisión de este post.
