Nuevos perfiles y monitorización en la versión preliminar de Couchbase Server 5.0

Cuando escribo consultas N1QL, necesito ser capaz de entender lo bien (o lo mal) que mi consulta (y mi clúster) está funcionando con el fin de hacer mejoras y diagnosticar problemas.

Con esta última versión para desarrolladores de Couchbase Server 5.0, se han añadido algunas herramientas nuevas a tu caja de herramientas de escritura N1QL.

Primero, un repaso.

Existen múltiples formas para que un desarrollador ejecute consultas N1QL.

En este post, utilizaré principalmente Query Workbench.

Hay dos catálogos de sistemas que ya están disponibles en Couchbase Server 4.5 y de las que hablaré hoy.

Ambos solicitudes_activas y solicitudes_realizadas devuelven no sólo el texto original de la consulta N1QL, sino también información relacionada: tiempo de solicitud, id de solicitud, tiempo de ejecución, consistencia del escaneo, etc. Esta información puede ser muy útil. He aquí un ejemplo de una consulta simple (select * from viaje-muestra) mientras se ejecuta select * from sistema:solicitudes_activas;

En primer lugar, quiero señalar que phaseTimes es una nueva adición a los resultados. Es una forma rápida y sucia de hacerse una idea del coste de la consulta sin mirar el perfil completo. Le da el coste global de cada fase de la consulta sin entrar en el detalle de cada operador. En el ejemplo anterior, por ejemplo, se puede ver que analizar tardó 500µs y primaryScan tardó 107,3891 ms. Esto puede ser suficiente información para que usted pueda seguir sin bucear en META().plan.

Sin embargo, con el nuevo META().planpuedes obtener información muy detallada sobre el plan de consulta. Esta vez, ejecutaré SELECT *, META().plan FROM system:active_requests;

La salida anterior procede del Query Workbench.

Observe la nueva parte "plan". Contiene un árbol de operadores que se combinan para ejecutar la consulta N1QL. El operador raíz es una Secuencia, que a su vez tiene una colección de operadores hijos como Authorize, PrimaryScan, Fetch, y posiblemente aún más Secuencias.

Para obtener esta información al utilizar cbq o la API REST, tendrás que activar la función "perfil".

Puede hacerlo en cbq introduciendo set -perfil timings; y, a continuación, ejecute su consulta.

También puede hacerlo con la API REST por cada solicitud (utilizando la función /consulta/servicio y pasando un parámetro querystring de perfil=tiempospor ejemplo).

Puedes activar la configuración para todo el nodo haciendo una petición POST a http://localhost:8093/admin/settings, usando autenticación Basic, y un cuerpo JSON como:

Fíjese en el perfil ajuste. Antes estaba desactivado, pero lo he puesto en "temporización".

Puede que no quieras hacerlo, especialmente en nodos que están siendo utilizados por otras personas y programas, porque afectará a otras consultas que se estén ejecutando en el nodo. Es mejor hacerlo por petición.

También es lo que hace Query Workbench por defecto.

Hay mucha información en META().plan sobre cómo se ejecuta el plan. Personalmente, prefiero ver una versión gráfica simplificada del mismo en Query Workbench haciendo clic en el icono "Plan" (que mencioné brevemente en un post anterior sobre la nueva Couchbase Web Console UI).

Veamos un ejemplo algo más complejo. Para este ejercicio, estoy utilizando el cubo de muestras de viajes, pero he eliminado uno de los índices (DROP INDEX viaje-muestra.def_sourceairport;).

A continuación, ejecuto una consulta N1QL para encontrar vuelos entre San Francisco y Miami:

Ejecutar esta consulta (en mi máquina local de un solo nodo) tarda unos 10 segundos. Definitivamente no es una cantidad de tiempo aceptable, así que echemos un vistazo al plan para ver cuál puede ser el problema (lo he dividido en dos líneas para que las capturas de pantalla quepan en la entrada del blog).

