Con Couchbase 5.0 cerca de su lanzamiento estable, es una buena idea revisar algunas de las mejoras, tanto en rendimiento como en características, que están llegando con la tecnología N1QL.
¿Qué mejoras se han introducido en materia de rendimiento?
Mejoras en el rendimiento de N1QL
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.
Esto nos lleva al tema de N1QL y las mejoras de las funciones de indexación.
Indexación simplificada de matrices
Con Couchbase Server 4.5 llegó la indexación de arrays. Tomemos como ejemplo el siguiente documento de muestra:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
{ "tipo": "persona", "nombre": "Nic", "apellido": "Raboy", "social-media": [ { "tipo": "twitter", "url": "https://www.twitter.com/nraboy" }, { "tipo": "sitio web", "url": "https://www.thepolyglotdeveloper.com" } ] } |
Nueva sintaxis de índice de matriz
Antes de Couchbase 5.0, para indexar los elementos de la matriz que se encuentran en redes sociales tenías que escribir un índice parecido al siguiente:
|
1 2 3 |
CREAR ÍNDICE ism ON `default` ( DISTINCT ARRAY media FOR media IN `social-media` END ) WHERE tipo = 'persona'; |
En el ejemplo anterior, el PARA era necesario para la indexación de arrays. En Couchbase Server 5.0 hay una sintaxis mucho más simplificada. El mismo índice se puede crear mediante lo siguiente:
|
1 2 3 |
CREAR ÍNDICE ism ON `default` ( DISTINCT `social-media` ) WHERE tipo = "persona"; |
Para asegurarte de que tu índice funciona, puedes ejecutar la siguiente consulta N1QL:
|
1 2 3 |
EXPLICAR SELECT * POR DEFECTO WHERE type = 'person' AND ANY media IN `social-media` SATISFIES media.type = 'website' END; |
Al examinar los resultados de la EXPLICAR debería ver que está utilizando el ismo creado anteriormente.
Ahora bien, que exista la sintaxis simplificada no significa que no se pueda utilizar la sintaxis anterior al indexar arrays. El siguiente sería un ejemplo perfecto de por qué la sintaxis anterior seguiría siendo válida:
|
1 2 3 |
CREAR ÍNDICE ism_website ON `default` ( DISTINCT ARRAY media FOR media IN `social-media` WHEN media.type = 'website' END ) WHERE tipo = 'persona'; |
Obsérvese que a CUANDO al crear el ism_website índice superior.
Más información sobre la indexación de matrices aquíjunto con otra documentación útil sobre la creación de índices en Couchbase.
Requisito relajado de coincidencia de variables para índices de matrices
En las versiones 4.x, la indexación de matrices requería el uso de exactamente los mismos nombres de variables en el archivo SELECCIONE que se utilizaron en la CREAR ÍNDICE declaración. Más información aquí.
Por ejemplo, en referencia a las consultas anteriores, observe que la variable medios de comunicación que se utiliza para iterar a través de la matriz redes sociales es muy importante. La indexación de matrices en 4.x exige el nombre exacto de la variable medios de comunicación que se utilizará en el SELECCIONE consulta.
La versión 5.0 de Couchbase relaja este requisito, y la siguiente consulta funcionaría perfectamente:
|
1 2 3 4 |
EXPLICAR SELECT * POR DEFECTO UTILIZAR ÍNDICE (ism) WHERE type = 'person' AND ANY m IN `social-media` SATISFIES m.type = 'website' END; |
Tenga en cuenta que, el índice ismo utiliza el nombre de la variable medios de comunicaciónpero la consulta anterior utiliza m. Aun así, la consulta anterior puede utilizar el índice ismo con éxito.
Requisito relajado de clave de índice de matriz completa para índices de matriz
Recuerde también que, en las versiones 4.x, la indexación de matrices cubierta requiere el atributo de matriz completa como clave de índice obligatoria en la definición del índice de matriz. Por ejemplo, tome la siguiente consulta de nuevo:
|
1 2 3 |
EXPLICAR SELECT * POR DEFECTO WHERE type = 'person' AND ANY media IN `social-media` SATISFIES media.type = 'website' END; |
El índice de matriz cubierta correspondiente a la consulta anterior sería:
|
1 2 3 |
CREAR ÍNDICE ism_covered ON `default` ( DISTINCT ARRAY media FOR media IN `social-media` END, `social-media`) WHERE tipo = 'persona'; |
Tenga en cuenta que, la segunda clave de índice redes sociales es obligatorio, por ejemplo para cubrir la siguiente consulta:
|
1 2 3 |
EXPLAIN SELECT medio POR DEFECTO WHERE type = 'person' AND ANY media IN `social-media` SATISFIES media IS NOT NULL END; |
En Couchbase 5.0, esta misma consulta estará cubierta por el índice ismo al principio de este artículo.
Es importante notar que, esta característica trae mucho poder a los Índices de Arreglos. Porque, ahora cada entrada en el índice de matriz consume menos espacio de almacenamiento y memoria. Permite los siguientes beneficios:
- Uso de índices de matrices cubiertas para matrices más grandes
- Aumenta la eficacia y el rendimiento de las consultas que utilizan índices de matrices cubiertas.
Indexación de la metainformación del documento
Demos un giro aquí y hablemos de la nueva metainformación que se puede indexar. Antes se podían crear índices sobre la meta().id pero ahora tanto la propiedad meta().cas y meta().expiración son compatibles.
Entonces, ¿cómo creamos un índice que utilice las meta propiedades como claves? No es muy distinto de lo que ya sabes. Tomemos como ejemplo los siguientes índices de cobertura:
|
1 2 3 4 5 |
CREAR ÍNDICE idx_cas ON `default` ( META().cas, META().expiration ) CREAR ÍNDICE idx_exp ON `default` ( META().expiration ) |
Ahora bien, si quisiera utilizar el idx_cas y idx_exp índices en una consulta N1QL, podría hacer algo como lo siguiente:
|
1 2 3 4 5 6 7 |
SELECT META().id, META().cas POR DEFECTO WHERE META().cas > 1489531586248179712; SELECT META().id, META().expiration POR DEFECTO WHERE META().caducidad > NOW_MILLIS(); |
¿Por qué indexar estas propiedades? ¿Y si quisieras consultar todos los documentos que han caducado hoy o todos los documentos que se han modificado hoy?
Para más información sobre las propiedades CAS y de caducidad, visite aquí. Para obtener más información sobre la indexación o el uso de N1QL con Couchbase, consulte la página Portal para desarrolladores de Couchbase.
