Presentación del FTS con N1QL

Temas que tratará este artículo

1. ¿Qué tiene de bueno N1QL?
2. ¿Y el FTS?
3. Pero, ¿por qué FTS dentro de N1QL?
4. Consultas básicas N1QL+FTS
5. Implantación de N1QL+FTS
   1. Sintaxis
   2. Capacidades y limitaciones
6. N1QL+FTS Internos
7. Consultas con índice cubierto frente a consultas sin índice cubierto
8. Más ejemplos de consultas N1QL+FTS
9. ¿Y ahora qué?

1. Couchbase N1QL

• N1QL es la oferta SQL de Couchbase para manipular datos JSON almacenados en el servidor couchbase.
• Las sentencias N1QL se pueden utilizar para crear, modificar, eliminar índices y seleccionar, insertar, actualizar, eliminar y volver a insertar datos en documentos JSON.
• Las expresiones N1QL permiten al usuario realizar operaciones de agregación, aritméticas, de colección, de comparación, condicionales y varias más.
• Todo ello con el apoyo de índices secundarios que permiten realizar estas operaciones con gran eficacia.

2. Couchbase FTS

• La oferta de búsqueda de texto completo de Couchbase proporciona amplias capacidades de consulta en lenguaje natural y está pensada para permitir a los usuarios buscar texto en múltiples campos de documentos JSON almacenados en un servidor Couchbase.
• Admite búsquedas en función del idioma y resultados de puntuación basados en la relevancia que puede configurar el usuario.
• El FTS crea índices rápidos especialmente diseñados para gestionar con gran eficacia una amplia gama de cargas de trabajo de búsqueda de texto.

3. ¿Por qué apoyar el FTS a través de N1QL?

• Las consultas N1QL pueden realizar búsquedas en cadenas, números, matrices, etc. y, con indexación secundaria (índice b-tree), también admiten búsquedas puntuales y escaneos de rangos, pero FTS ofrece rendimiento para la búsqueda de texto (consultas compuestas simples y complejas) con el apoyo de su índice invertido subyacente.
• Las aplicaciones necesitan poder aprovechar ambas capacidades utilizando una API y un lenguaje únicos.
• Soporte de operaciones compuestas/complejas como la aplicación de agregaciones, operaciones aritméticas y otras operaciones SQL sobre resultados FTS para facilitar el desarrollo.
• Ampliar la visibilidad de FTS (más allá del SDK, curl o la interfaz de usuario de Couchbase).

4. N1QL + FTS

Couchbase 6.5 soportará la interfaz propuesta entre N1QL y FTS. El usuario todavía tendrá que configurar índices FTS para apoyar su caso de uso al igual que con GSI (Indexación Secundaria Global). Con esta nueva interfaz, los usuarios podrán combinar y ejecutar consultas FTS desde consultas N1QL sin problemas.

Un nuevo predicado SEARCH(..) será ahora soportado como parte de la sintaxis de consulta N1QL. Antes de entrar en los aspectos internos de lo que sucede cuando se ejecuta una consulta N1QL con el predicado SEARCH(..), aquí hay algo de documentación sobre cómo crear y gestionar índices FTS y aquí hay algunas consultas de ejemplo ..

Por ejemplo, digamos que tengo un índice FTS configurado sobre algunos documentos de viaje, y quiero obtener los resultados FTS (sólo ids) de todos los documentos que lleven "San Francisco" en su campo de ciudad...

Como puede ver arriba, la cadena de consulta FTS 'city: "San Francisco"' está incrustada dentro de la consulta N1QL. Alternativamente, la consulta N1QL también soportará un objeto de consulta FTS como ...

El ejemplo anterior limitará el conjunto de resultados FTS a 10.

O incluso un objeto de solicitud de búsqueda FTS ..

El ejemplo anterior también limita el conjunto de resultados a 10, pero FTS lo reforzará.

Los filtros OFFSET/LIMIT pueden establecerse en la sintaxis de la consulta N1QL o en el objeto de petición de búsqueda FTS. Si estos parámetros se establecen dentro de la petición de búsqueda FTS, FTS enviará sólo el número solicitado de resultados. Los parámetros N1QL se aplicarán sobre los resultados que FTS le haya enviado. Si estos parámetros no se establecen dentro del objeto FTS pero se establecen en la consulta N1QL - FTS transmitirá todos los resultados a N1QL hasta el momento en que N1QL haya recibido todos los resultados que necesita.

