Asesor de Índices N1QL: Mejore el rendimiento y la productividad de las consultas

Como desarrolladores de aplicaciones, vuestro principal objetivo es diseñar las consultas más eficientes para vuestra aplicación. Desea garantizar la integridad de los datos que su aplicación envía a la base de datos y construir las consultas más eficaces para recuperar los datos necesarios para la aplicación. En muchos casos, el rendimiento de la aplicación se aplaza a una fase posterior del ciclo de desarrollo. A menudo se deja en manos de los especialistas en rendimiento de bases de datos, que pueden proporcionar las recomendaciones para el diseño del índice, que también puede incluir la reescritura de la consulta, con el fin de cumplir el requisito de rendimiento. Pero comprender el rendimiento de la consulta puede mejorar enormemente la productividad y ayudar a los desarrolladores a buscar una solución de mayor rendimiento en una fase temprana del ciclo de desarrollo.

Los proveedores de bases de datos son conscientes de este reto, y los RDBMS de clase empresarial incluyen la capacidad de ajuste del rendimiento como parte de sus conjuntos de herramientas de bases de datos.

Couchbase N1QL Index Advisor, una nueva característica en Couchbase 6.5 (DP), ahora proporciona recomendaciones de índices GSI para sentencias de consulta N1QL. Su objetivo principal es recomendar índices para optimizar el tiempo de respuesta de la consulta. Permite a los desarrolladores ser más productivos, ya que pueden crear los índices recomendados y ver cómo se comporta la consulta al principio del ciclo de desarrollo. También permite a los administradores de bases de datos mejorar el rendimiento del sistema revisando periódicamente las consultas de ejecución lenta.

Puede aprender a utilizar Couchbase Index Advisor leyendo el documento Comprender Index Advisor y Empezar a utilizar Index Advisor a continuación. Las secciones restantes proporcionan más detalles sobre cómo Index Advisor llega a las recomendaciones, incluyendo consejos sobre el uso de Index Advisor en las solicitudes completadas y cómo identificar los índices de uso poco frecuente.

Comprender Index Advisor

Rendimiento de la base de datosaunque es una tarea difícil de gestionar bien, es un problema bien entendido por los proveedores de bases de datos. El advenimiento de SaaS y DBasS también significa que el desafío del rendimiento de la base de datos es sólo una parte del servicio, y necesita ser automatizado con respecto a su capacidad para diagnosticar y solucionar el problema. Nuestro equipo de desarrollo ha estado trabajando duro para crear los bloques de construcción hacia esa visión.

Couchbase Index Advisor es parte del constructo N1QL ADVISE que permite a desarrolladores y DBAs gestionar el aspecto de ajuste de rendimiento de sus aplicaciones. Para entender cómo funciona Index Advisor, necesitas entender las principales técnicas de recuperación de datos en la plataforma de datos Couchbase:

• Key-Value - Un acceso rápido y directo a los datos para el servicio Data cuando las claves están disponibles. Este método de acceso no involucra al servicio de Indexación de Couchbase.
• Servicio de Indexación (GSI) - Un servicio escalable que permite a las aplicaciones realizar consultas N1QL rápidas. GSI aprovecha una arquitectura distribuida y almacena los índices en un conjunto independiente de nodos a través de Couchbase Cluster.
• Search (FTS) - Un servicio de búsqueda de texto completo que proporciona palabras clave y búsqueda difusa. FTS, como todos los servicios de Couchbase, es un servicio distribuido que se puede configurar en todo el clúster de Couchbase.

N1QL Query aprovecha todos los servicios anteriores para entregar el resultado de la consulta a las aplicaciones. Sin embargo, Index Advisor en v6.5 (DP) sólo recomienda índices gestionados por el servicio Index (GSI). Index Advisor no evalúa la técnica de recuperación del servicio de Datos a través de USE KEYS, ni el servicio de Búsqueda(FTS) a través de la función N1QL SEARCH_QUERY() y SEARCH().

Empezar a utilizar Index Advisor

Como ya he mencionado antes, Index Advisor es la primera de una serie de funciones que introducimos para el ajuste del rendimiento de las bases de datos. Index Advisor ayuda a identificar sistemáticamente los índices que pueden optimizar el rendimiento de la aplicación y garantiza que los índices se creen siguiendo las mejores prácticas recomendadas para el orden de las claves. En efecto, Index Advisor puede ofrecer recomendaciones incluso cuando ya se dispone de índices que funcionan para las consultas.

