{"id":3676,"date":"2017-06-21T08:06:12","date_gmt":"2017-06-21T15:06:12","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=3676"},"modified":"2025-06-13T20:20:21","modified_gmt":"2025-06-14T03:20:21","slug":"n1ql-performance-feature-enhancements-couchbase-5-0","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/n1ql-performance-feature-enhancements-couchbase-5-0\/","title":{"rendered":"Mejoras de rendimiento y funciones de N1QL en Couchbase 5.0"},"content":{"rendered":"

Con Couchbase 5.0 cerca de su lanzamiento estable, es una buena idea revisar algunas de las mejoras, tanto en rendimiento como en caracter\u00edsticas, que est\u00e1n llegando con la tecnolog\u00eda N1QL.<\/p>\n

<\/p>\n

\u00bfQu\u00e9 mejoras se han introducido en materia de rendimiento?<\/p>\n

Mejoras en el rendimiento de N1QL<\/h2>\n

Tomemos como ejemplo la proyecci\u00f3n de \u00edndices. Al crear un \u00edndice, puede crear uno con cualquier n\u00famero de propiedades. Por ejemplo, tomemos el siguiente \u00edndice:<\/p>\n

CREATE INDEX idx ON default(type, firstname, lastname);<\/pre>\n
La sentencia anterior crear\u00e1 un \u00edndice de cobertura en el archivo\u00a0por defecto<\/code> Cubo para el\u00a0tipo<\/code>, nombre<\/code>y\u00a0apellido<\/code> de cualquier documento.<\/p>\n
Supongamos ahora que creamos la siguiente consulta N1QL para recuperar algunos documentos con la propiedad\u00a0idx<\/code> \u00edndice que hab\u00edamos creado:<\/p>\n
SELECT firstname\r\nFROM default\r\nWHERE type = 'person'<\/pre>\n
La consulta anterior utilizar\u00eda la funci\u00f3n\u00a0idx<\/code> y devolver s\u00f3lo el \u00edndice\u00a0nombre<\/code>\u00a0para 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\u00e1s cuenta de que aunque nuestro \u00edndice tiene muchas claves, s\u00f3lo estamos interesados en un subconjunto, o en este caso dos claves.<\/p>\n
\u00bfQu\u00e9 est\u00e1 pasando y por qu\u00e9 es importante?<\/p>\n
En versiones anteriores de Couchbase se tomaban en consideraci\u00f3n todas las claves del \u00edndice sin importar si s\u00f3lo se utilizaba un subconjunto.  Como resultado, se necesitaba m\u00e1s red, CPU y memoria para acomodar lo que estaba ocurriendo.  Ahora este no es el caso.<\/p>\n
Entonces, \u00bfc\u00f3mo saber si se est\u00e1 produciendo una proyecci\u00f3n de \u00edndice?<\/p>\n
Haga un\u00a0EXPLICAR<\/code> en la consulta que est\u00e1s ejecutando:<\/p>\n
EXPLAIN SELECT firstname\r\nFROM default\r\nWHERE type = 'person'<\/pre>\n
En los resultados deber\u00eda ver algo relativo a\u00a0proyecci\u00f3n_\u00edndice<\/code> que se parece a lo siguiente:<\/p>\n
...\r\n\"index_projection\": {\r\n    \"entry_keys\": [\r\n        0,\r\n        1\r\n    ]\r\n},\r\n...<\/pre>\n
En\u00a0claves_de_entrada<\/code> cambiar\u00e1 en funci\u00f3n de su consulta.  Por ejemplo, \u00bfqu\u00e9 pasa si a\u00f1adimos una\u00a0DONDE<\/code> condici\u00f3n as\u00ed?:<\/p>\n
SELECT firstname\r\nFROM default\r\nWHERE type = 'person' AND lastname = 'Nic'<\/pre>\n
En el escenario anterior, obtendr\u00edamos un\u00a0EXPLICAR<\/code> resultado que se parece a lo siguiente:<\/p>\n
...\r\n\"index_projection\": {\r\n    \"entry_keys\": [\r\n        0,\r\n        1,\r\n        2\r\n    ]\r\n},\r\n...<\/pre>\n
Ahora bien, la consulta anterior no era una proyecci\u00f3n de \u00edndice porque utilizamos todas las claves de nuestro \u00edndice de cobertura.<\/p>\n
La creaci\u00f3n de \u00edndices adecuados junto con la proyecci\u00f3n de \u00edndices puede ayudar realmente en el rendimiento general y el escalado de su cl\u00faster de Couchbase Server.<\/p>\n
La proyecci\u00f3n de \u00edndices no fue la \u00fanica mejora de rendimiento realizada en la versi\u00f3n de marzo de 2017, \u00bfverdad?  As\u00ed es, \u00a1hay m\u00e1s!<\/p>\n
Tomemos el\u00a0COUNT(DISTINCT)<\/code> por ejemplo.  Ahora utilicemos esa operaci\u00f3n en la siguiente consulta:<\/p>\n
EXPLAIN SELECT COUNT(DISTINCT type)\r\nFROM default;<\/pre>\n
En los resultados observar\u00e1 que est\u00e1 utilizando\u00a0IndexCountDistinctScan2<\/code> y lo que est\u00e1 haciendo es almacenar todos\u00a0tipo<\/code> en el \u00edndice y procesando los valores distintos.  Aunque esto ocurre en el indexador en Couchbase 5.0, anteriormente ocurr\u00eda en el servicio N1QL en ediciones anteriores.  Al descargar esta operaci\u00f3n en el indexador, podemos experimentar importantes mejoras de rendimiento.<\/p>\n
Del mismo modo, tome la\u00a0OFFSET<\/code>,\u00a0L\u00cdMITE<\/code>y\u00a0ORDENAR POR<\/code> que se pueden utilizar en las consultas N1QL.  Tomemos como ejemplo la siguiente consulta:<\/p>\n
EXPLAIN SELECT firstname\r\nFROM default\r\nWHERE type = 'person'\r\nORDER BY firstname\r\nLIMIT 1\r\nOFFSET 1;<\/pre>\n
Observar\u00e1 que el\u00a0L\u00cdMITE<\/code>, ORDENAR POR<\/code>y\u00a0OFFSET<\/code> aparecer\u00e1n en el indizador.  Antes de la versi\u00f3n 5.0, los operadores L\u00cdMITE<\/code> aparec\u00eda en el indexador, pero ahora los otros tambi\u00e9n lo hacen.  Esto es una gran victoria porque en versiones anteriores de Couchbase si se desplazaban los resultados, N1QL obtendr\u00eda todo el n\u00famero X de resultados, y descartar\u00eda todo lo anterior al desplazamiento.<\/p>\n
Esto nos lleva al tema de N1QL y las mejoras de las funciones de indexaci\u00f3n.<\/p>\n
Indexaci\u00f3n simplificada de matrices<\/h2>\n
Con Couchbase Server 4.5 lleg\u00f3 la indexaci\u00f3n de arrays. Tomemos como ejemplo el siguiente documento de muestra:<\/p>\n
{\r\n  \"tipo\": \"persona\",\r\n  \"nombre\": \"Nic\",\r\n  \"apellido\": \"Raboy\",\r\n  \"social-media\": [\r\n    {\r\n      \"tipo\": \"twitter\",\r\n      \"url\": \"https:\/\/www.twitter.com\/nraboy\"\r\n    },\r\n    {\r\n      \"type\": \"sitio web\",\r\n      \"url\": \"https:\/\/www.thepolyglotdeveloper.com\"\r\n    }\r\n  ]\r\n}<\/pre>\n
Nueva sintaxis de \u00edndice de matriz<\/h3>\n
Antes de Couchbase 5.0, para indexar los elementos de la matriz que se encuentran en redes sociales<\/code> ten\u00edas que escribir un \u00edndice parecido al siguiente:<\/p>\n
CREAR \u00cdNDICE ism\r\nON `default` ( DISTINCT ARRAY media FOR media IN `social-media` END )\r\nWHERE type = 'persona';<\/pre>\n
En el ejemplo anterior, el\u00a0PARA<\/code> era necesario para la indexaci\u00f3n de arrays.  En Couchbase Server 5.0 hay una sintaxis mucho m\u00e1s simplificada.  El mismo \u00edndice se puede crear mediante lo siguiente:<\/p>\n
CREAR \u00cdNDICE ism\r\nON `default` ( DISTINCT `social-media` )\r\nWHERE tipo = \"persona\";<\/pre>\n
Para asegurarte de que tu \u00edndice funciona, puedes ejecutar la siguiente consulta N1QL:<\/p>\n
EXPLICAR SELECT *\r\nFROM default\r\nWHERE type = 'person' AND ANY media IN `social-media` SATISFIES media.type = 'website' END;<\/pre>\n
Al examinar los resultados de la\u00a0EXPLICAR<\/code> deber\u00eda ver que est\u00e1 utilizando el\u00a0ismo<\/code> creado anteriormente.<\/p>\n
Ahora bien, que exista la sintaxis simplificada no significa que no se pueda utilizar la sintaxis anterior al indexar arrays.  El siguiente ser\u00eda un ejemplo perfecto de por qu\u00e9 la sintaxis anterior seguir\u00eda siendo v\u00e1lida:<\/p>\n
CREAR \u00cdNDICE ism_website\r\nON `default` ( DISTINCT ARRAY media FOR media IN `social-media` WHEN media.type = 'website' END )\r\nWHERE tipo = 'persona';<\/pre>\n
Obs\u00e9rvese que a\u00a0CUANDO<\/code> al crear el\u00a0ism_website<\/code> \u00edndice superior.<\/p>\n
M\u00e1s informaci\u00f3n sobre la indexaci\u00f3n de matrices\u00a0aqu\u00ed<\/a>junto con otra documentaci\u00f3n \u00fatil sobre la creaci\u00f3n de \u00edndices en Couchbase.<\/p>\n
Requisito relajado de coincidencia de variables para \u00edndices de matrices<\/h3>\n
En las versiones 4.x, la indexaci\u00f3n de matrices requer\u00eda el uso de exactamente los mismos nombres de variables en el archivo SELECCIONE<\/code> que se utilizaron en la CREAR \u00cdNDICE<\/code> declaraci\u00f3n. M\u00e1s informaci\u00f3n aqu\u00ed<\/a>.<\/p>\n
Por ejemplo, en referencia a las consultas anteriores, observe que la variable medios de comunicaci\u00f3n<\/code> que se utiliza para iterar a trav\u00e9s de la matriz redes sociales<\/code> es muy importante. La indexaci\u00f3n de matrices en 4.x exige el nombre exacto de la variable medios de comunicaci\u00f3n<\/code> que se utilizar\u00e1 en el\u00a0SELECCIONE<\/code> consulta.<\/p>\n
La versi\u00f3n 5.0 de Couchbase relaja este requisito, y la siguiente consulta funcionar\u00eda perfectamente:<\/p>\n
EXPLICAR SELECT *\r\nFROM default\r\nUSE INDEX (ism)\r\nWHERE type = 'person' AND ANY m IN `social-media` SATISFIES m.type = 'website' END;<\/pre>\n
Tenga en cuenta que, el \u00edndice ismo<\/code> utiliza el nombre de la variable medios de comunicaci\u00f3n<\/code>pero la consulta anterior utiliza m<\/code>. Aun as\u00ed, la consulta anterior puede utilizar el \u00edndice ismo<\/code> con \u00e9xito.<\/p>\n
Requisito relajado de clave de \u00edndice de matriz completa para \u00edndices de matriz<\/h3>\n
Recuerde tambi\u00e9n que, en las versiones 4.x, la indexaci\u00f3n de matrices cubierta requiere el atributo de matriz completa como clave de \u00edndice obligatoria en la definici\u00f3n del \u00edndice de matriz.  Por ejemplo, tome la siguiente consulta de nuevo:<\/p>\n
EXPLICAR SELECT *\r\nFROM default\r\nWHERE type = 'person' AND ANY media IN `social-media` SATISFIES media.type = 'website' END;<\/pre>\n
El \u00edndice de matriz cubierta correspondiente a la consulta anterior ser\u00eda:<\/p>\n
CREAR \u00cdNDICE ism_covered\r\nON `default` ( DISTINCT ARRAY media FOR media IN `social-media` END, `social-media`)\r\nWHERE type = 'persona';<\/pre>\n
Tenga en cuenta que, la segunda clave de \u00edndice redes sociales<\/code> es obligatorio, por ejemplo para cubrir la siguiente consulta:<\/p>\n
EXPLAIN SELECT medio\r\nFROM default\r\nWHERE type = 'person' AND ANY media IN `social-media` SATISFIES media IS NOT NULL END;<\/pre>\n
En Couchbase 5.0, esta misma consulta estar\u00e1 cubierta por el \u00edndice ismo<\/code> al principio de este art\u00edculo.<\/p>\n
Es importante notar que, esta caracter\u00edstica trae mucho poder a los \u00cdndices de Arreglos. Porque, ahora cada entrada en el \u00edndice de matriz consume menos espacio de almacenamiento y memoria. Permite los siguientes beneficios:<\/p>\n