También, como en los últimos 3 ejemplos, uno no tiene que especificar explícitamente el nombre del índice FTS a escoger - N1QL determinará cual es el mejor índice entre los disponibles para ejecutar la consulta FTS. Si uno quiere que N1QL use un índice específico (por ejemplo - un índice llamado "travel"), así es como...

Tenga en cuenta que para todas las consultas de ejemplo anteriores - los resultados se transmiten y no se ordenan en función de la relevancia (puntuación - comportamiento FTS por defecto). La ordenación se puede realizar indicándolo explícitamente en la petición de búsqueda o utilizando el comando de N1QLs ORDENAR POR cláusula. La paginación de los resultados también puede lograrse indicándolo explícitamente en la solicitud de búsqueda o utilizando la cláusula de N1QL OFFSET y LÍMITE cláusulas.

5. Despliegue de N1QL + FTS

• Para permitir consultas N1QL con la capacidad SEARCH(..), el cluster couchbase necesita tener al menos 1 nodo que ejecute el servicio Search y 1 nodo que ejecute el servicio Query (ambos servicios pueden ser configurados en el mismo nodo también).
• Los índices FTS deben ser configurados por el usuario para indexar el contenido necesario sobre el que se desea buscar.
• Si N1QL no ha encontrado índices FTS para ejecutar la consulta, busca índices GSI que potencialmente puedan gestionar la consulta. En este caso, se aplica el predicado SEARCH(..) sobre los resultados intermedios obtenidos. Aunque esto funcionaría, no es el enfoque recomendado ya que la evaluación SEARCH(..) puede ser costosa.
• Las consultas N1QL con SEARCH(..) pueden ejecutarse desde el banco de trabajo de consultas, curl, SDK o la interfaz de línea de comandos que ofrece couchbase.

5.1 Sintaxis de búsqueda

Esto es lo que admite la función SEARCH(, , [opciones])...

5.2 Capacidades y limitaciones

• Todas las funciones que ofrecen las peticiones de búsqueda FTS serán compatibles con las consultas N1QL.
• Aquí son algunos puntos destacados sobre lo que hay que lanzar en la sección "query" dentro de la función SEARCH(..).
• En la primera versión de la interfaz N1QL+FTS no se permitirán los índices FTS que admitan asignaciones de tipos múltiples para que no se cuelen falsos positivos en el conjunto de resultados.

Aplicación interna

Internamente la interfaz N1QL+FTS soporta 4 APIs que el servicio N1QL invocará durante sus fases de preparación y ejecución para consultas con el predicado SEARCH(..).

Antes de describir las API anteriores con más detalle, aquí tienes un diagrama de flujo de las operaciones que se realizan en la interfaz ...

6.1 Sargable

Esta API de índices FTS se utilizará para determinar si el índice es capaz de gestionar la solicitud de consulta sin devolver falsos negativos. En la primera versión, el índice sólo se elige si todos los campos de la consulta están indexados en él, o si el índice tiene en su definición un mapeo dinámico que podría atender a todos los campos solicitados. Si varios índices son sargables para una consulta determinada, se elige el que tenga el menor número de campos indexados que satisfagan la cláusula de sargabilidad (por razones de rendimiento).

6.2 Paginable

Esta API se utilizará para determinar si los resultados obtenidos del índice FTS subyacente serán paginables o no. Si el índice es paginable, N1QL aplicará los filtros (offset, límite, información de ordenación) para FTS antes de emitir el Search(..), de lo contrario los filtros se aplican sobre el conjunto de resultados después de que FTS lo haya enviado.

Tenga en cuenta que esta API no se invoca si no hay filtros (offset, limit, order by) en la consulta N1QL.

6.3 Búsqueda

Esta API se invoca para el índice más sargable, y es esencialmente responsable de obtener la solicitud de búsqueda a través del índice FTS y la transmisión de los resultados a través de un canal. Si la cantidad de datos a transmitir excede el tamaño del búfer disponible en el extremo N1QL del canal, FTS rellenará los datos a un archivo y una rutina separada es responsable de transmitir este contenido a N1QL. Esto se hace para que los recursos del FTS no se detengan por una conexión lenta del N1QL. Internamente, el protocolo gRPC se utiliza para la transmisión de datos de FTS a N1QL.

6.4 Verificar:Evaluar

Esta API es utilizada por N1QL para asegurar que los resultados devueltos por un índice FTS son realmente válidos para la consulta. FTS sólo devuelve los ID de las claves y algunos metadatos relacionados con FTS (si se solicitan), como la puntuación, etc. N1QL obtiene los documentos de KV e invoca Verify para ellos si el predicado SELECT solicita algunos campos del documento.