Puede empezar a utilizar N1QL Index Advisor utilizando:

N1QL - ADVISE [INDEX]

Índices actuales - La sección enumera todos los índices existentes que el planificador de consultas utilizará para esta consulta. También proporciona información adicional sobre cualquier índice que el planificador de consultas utilice como índice de cobertura.

Índices recomendados - Esta sección enumera todos los índices recomendados por el Asesor de Índices. Las recomendaciones de índices de cobertura son aquellas que permitirían que la consulta funcionara sin necesidad de obtener datos adicionales del servicio de datos. Mientras que la sección de índices muestra sólo aquellos que ayudan con la cláusula de predicado. Tenga en cuenta que podría haber duplicación de información en estas dos secciones, pero en las que el nombre del índice sería idéntico si las claves del índice son las mismas.

También explica por qué había recomendado los índices.

Utilizar Advise desde el Query Workbench

Haga clic en el botón Aconsejar para obtener la salida del Asesor de índices para la consulta.

N1QL ADVISE soporta consultas SELECT, DELETE, UPDATE y MERGE. Proporciona recomendaciones de índice para:

• Predicado de la cláusula WHERE.
• Condición de unión cláusula ON para Index join, ANSI join, Index NEST, ANSI NEST y ANSI MERGE.
• Índice de matriz para UNNEST y predicados de matriz en la cláusula WHERE/ON.
• Subconsulta cuando se utiliza en la cláusula FROM.

¿Cómo funciona Index Advisor?

Utilizaré el siguiente enfoque para explicar cómo funciona el Index Advisor.

1. Seleccionaré un ejemplo que tiene las típicas construcciones de consulta (predicado, join, array, group by), que pueden ser difíciles de adivinar cuáles son los mejores índices para la consulta.
2. Examine el plan de consulta para saber qué haría el optimizador para la consulta actual.
3. Determinar manualmente qué índices crear para mejorar el rendimiento de la consulta. Esto se basaría en la comprensión de los desarrolladores de aplicaciones típicas de los índices de predicados y campos de unión.
4. A continuación, ejecuta Couchbase Index Advisor y compara sus recomendaciones con las que teníamos en mente.
5. Cree los índices recomendados.
6. Revise el nuevo plan de consulta y evalúe los cambios.

Ejemplo de consulta

Esta consulta recupera el número de rutas por aerolíneas desde cualquier aeropuerto de la ciudad de San José, EE.UU. que tienen vuelos programados en domingo.

El plan de consulta 

1. La consulta utiliza cinco índices
   1. Se utilizaron tres índices para los predicados del tipo de documento "aeropuerto": "ciudad", "tipo" y "faa".
   2. Se ha utilizado un índice para el tipo de documento "route" en el campo "sourceairport" a efectos de la unión entre "route" y "airport". En este caso se utilizó el índice existente "def_route_src_dst_day" porque tiene la clave principal "sourceairport".
   3. Un índice para el tipo de documento "compañía aérea", que es el índice parcial por defecto para "tipo".
2. Dos documentos NestedLoop une - 'aeropuerto' - 'ruta' y 'ruta' - 'aerolínea'. Pero, aparte del índice "def_route_src_dst_day" en "route", no hay otros índices que soporten el resto de las uniones. Por lo tanto, estas uniones no son eficientes.
3. También hubo una agregación final para contabilizar el número de rutas por compañía aérea.
4. La consulta se completó en 2,1 s

¿Cómo podemos mejorar el rendimiento de la consulta?

1. El documento "aeropuerto" tiene dos predicados ("ciudad" y "país") y un predicado de sabor en "tipo". Además, la columna "faa" del aeropuerto también se utiliza para la unión con "route". Por tanto, en lugar de utilizar tres índices distintos, debería haber un índice parcial en el documento "airport" para ("city", "country") [action_1]. El campo "aeropuerto.faa" también podría beneficiarse de un índice separado, o de una parte del índice principal del aeropuerto.
2. El documento 'route' no tiene predicados, pero tiene un join a 'airport' con el campo 'sourceairport'. Un índice en esta columna debería ayudar con la unión, y ya tenemos el índice 'def_route_src_dst_day' [action_2] por lo que no es necesaria ninguna acción para esta unión.
3. El documento "route" también tiene una unión con "airline" en el campo "airline". Así que deberíamos tener un índice para esto - documento 'route' ('airline') [action_3].
4. El documento 'airline' tampoco tiene predicado, pero tiene un join a 'route' con el campo 'iata'. Por lo tanto, se necesita otro índice en el documento "aerolínea" ("iata") [action_4].
5. Tenemos un predicado en el array route.schedule. Así que necesitamos un índice sobre esto también. route' document (DISTINCT ARRAY x.day FOR x in schedule END) [action_5].