Si se observa el plan, parece que las partes más costosas de la consulta son las siguientes Filtro y el Únete a. ÚNASE A funcionan con teclas, por lo que normalmente deberían ser muy rápidas. Pero parece que hay un lote de los documentos que se unen.

El filtro (el DONDE parte de la consulta) también lleva mucho tiempo. Está mirando el fuenteaeropuerto y destinoaeropuerto campos. Mirando en otra parte del plan, veo que hay un PrimaryScan. Esto debería ser una señal de alarma cuando se intenta escribir consultas de alto rendimiento. PrimaryScan significa que la consulta no ha podido encontrar un índice distinto del índice primario. Esto es más o menos el equivalente a un "escaneo de tabla" en términos de bases de datos relacionales. (Puede que quieras eliminar el índice primario para que estos problemas se solucionen más rápidamente, pero ese es un tema para otro momento).

Vamos a añadir un índice en fuenteaeropuerto campo y ver si eso ayuda.

Ahora, ejecutando la misma consulta anterior, obtengo el siguiente plan:

Esta consulta tardó ~100ms (en mi máquina local de un solo nodo), lo que es mucho más aceptable. El Filtro y el Únete a siguen ocupando un gran porcentaje del tiempo, pero gracias a la IndexScan sustituyendo el PrimaryScanEn el caso de los operadores de búsqueda, son muchos menos los documentos con los que tienen que trabajar. Tal vez la consulta podría mejorarse aún más con un índice adicional sobre el índice destinoaeropuerto campo.

La respuesta a los problemas de rendimiento no siempre está en ajustar las consultas. A veces es necesario añadir más nodos al clúster para solucionar el problema subyacente.

Mira el PrimaryScan información en META().plan. He aquí un fragmento:

En servTime indica cuánto tiempo emplea el servicio de consulta en esperar en el almacenamiento de datos Clave/Valor. Si el valor servTime es muy alta, pero hay un número pequeño de documentos siendo procesados, eso indica que el indexador (o el servicio clave/valor) no puede seguir el ritmo. Tal vez tienen demasiada carga procedente de otro lugar. Así que esto significa que algo raro se está ejecutando en algún otro lugar o que su clúster está tratando de manejar demasiada carga. Puede que sea el momento de añadir más nodos.

Del mismo modo, el kernTime es cuánto tiempo se pasa esperando en otras rutinas N1QL. Esto podría significar que algo más aguas abajo en el plan de consulta tiene un problema, o que el nodo de consulta está saturado de peticiones y está teniendo que esperar mucho.

El nuevo META().plan y el nuevo Plan UI se combinan en Couchbase Server 5.0 para mejorar el proceso de escritura y perfilado de N1QL.

Permanezca atento a la Blog de Couchbase para más información sobre la próxima versión para desarrolladores.

¿Le interesa probar algunas de estas nuevas funciones? Descargar Couchbase Server 5.0 ¡hoy!

Queremos tu opinión Todos los meses se publican versiones para desarrolladores, así que tienes la oportunidad de influir en lo que estamos construyendo.

Bichos: Si encuentra un error (algo que no funciona o que no funciona como cabría esperar), presente un problema en nuestra sección Sistema JIRA en issues.couchbase.com o envíe una pregunta a Foros de Couchbase. O ponte en contacto conmigo con una descripción del problema. Estaré encantado de ayudarte o de enviar el error por ti (mis gestores de Couchbase me chocan los cinco cada vez que envío un buen error).

Comentarios: Dígame lo que piensa. ¿Algo que no te guste? ¿Algo que te guste mucho? ¿Falta algo? Ahora puedes dar tu opinión directamente desde la Consola Web de Couchbase. Busca el icono en la parte inferior derecha de la pantalla.

En algunos casos, puede resultar difícil decidir si su comentario es un error o una sugerencia. Usa tu criterio o, de nuevo, no dudes en ponerte en contacto conmigo para pedirme ayuda. Quiero saber de ti. La mejor forma de ponerse en contacto conmigo es Twitter @mgroves o envíeme un correo electrónico matthew.groves@couchbase.com.