Consultas con índice cubierto frente a consultas sin índice cubierto

Si el predicado de la sentencia SELECT sólo solicita claves o metadatos, no se invoca la API de verificación. Este tipo de consulta se denomina consulta consulta de índice cubierto. Si la solicitud se refiere al contenido de algún otro documento, N1QL utilizará las claves devueltas por FTS para obtener los datos del documento de KV, tras lo cual invocará el método Verify para cada uno de los documentos obtenidos para volver a comprobar si los documentos recuperados son realmente coincidencias válidas. Este tipo de consulta se denomina consulta de índice no cubierto. Las consultas sin índice cubierto tienden a tener latencias más altas que las consultas con índice cubierto, ya que implican la búsqueda y verificación de KV para cada resultado.

Si el usuario requiere que otros campos de los documentos formen parte del conjunto de resultados, un enfoque más rápido sería ajustar la definición del índice FTS para almacenar los campos deseados. Ahora, en la petición de búsqueda dentro de la función SEARCH(..), incluya una sección llamada "fields": ["*"] para obtener todos los campos almacenados como parte del conjunto de resultados. De esta manera N1QL no tendrá que hacer una búsqueda separada del documento y puede omitir la verificación => esencialmente convirtiendo una consulta de índice no cubierto en una consulta de índice cubierto a costa de un índice FTS más grande.

Considere la siguiente definición de índice FTS con los campos "país" y "contenido" indexados..

A continuación se muestra un ejemplo de consulta de índice no cubierto más lenta que recupera el campo de documento "contenido" de los documentos que tienen "estados unidos" en su campo "país"...

Vamos a actualizar la definición del índice para almacenar también el campo "contenido" que es de interés ..

Ahora aquí está la misma consulta que califica como una consulta de índice cubierto..

Más ejemplos de N1QL+FTS

8.1 Consultas más complejas

Ejecución de una búsqueda FTS de conjunción/disyunción compuesta dentro de una consulta N1QL ... los 100 documentos más importantes ordenados por puntuación (tf-idf .. que es el algoritmo de puntuación por defecto de FTS) de mayor a menor, cuya categoría es landmark y el país es Estados Unidos...

He aquí una consulta equivalente con ajustes FTS integrados en la función SEARCH(..) ...

Ejecución de otra consulta con la configuración FTS integrada en la función SEARCH(..) ... buscar todos los identificadores de documentos que contengan en su campo de descripción el término gótico sin tener en cuenta la puntuación. Aquí podemos optimizar la petición de búsqueda FTS para no determinar la puntuación en absoluto..

A continuación se describen con más detalle los distintos tipos de consulta FTS compatibles aquí.

8.2 Sargabilidad de las consultas frente a definiciones de índices

Antes de pasar a algunos ejemplos sobre cómo las consultas se consideran sargables para las definiciones de índices FTS, aprenda más sobre las definiciones de índices FTS aquí.

Considere la siguiente consulta, que busca el término "gótico" en el campo "descripción"...

En el sistema couchbase que nos ocupa, supongamos que hay varios índices FTS definidos.

El primer índice FTS que encontramos tiene la siguiente definición ..

Este índice es lo que se denomina un índice dinámico por defecto que cubre todos los campos disponibles en todos los documentos y también incluye el contenido del campo por defecto "_all". Este campo por defecto es el que se consulta cuando una consulta FTS no contiene información de "campo" para un criterio de búsqueda. Este índice se considera SARGIBLE para la consulta anterior.

Un segundo índice FTS tiene la siguiente definición ..

Este índice sólo tiene indexado el campo "descripción", que respondería a la petición de la consulta, y por tanto el índice es SARGABLE para la consulta.

Un tercer índice FTS tiene la siguiente definición ..

Este índice tiene algunos campos indexados, pero ninguno de ellos coincide con el campo solicitado "descripción". Este índice se considera NO APTO para la consulta.

N1QL ahora tiene la opción de seleccionar entre los 2 primeros índices que serán capaces de entregar resultados precisos para la consulta. Dado que el número de campos indexados dentro del segundo índice es preciso y más pequeño (y por lo tanto ya que la búsqueda a través de este índice sería más rápida), N1QL elige el segundo índice para la ejecución de la consulta.

Futuro

• Establecer mejor la sargabilidad apoyando cierta flexibilidad de las definiciones de índice FTS - como en los índices FTS que no admiten todos los campos solicitados.
• Compatibilidad con índices FTS con asignaciones de tipos múltiples.
• Ampliación de la interfaz de consulta N1QL para editar índices FTS.