Así que hemos llegado a cinco puntos de acción, que resultan en cuatro índices adicionales para esta consulta. Veamos qué recomienda Index Advisor.

Ejecute el Index Advisor para comprobar el resultado

Sección de índices actuales

Esto es lo mismo que nos había dado el plan. La consulta utiliza cinco índices.

Sección Índices recomendados - "Índices"

Esta sección enumera todos los índices desde la perspectiva del predicado. Tenga en cuenta que JOIN tiene campos ON, que también se tratan como predicados. Así que vamos a revisar los índices recomendados.

1. adv_country_faa_city_type ON viaje-muestra(país,faa,ciudad) DONDE tipo = 'aeropuerto' - Aparte del orden de las claves, se trata del mismo índice que hemos identificado en [action_1]. El orden de las claves no es significativo en este caso, ya que todos estos predicados utilizan la igualdad.
2. adv_airline_sourceairport_DISTINCT_schedule_day_type ON viaje-muestra(aerolínea,fuenteaeropuertoDISTINCT ARRAY x.day FOR x in schedule END) DONDE tipo = 'ruta' - Lo que Index Advisor ha hecho aquí es que ha combinado [acción_2, acción_3, acción_5] en un único índice.
3. adv_iata_type ON viaje-muestra(iata) DONDE tipo = 'aerolínea' - Este es el mismo índice que habíamos identificado en [action_4]

Sección de índices recomendados - "Índices de cobertura"

En esta sección se enumeran todas las recomendaciones sobre índices de cobertura. Tenga en cuenta que los índices de cobertura son los que se utilizan para satisfacer una consulta sobre un documento cuya ejecución no necesitaría realizar una obtención adicional del servicio de datos.

1. adv_faa_city_country_type_airportname_airportname ON viaje-muestra(país,faa,ciudad,nombre del aeropuerto) DONDE tipo = 'airport' - Index Advisor ha añadido el campo route.airportname al índice recomendado [adv_country_faa_city_type ON viaje-muestra(país,faa,ciudad)]. De este modo, el servicio de consulta no tendría que obtener el documento de ruta del servicio de datos para proyectar el nombre de aeropuerto route.airportname
2. adv_iata_type_name_name ON viaje-muestra(iata,nombre) DONDE tipo = 'compañía aérea' - Index Advisor ha añadido el nombre de la compañía aérea al índice recomendado [adv_iata_type ON viaje-muestra(iata) DONDE tipo = 'compañía aérea']. De este modo, el servicio de consulta no necesitaría obtener el documento de la línea aérea del servicio de datos para proyectar el nombre de la línea aérea.

Nota: El índice de cobertura reduce la necesidad de que el servicio de consulta realice búsquedas adicionales en el servicio de datos, lo que mejora el rendimiento de la consulta. Sin embargo, el usuario debe decidir si crea o no índices de cobertura en función de sus limitaciones específicas, como la memoria o el almacenamiento de su entorno.

Cree todos los índices recomendados y revise el nuevo plan de consulta

Para este ejercicio, he decidido crear todos los índices recomendados utilizando índices de cobertura cuando proceda.

El plan de consulta después de añadir los índices recomendados

1. La consulta utiliza ahora los tres nuevos índices recomendados por Index Advisor, en lugar de cinco índices.
2. Dado que hemos creado índices de cobertura, el servicio de consulta ya no necesita realizar ninguna búsqueda adicional desde el servicio de datos.
3. Ahora la consulta se completa en 120 ms. Una mejora de 94%.

Utilice Index Advisor para analizar la carga de trabajo

N1QL - ASESOR( )

Index Advisor también puede invocarse con la función ADVISOR(). Permite a los usuarios:

1. Pasar múltiples consultas. SELECT ADVISOR("SELECT ..", "SELECT ..", "UPDATE..");
2. Pase una subconsulta que devuelva las sentencias N1QL reales. Dado que la consulta devuelve una estructura de documento json, tendrás que utilizar la palabra clave RAW para asegurarte de que solo se devuelven las sentencias N1QL reales.

