Con el servidor Couchbase 4,0 GA - le ofrecimos N1QL, que fue un elemento clave para desarrollar con agilidad y operar a escala. Ahora, nos complace anunciar el versión preliminar para desarrolladores de 4.1 - que contiene valiosas correcciones de estabilidad. También incluye una función clave llamada Índices de cobertura.
El Índice de Cobertura es una nueva y emocionante característica de N1QL en la versión 4.1 que proporciona la capacidad para que una aplicación, que lo aproveche adecuadamente, reconozca una notable mejora en el rendimiento de la consulta 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 echas un vistazo al flujo de ejecución de la consulta, es el siguiente:
-
El cliente de la aplicación emite una solicitud de consulta al servidor a través de una API Rest
-
El servicio de consulta pasa por una fase de análisis sintáctico y genera un plan de consulta.
-
El servicio de consulta emite peticiones de escaneo al servicio de índices si existe un índice válido para la situación
-
Recupera las claves de documento cualificadas del servicio Index
-
Envía las claves del documento al Servicio de Datos (una "solicitud de obtención")
-
Recupera los documentos del Servicio de Datos
-
Evalúa los documentos (vuelve a aplicar criterios de filtrado, etc.)
-
Envía los resultados finales filtrados al cliente
En una aplicación bien diseñada, los pasos 5 y 6 pueden evitarse utilizando un índice de cobertura (que recomendamos encarecidamente como mejor práctica), y eso puede dar lugar a una mejora demostrable del rendimiento.
La sentencia EXPLAIN en N1QL permite ver el plan de ejecución de la consulta. Cuando se utiliza un índice de cobertura para la ejecución de la consulta, la sentencia EXPLAIN mostrará ahora que se utiliza un índice de cobertura para el acceso a los datos (y se evitan las búsquedas de documentos clave-valor y la sobrecarga asociada).
Supongamos que creamos un índice sobre el atributo "estado" en el bucket de muestras de cerveza.
CREAR ÍNDICE idxstate EN muestra de cerveza(estado) USO DE GSI
Ahora bien, si seleccionamos el estado de la muestra de cerveza, como todos los datos que se van a devolver están presentes en el índice, podemos evitar la obtención de datos de valor clave y limitarnos a devolver los datos basándonos en el índice.
EXPLAIN SELECT estado FROM muestra-cerveza' WHERE estado = "CA"
"resultados": [
{
"#operator": "Secuencia",
"~children": [
{
"#operator": "IndexScan",
"cubiertas": [
"cover((muestra de cerveza.estado))"
],
"index": "idxstate",
"keyspace": "cerveza-muestra",
"namespace": "default",
"spans": [
{
"Rango": {
"Alto": [
""CA""
],
"Inclusión": 3,
"Bajo": [
""CA""
]
}
}
],
"using": "gsi"
Nota: El mismo índice NO es un índice de cobertura si la consulta se modificara ligeramente.
EXPLAIN SELECT estado, ciudad FROM muestra de cerveza DONDE ESTADO = "CA";
Sigue utilizando 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 índice de cobertura.
{
"requestID": "c60b10d2-2cab-4b6a-987c-e5e6ebe4a900",
"firma": "json",
"resultados": [
{
"#operator": "Secuencia",
"~children": [
{
"#operator": "IndexScan",
"index": "idxstate",
"keyspace": "cerveza-muestra",
"namespace": "default",
"spans": [
{
"Rango": {
"Alto": [
""CA""
],
"Inclusión": 3,
"Bajo": [
""CA""
]
}
}
],
"using": "gsi"
},
{
"#operator": "Paralelo",
"~child": {
"#operator": "Secuencia",
"~children": [
{
"#operator": "Fetch",
"keyspace": "cerveza-muestra",
"namespace": "default"
},
{
"#operator": "Filtro",
"condición": "((muestra de cerveza.estado) = "CA")"
},
{
"#operator": "InitialProject",
"result_terms": [
{
"expr": "(muestra de cerveza.estado)"
},
{
"expr": "(muestra de cerveza.ciudad)"
}
]
},
{
"#operator": "FinalProject"
}
]...el resto se omite por brevedad
¿Cómo convertimos esta consulta modificada para utilizar un índice de cobertura?
Aquí tienes,
CREAR ÍNDICE idxstatecity EN muestra de cerveza (estado, ciudad) USANDO GSI
Ahora, si ejecutamos la consulta
EXPLAIN SELECT estado, ciudad
DESDE muestra de cerveza USE INDEX (idxstatecity)
DONDE ESTADO = "CA" ;
¡Bingo! Se convierte en una consulta que utiliza un índice de cobertura
{
"#operator": "IndexScan",
"cubiertas": [
"cover((meta(muestra de cerveza).id))",
"cover((muestra de cerveza.estado))",
"cover((muestra de cerveza.ciudad))"
],
"index": "idxstatecity",
"keyspace": "cerveza-muestra",
"namespace": "default",
"spans": [
{
"Rango": {
"Alto": [
"sucesor("CA")"
],
"Inclusión": 1,
"Bajo": [
""CA""
]
}
}
],
"using": "gsi"
},
EXPRESIONES Y AGREGADOS
Las consultas con expresiones y agregados también pueden beneficiarse del índice de cobertura.
CREAR ÍNDICE idxestadopaís EN muestra de cerveza(estado, país) USANDO GSI
SELECCIONE país, máx(estado)
DESDE muestra de cerveza USE INDEX (idxestadopaís)
WHERE STATE LIKE '%'
GROUP BY país
UNIÓN / INTERSECCIÓN / EXCEPCIÓN
También se admiten para cubrir índices
SELECCIONAR PAÍS
DESDE muestra de cerveza
DONDE ESTADO = 'CA'
UNIÓN TODOS
SELECCIONAR PAÍS
DESDE muestra-de-cerveza
WHERE ESTADO = 'Texas
Y puesto que el índice ya está ordenado, cuando se utiliza ORDER BY en el caso de un índice de cobertura, existe la ventaja añadida de que el motor de consulta ya puede utilizar un índice ordenado.
Consulte nuestra documentación para más información y más escenarios en los que los índices de cobertura le serán útiles.
Te animamos a que pruebes esta función en la versión 4.1 para desarrolladores y nos des tu valiosa opinión. comentarios.
También puede probar N1QL con la versión preliminar para desarrolladores de la aplicación Workbench de consultaque proporciona una interfaz gráfica para escribir y ejecutar consultas N1QL.
