Con Couchbase Server 4.0 GA – ¡les proporcionamos N1QL, que fue un habilitador clave para desarrollar con agilidad y operar a escala! Ahora, nos complace anunciar el versión preliminar para desarrolladores de 4.1 – el cual incluye valiosas correcciones de estabilidad. Integrada en este se encuentra una función clave llamada Índices de cobertura.
El índice de cobertura (Covering Index) es una nueva e interesante característica de N1QL en la versión 4.1 que ofrece a una aplicación que la aproveche adecuadamente la capacidad de reconocer una mejora notable en el rendimiento de las consultas en muchos casos. Una consulta cubierta es una consulta N1QL en la que todos los campos de la consulta forman parte de un índice y todos los campos devueltos en la consulta están en el mismo índice.
Antes de esta mejora, si se echa un vistazo al flujo de ejecución de la consulta, es el siguiente:
-
El cliente de la aplicación envía una solicitud de consulta al servidor a través de una API REST
-
El servicio de consultas pasa por una fase de análisis sintáctico y análisis, y genera un plan de consulta.
-
El servicio de consultas emite solicitudes de análisis al servicio de índices si hay un índice válido para la situación
-
Obtiene las claves de documento calificadas del servicio Index
-
Envía las claves del documento al Servicio de Datos (una ‘solicitud de recuperación’)
-
Recupera los documentos del Servicio de Datos
-
Evalúa los documentos (reaplica los criterios de filtrado, etc.)
-
Envía los resultados finales filtrados de regreso al cliente
En una aplicación bien diseñada, los pasos 5 y 6 se pueden evitar utilizando un índice de cobertura (el cual recomendamos encarecidamente como la mejor práctica), y eso puede resultar en una mejora demostrable del rendimiento.
La instrucción EXPLAIN en N1QL permite ver el plan de ejecución de consultas. Cuando se utiliza un índice de cobertura para la ejecución de una consulta, el EXPLAIN ahora mostrará que se usa un índice de cobertura para el acceso a los datos (y se evitan las recuperaciones de documentos por clave-valor y la sobrecarga asociada).
Digamos que creamos un índice en el atributo “state” en el bucket beer-sample.
CREATE INDEX idxstate ON `beer-sample`(state) USING GSI
Ahora, si seleccionamos state de beer-sample, dado que todos los datos que se van a devolver están presentes en el índice, podemos evitar las recuperaciones de datos de clave-valor y simplemente devolver los datos en función del índice.
EXPLAIN SELECT state FROM `beer-sample` WHERE state = ’CA“
“results”: [
{
“#operator”: “Secuencia”,
“~children”: [
{
“#operator”: “IndexScan“,
“covers”: [
“`cover((`beer-sample`.`state`))`”
],
“index”: “idxstate”,
“keyspace”: “beer-sample”,
“namespace”: “default”,
“spans”: [
{
“Range”: {
“Alto”: [
“”CA””
],
“Inclusión”: 3,
“Bajo”: [
“”CA””
]
}
}
],
“usando”: “gsi”
Nota: El mismo índice NO es un índice recubridor si la consulta fuera modificada ligeramente.
EXPLAIN SELECT state, city FROM `beer-sample` WHERE STATE = “CA”;
Todavía utiliza el índice idxstate; sin embargo, dado que el índice NO contiene la información de la ciudad, utiliza el índice para una búsqueda más rápida, pero no como un índice cubriente.
{
“requestID”: “c60b10d2-2cab-4b6a-987c-e5e6ebe4a900”,
“signature”: “json”,
“results”: [
{
“#operator”: “Secuencia”,
“~children”: [
{
“#operator”: “IndexScan“,
“index”: “idxstate”,
“keyspace”: “beer-sample”,
“namespace”: “default”,
“spans”: [
{
“Range”: {
“Alto”: [
“”CA””
],
“Inclusión”: 3,
“Bajo”: [
“”CA””
]
}
}
],
“usando”: “gsi”
},
{
“#operator”: “Paralelo”,
“~child”: {
“#operator”: “Secuencia”,
“~children”: [
{
“”#operator“: ”Fetch»,
“keyspace”: “beer-sample”,
“namespace”: “default”
},
{
“#operator”: “Filtro”,
“condition”: “((`beer-sample`.`state`) = “CA”)”
},
{
“#operator”: “InitialProject”,
“result_terms”: [
{
“expr”: “(`beer-sample`.`state`)”
},
{
“expr”: “(`beer-sample`.`city`)”
}
]
},
{
“#operator”: “FinalProject”
}
]…se omite el resto por brevedad
¿Cómo convertimos entonces esta consulta modificada para que utilice un índice cubriente?
Aquí tienes,
CREATE INDEX idxstatecity ON `beer-sample` (state, city) USING GSI
Ahora, si ejecutamos la consulta:
EXPLAIN SELECT state, city
DESDE `beer-sample` USAR ÍNDICE (idxstatecity)
DÓNDE ESTADO = “CA” ;
¡Bingo! Se convierte en una consulta que usa un índice cubridor
{
“#operator”: “IndexScan”,
“covers”: [
“cover((meta(`beer-sample`).`id`))”,
“`cover((`beer-sample`.`state`))`,
“cover((`beer-sample`.`city`))”
],
“index”: “idxstatecity”,
“keyspace”: “beer-sample”,
“namespace”: “default”,
“spans”: [
{
“Range”: {
“Alto”: [
“successor(“CA”)”
],
“Inclusión”: 1,
“Bajo”: [
“”CA””
]
}
}
],
“usando”: “gsi”
},
EXPRESIONES Y AGREGADOS
Las consultas con expresiones y agregados también se pueden beneficiar de un índice cubriente.
CREATE INDEX idxstatecountry ON `beer-sample`(state, country) USING GSI
SELECT country, max(state)
FROM `beer-sample` USE INDEX (idxstatecountry)
DONDE SE DICE ‘%’
AGRUPAR POR país
UNIÓN / INTERSECCIÓN / EXCEPTO
Estos también son compatibles para cubrir índices
SELECCIONAR PAÍS
DE `beer-sample`
DONDE ESTADO = ‘CA’
UNION ALL
SELECCIONAR PAÍS
DE `beer-sample`
DONDE ESTADO = ‘Texas’
Y dado que el índice ya está ordenado, cuando usas ORDER BY en el caso de un índice cobertor, existe el beneficio adicional de que el motor de consultas ya puede utilizar un índice ordenado.
Por favor, consulte nuestra documentación para obtener más información y más escenarios donde los índices agrupados cubrientes le sean útiles.
Te recomendamos encarecidamente que pruebes esta función en la versión preliminar para desarrolladores de 4.1 y nos des tus valiosos retroalimentación.
También puedes probar N1QL usando la Vista previa para desarrolladores de Workbench de consultas, el cual proporciona una agradable interfaz gráfica de usuario para escribir y ejecutar consultas N1QL.
Deja un comentario
Lo siento, debes estar conectado para publicar un comentario.