Utilice ADVISOR() para identificar las consultas lentas consultando las peticiones completadas.

Identificar los índices ineficaces existentes

Incluso cuando ya tienes índices para tu consulta, ejecutar Index Advisor puede ayudar a identificar casos en los que los índices existentes pueden no ser los mejores índices, basándose en la guía de Índices de Couchbase.

Considere este ejemplo:

Y que tu consulta puede ejecutarse sin problemas con un índice por debajo:

Pero el índice recomendado para la consulta sería:

Esto se debe a que el índice debería funcionar mejor si las claves siguen el orden de la regla del tipo de predicado:

• Regla 4. Menor que/entre/mayor que.
• Regla 6. No nulo/no perdido/valorado.
• Regla 8. Sabor para índice parcial.

Convención recomendada para la denominación de índices

Index Advisor recomienda índices con una convención de nomenclatura específica,

• adv_field1_field2_field3...

Para los índices de matriz, se añade un guión bajo adicional al final del índice de matriz para distinguirlos:

• adv_[DISTINCT/ALL]_campo1_campo1.2_campo1.2.3__campo2_campo3...

Se recomienda que mantenga la nomenclatura del índice tal y como se ha proporcionado, ya que esto permitiría a Index Advisor reconocer los índices que había recomendado anteriormente frente a los que se han creado por otros medios. En futuras actualizaciones, Index Advisor puede optar por recomendar la sustitución de un índice, pero sólo lo haría si el índice que pretende sustituir es uno que ya había recomendado anteriormente.

Utilizar estadísticas de índices Última hora de exploración conocida

Su base de datos puede tener muchos índices para diferentes requisitos de consulta a lo largo de un periodo de tiempo. Pero a medida que se acumulan índices en su base de datos, existe la posibilidad de que se produzcan duplicados o índices creados de forma similar. Esto incluye los índices que ya no están en uso. Puede consultar el valor "hora_última_exploración_conocida"del punto final Index stats rest, para determinar el estado de sus índices y decidir si debe eliminarlos.

Resultados:

Resumen

Desde la perspectiva del despliegue de aplicaciones, la necesidad de gestionar los índices no se detiene al final del proceso de desarrollo, sino que es un ejercicio continuo. De hecho, la gestión de índices debe tener un ciclo de vida propio. Esto se debe a que el volumen y la forma de los datos pueden cambiar con el tiempo, lo que posteriormente puede requerir cambios en los índices existentes. En algunos casos, también puede ser necesario revisar la construcción de la consulta. El asesor de índices, por tanto, es una parte crítica para la gestión del ciclo de vida del producto.

Algunos puntos clave a tener en cuenta sobre Index Advisor a partir de Couchbase 6.5 (DP)

• Tipo de índice - Index Advisor sólo recomienda índices GSI. No recomienda índices primarios, ni índices FTS.
• Basado en reglas - En la implementación actual, el Asesor de índices recomienda índices basados en predicados, la lista de proyección y el orden de las columnas clave. En efecto, se basa en la misma regla que utiliza el planificador de consultas. Al igual que con la optimización de bases de datos basada en reglas (RBO), Index Advisor no tiene en cuenta las estadísticas de la distribución de datos de las columnas clave. Por esta razón, el usuario debe realizar una evaluación del rendimiento con los índices recomendados antes de desplegarlos en un entorno de producción.
• Subconsulta: el Index Advisor funciona con subconsultas cuando la consulta sólo se encuentra en la cláusula FROM.
• Índice de matriz con varias claves: el Asesor de índices sólo recomendará una única clave para un índice de matriz, incluso cuando el predicado haga referencia a varios campos de matriz.
• Índice de partición: Index Advisor no incluye la cláusula de partición en el índice recomendado. creación de índices declaraciones.
• Índices existentes - Index Advisor no recomienda el rediseño de índices existentes, ni recomienda la eliminación de índices existentes. El usuario debe utilizar el último tiempo de escaneo del índice para tomar la decisión.

Recursos

• Descargar: Descargar Couchbase Server 6.5
• Documentación: Novedades de Couchbase Server 6.5
• Todos los blogs de 6.5

Nos encantaría que nos dijera qué le han parecido las funciones de la versión 6.5 y en qué beneficiarán a su empresa en el futuro. Por favor, comparta su opinión a través de los comentarios o en el foro.