N1QL en Couchbase ha recorrido un largo camino desde que fue introducido por primera vez en Couchbase Server 4.0. En Couchbase 5.0, las cosas se llevan al siguiente nivel en términos de rendimiento. En términos de la build para desarrolladores de marzo de 2017 de Couchbase 5.0, hay mejoras de rendimiento para N1QL en el sabor de la proyección de índices, mejoras para CONTAR y DISTINTOy el tan solicitado ORDENAR POR, LÍMITEy OFFSET operadores.
¿Qué se ha hecho en concreto para mejorar todas estas áreas y cómo podemos aprovechar los cambios?
Tomemos como ejemplo la proyección de índices. Al crear un índice, puede crear uno con cualquier número de propiedades. Por ejemplo, tomemos el siguiente índice:
|
1 |
CREATE INDEX idx ON default(type, firstname, lastname); |
La sentencia anterior creará un índice de cobertura en el archivo por defecto Cubo para el tipo, nombrey apellido de cualquier documento.
Supongamos ahora que creamos la siguiente consulta N1QL para recuperar algunos documentos con la propiedad idx índice que habíamos creado:
|
1 2 3 |
SELECCIONAR nombre POR DEFECTO WHERE tipo = 'persona |
La consulta anterior utilizaría la función idx y devolver sólo el índice nombre para cada documento que coincida. El concepto de consulta de esta forma no es nada nuevo, sin embargo, lo que ocurre entre bastidores ha cambiado. Te darás cuenta de que aunque nuestro índice tiene muchas claves, sólo estamos interesados en un subconjunto, o en este caso dos claves.
¿Qué está pasando y por qué es importante?
En versiones anteriores de Couchbase se tomaban en consideración todas las claves del índice sin importar si sólo se utilizaba un subconjunto. Como resultado, se necesitaba más red, CPU y memoria para acomodar lo que estaba ocurriendo. Ahora este no es el caso.
Entonces, ¿cómo saber si se está produciendo una proyección de índice?
Haga un EXPLICAR en la consulta que estás ejecutando:
|
1 2 3 |
EXPLAIN SELECT nombre POR DEFECTO WHERE tipo = 'persona |
En los resultados debería ver algo relativo a proyección_índice que se parece a lo siguiente:
|
1 2 3 4 5 6 7 8 |
... "proyección_índice": { "entry_keys": [ 0, 1 ] }, ... |
En claves_de_entrada cambiará en función de su consulta. Por ejemplo, ¿qué pasa si añadimos una DONDE condición así?:
|
1 2 3 |
SELECCIONAR nombre POR DEFECTO WHERE tipo = 'persona' AND apellido = 'Nic' |
En el escenario anterior, obtendríamos un EXPLICAR resultado que se parece a lo siguiente:
|
1 2 3 4 5 6 7 8 9 |
... "proyección_índice": { "entry_keys": [ 0, 1, 2 ] }, ... |
Ahora bien, la consulta anterior no era una proyección de índice porque utilizamos todas las claves de nuestro índice de cobertura.
La creación de índices adecuados junto con la proyección de índices puede ayudar realmente en el rendimiento general y el escalado de su clúster de Couchbase Server.
La proyección de índices no fue la única mejora de rendimiento realizada en la versión de marzo de 2017, ¿verdad? Así es, ¡hay más!
Tomemos el COUNT(DISTINCT) por ejemplo. Ahora utilicemos esa operación en la siguiente consulta:
|
1 2 |
EXPLAIN SELECT COUNT(DISTINCT tipo) POR DEFECTO; |
En los resultados observará que está utilizando IndexCountDistinctScan2 y lo que está haciendo es almacenar todos tipo en el índice y procesando los valores distintos. Aunque esto ocurre en el indexador en Couchbase 5.0, anteriormente ocurría en el servicio N1QL en ediciones anteriores. Al descargar esta operación en el indexador, podemos experimentar importantes mejoras de rendimiento.
Del mismo modo, tome la OFFSET, LÍMITEy ORDENAR POR que se pueden utilizar en las consultas N1QL. Tomemos como ejemplo la siguiente consulta:
|
1 2 3 4 5 6 |
EXPLAIN SELECT nombre POR DEFECTO WHERE tipo = 'persona ORDER BY nombre LÍMITE 1 OFFSET 1; |
Observará que el LÍMITE, ORDENAR PORy OFFSET aparecerán en el indizador. Antes de la versión 5.0, los operadores LÍMITE aparecía en el indexador, pero ahora los otros también lo hacen. Esto es una gran victoria porque en versiones anteriores de Couchbase si se desplazaban los resultados, N1QL obtendría todo el número X de resultados, y descartaría todo lo anterior al desplazamiento.
Para obtener más ayuda con N1QL, consulte la página Portal para desarrolladores de Couchbase que contiene un montón de documentación útil para desarrolladores.
" OFFSET, LIMIT, y ORDER BY" ejemplo debería ser
EXPLAIN SELECT nombre
POR DEFECTO
WHERE tipo = 'persona
ORDER BY nombre
LÍMITE 1
OFFSET 1;
Bien visto. He actualizado la consulta :-)