En este artículo, abordaremos algunos ejemplos prácticos empezando por las consultas N1QL utilizando Índices GSI y simular un conjunto de datos que con el tiempo crece no sólo con el tamaño del documento, sino que la estructura real del documento también crece. Couchbase Server facilita un esquema flexible, pero cuando se añaden nuevos campos y datos necesitamos añadir más índices GSI y potencialmente mantenerlos.
Le recomiendo que lea nuestra Índices Flex docs después de este artículo si no lo ha hecho, sin embargo; esta entrada de blog cubrirá algunos ejemplos prácticos para que se familiarice con el uso de Flex Indexes.
Comenzando en Couchbase 6.5 (early preview) y ahora con más soporte en el Lanzamiento de Couchbase 6.6tenemos la posibilidad de aprovechar los índices Flex. Es una gran herramienta para usar en casos donde las condiciones no están predeterminadas y sus predicados de búsqueda involucran un gran número de campos. Nos centraremos en esas situaciones. Utilizaremos el cubo de muestras de viajes para asegurarnos de que pueda ponerse en marcha y seguir el proceso fácilmente.
Preparación del servidor y los datos
Para empezar tengo instalado Couchbase Server 6.6 usando Dockerpero no dude en instalar localmenteel Nube Couchbaseo en tu plataforma en la nube favorita si lo desea.
Una vez que nuestro Couchbase Server está en funcionamiento, instalar el cubo de muestras travel-sample. Ahora debería ver 31.631 documentos disponibles.
También se han instalado los índices primario y GSI predeterminados para ayudarle a consultar este conjunto de datos nada más sacarlo de la caja.
Para las consultas que realizaremos sobre los datos del hotel, sólo utilizaremos tres de los índices que vemos instalados en la pestaña Índices.
-
- def_ciudad
- def_primary
- def_tipo
Esto nos dejaría con tres índices y podríamos suponer que, si nuestra única intención fuera consultar registros de hoteles, bastarían para nuestras consultas en torno a los datos existentes del conjunto de datos de la muestra de viajes. Teniendo en cuenta nuestra "hotel" estos tres índices serán los que utilicemos en nuestros ejemplos.
Índices GSI básicos
Empezaremos examinando una consulta N1QL SIN Indexación flexible.
|
1 2 3 4 5 |
SELECCIONAR * DESDE `viaje-muestra` DONDE tipo = "hotel" Y país = "Estados Unidos" Y estado = "California" Y (ciudad = "Fremont" O ciudad = "Oakland") |
Cuando ejecutamos esta consulta N1QL utilizando los índices GSI preconstruidos que vienen con la aplicación viaje-muestra terminamos utilizando una intersección del def_tipo y def_ciudad Índices GSI.
En la interfaz web de Couchbase Server, Ejecute la consulta en el editor del Query Workbench y revise el plan para ver qué índice se está utilizando.
Este índice se eligió debido a la optimización basada en reglas, si hay un índice que coincida con el predicado, se utilizará. Dado que "California" aparece como estado para todos los documentos con ciudad de "Fremont" o "Oakland"podemos utilizar una intersección de def_tipo y el def_ciudad índices para obtener el rendimiento más óptimo.
Añadir más datos y campos
Ahora vamos a añadir más datos. Vamos a añadir 30.000 documentos con los siguientes campos nuevos:
- estrellas: Número
- frente a: Cadena
- hotelType: Cadena
- principalesAmenidades: Matriz de cadenas
Si quieres seguirnos, clona el botón viajes-muestra-hoteles-falsos y antes de ejecutar el archivo server.js, asegúrate de que tu nombre de usuario y contraseña de Couchbase en el código de conexión son correctos.
|
1 |
nodo servidor |
Una vez finalizado, el recuento total de documentos ascenderá a 61.631, de los cuales 30.000 serán documentos recién añadidos con los nuevos campos que queremos empezar a utilizar en los predicados de consulta.
|
1 |
DONDE tipo="hotel" Y hotelType = "Jardín" |
Cuando añadimos una consulta contra nuestros nuevos datos utilizando un predicado con nuestros nuevos campos, nuestra consulta no va a tener un rendimiento óptimo. Tendríamos que añadir un nuevo índice. Algo como:
|
1 |
CREAR ÍNDICE `def_hotelType` EN `viaje-muestra`(`hotelType`) |
En un entorno de producción, añadir un índice puede ser a veces tedioso y requerir también un DBA, nuestros índices necesitan ser mantenidos a lo largo del tiempo.
Añadir índice para tipo de hotel
Si quisiéramos un índice mejor para las consultas con predicados que implican hotelType podríamos añadir lo siguiente:
|
1 2 3 |
CREAR ÍNDICE `def_hotelType` EN `viaje-muestra`(`hotelType`) DONDE (`tipo` = "hotel") USO DE GSI |
En este punto, ejecutar una consulta como la siguiente:
|
1 2 3 |
SELECCIONAR * DESDE `viaje-muestra` DONDE tipo = "hotel" Y hotelType = "Jardín" |
Utilizará este índice en lugar del primario o def_tipo con razón. Veremos que a medida que añadamos nuevos predicados a nuestras consultas para incluir los nuevos campos que añadimos como estrellas, frente a, hotelType, y posiblemente incluso predicados basados en la comprobación de nuestro principalesAmenidades tendremos que añadir cuidadosamente nuevos índices basados en la estrategia de consulta. Couchbase es bastante bueno en esto, hay grandes recursos como nuestro blog (Crear el índice adecuado, obtener el rendimiento adecuado) y existen otros recursos útiles para ayudarle.
Pero no crear el índice adecuado puede causar muchos problemas, uno de los más obvios es el tiempo que se tarda en obtener los datos.
La siguiente consulta utiliza los nuevos campos que hemos añadido:
|
1 2 3 4 |
SELECCIONAR * DESDE `viaje-muestra` DONDE tipo = "hotel" Y hotelType = "Jardín" Y frente a = "norte" |
En la situación anterior, si no hubiéramos creado el archivo def_hotelType podríamos ver tiempos de consulta de más de 5 segundos frente a 500ms.
Un índice de este tipo tarda unos diez segundos en crearse y multiplicará por diez los resultados en términos de tiempo y rendimiento a la hora de recuperar los datos. Recuerde que hay 30.000 documentos que examinar en caso de que utilicemos un índice incorrecto.
Añada más índices para mantenerse al día
Dependiendo de la cantidad de datos que tengamos y de muchas otras características de nuestros datos, añadir otro índice para predicados que busquen consultar sobre el campo "facing", que indica a qué lado de la propiedad da la entrada de un hotel.
|
1 2 3 |
CREAR ÍNDICE `def_facing` EN `viaje-muestra`(`frente a`) DONDE (`tipo` = "hotel") USO DE GSI |
Mejor aún, podríamos utilizar la función ADVISE para añadir un nuevo índice, esta última sugerencia se recomienda en lugar de añadir un índice individual. Si utilizamos la función ADVISE obtendremos la recomendación de añadir el siguiente índice:
|
1 2 3 |
CREAR ÍNDICE `adv_facing_hotelType_type` EN `viaje-muestra`(`frente a`,`hotelType`) DONDE `tipo` = hotel |
Podríamos obtener un mejor rendimiento del adv_facing_hotelType_type que se sugirió, pero cuando se consideran otras permutaciones de una consulta similar a ésta, pero en distinto orden de operaciones, obtenemos resultados diferentes. Todas estas son cosas que hay que tener en cuenta a la hora de realizar consultas y saber qué índices utilizar.
¿Y si pudiéramos consultar nuestros datos de tipo hotel, pero con un índice que nos permitiera ser más flexibles con nuestras consultas? También podría permitir la experiencia de otros desarrolladores teniendo en cuenta que podría utilizarse para cosas como consultas ad hoc y potencialmente ser lo suficientemente eficaz como para utilizarlo en lugar de nuestros índices GSI. ¿Y si existiera la opción de un índice único?
Flexionemos sobre estos datos
En Couchbase Server 6.6, tenemos una característica en Flex indexing que puede satisfacer tus necesidades. Lo bueno es que puedo mostrarte muy fácilmente cómo empezar a usarlo.
Tenemos que decirle al motor de consulta N1QL que tenemos la intención de utilizar un Índice Flex. Además la consulta debe tener ciertas características para utilizar el Flex Indexing, considerando que estos requisitos se cumplen, la consulta N1QL se transforma en una consulta FTS y se ejecuta contra el índice de texto completo.
Para no repetir la información de nuestra documentación, sigue siendo importante que mencione que hay diferencias semánticas y restricciones en las consultas N1QL frente a los índices Flex. Por este motivo, intentaremos evitar esas restricciones y ser conscientes de las diferencias semánticas.
Configuración de nuestro índice FTS Flex
Iara obtener un índice Flex que ejecute nuestra consulta en lugar de los índices que ya tenemos configurados para nuestro conjunto de datos de muestra de viajes, sólo tenemos que ir a la pestaña de búsqueda de la interfaz web de Couchbase Server y hacer clic en "Añadir índice" y rellene los siguientes campos.
- Para el nombre he utilizado "fts-index"se recomienda un nombre más descriptivo
- Seleccione el cubo en el que se encuentran nuestros documentos
- Para el Campo de tipo JSON, especificaremos: tipo
- Haga clic en +Añadir asignación de tipos y especificamos nuestro tipo de documento: hotel
- Seleccione "palabra clave" en el menú desplegable del analizador por defecto
- Desmarque la casilla por defecto para no escanear todos los tipos de documentos de nuestro cubo.
Utilizar FTS Hints
Todavía tenemos que indicar que nos gustaría probar y utilizar Flex Indexing en nuestras consultas N1QL. En la situación anterior, en la que tenemos una consulta N1QL muy básica que recupera documentos de tipo "hotel" si quisiéramos alterar esa consulta para aprovechar las ventajas de Flex Indexing proporcionaríamos la variable (USANDO FTS) insinuar:
|
1 2 3 4 |
SELECCIONAR * DESDE `viaje-muestra` UTILICE ÍNDICE (USO DE FTS) DONDE tipo = "hotel" Y hotelType = "Jardín" Y frente a = "norte" |
Esta consulta utiliza ahora el índice Flex que hemos configurado y delega en Flex Indexing para que se encargue de ello debido a la naturaleza genérica de nuestro índice.
Nuestras opciones de consulta son múltiples
Vamos a probar algunas consultas más, las he ejecutado todas y cada una parece tener beneficios similares sobre los índices GSI teniendo en cuenta el tiempo total para ejecutar la consulta y recuperar nuestros datos.
Aquí hemos añadido un predicado de ciudad.
|
1 2 3 4 5 |
SELECCIONAR * DESDE `viaje-muestra` UTILICE ÍNDICE (USO DE FTS) DONDE tipo = "hotel" Y frente a = "norte" Y hotelType = "Jardín" Y (ciudad = "Fremont" O ciudad = "Oakland") |
A continuación, combinamos los campos "ciudad" y "estrellas" en nuestro predicado.
|
1 2 3 4 |
SELECCIONAR * DESDE `viaje-muestra` UTILICE ÍNDICE (USO DE FTS) DONDE tipo = "hotel" Y (ciudad = "Fremont" O ciudad = "Oakland") Y estrellas > 3 |
¿Y si omitimos type="hotel"? (16s exploración primaria)
|
1 2 3 |
SELECCIONAR * DESDE `viaje-muestra` UTILICE ÍNDICE (USO DE FTS) DONDE hotelType = "Jardín" Y estrellas > 3 |
Queremos asegurarnos de que añadimos WHERE type="hotel" a nuestro predicado, cuando utilicemos el Flex Index específico que hemos configurado, recuerde que, en cierto sentido, es la parte más importante de nuestro predicado de consulta y que, de lo contrario, nuestro Flex Index no será recogido. Un índice que es de tipo mapeado no será seleccionado por N1QL si la expresión de la condición (por ejemplo tipo = "hotel") en la consulta.
Utilicemos el principalesAmenidades y comprueba si tiene una cadena de "Restaurante" contenido.
|
1 2 3 4 5 |
SELECCIONAR * DESDE `viaje-muestra` UTILICE ÍNDICE (USO DE FTS) DONDE tipo="hotel" Y ARRAY_CONTAINS(principalesAmenidades, "Restaurante") Y ciudad = "Oakland" |
Resumen
Hemos recorrido los fundamentos de GSI Indexes y Flex Indexing, mostrándote cómo empezar con la indexación en Couchbase. Nada de esto debería sustituir la lectura de la documentación, pero puede ayudarte a empezar más fácilmente. Con este conocimiento, ahora deberías entender cómo acercarte a Flex Indexing.
Gracias por leer y por favor, consulte la documentación de Flex Indexing para más información



