Ya hemos visto un puñado de buenas prácticas para definir un Índice FTS en part1Ahora vamos a explorar algunos consejos útiles sobre los aspectos operativos y de mantenimiento de un índice.
Un usuario nuevo en Recuperación de información(IR) puede que el proceso de definición de índices FTS le resulte un poco tedioso, sobre todo a la hora de configurar el proceso de análisis de texto para un índice. Es posible que se sienta abrumado por la sobrecarga de información de toda esa jerga de IR, como filtros de caracteres, tokenizadores y demás. innumerables filtros de fichas como shingles, ngrams, edge_ngrams, etc. Estas opciones son infinitas cuando se empieza a configurar un analizador de texto personalizado. Una vez definido un índice con un analizador personalizado/integrado, debido a todas estas complejidades inherentes antes mencionadas, se convierte en una tarea cada vez más engorrosa predecir y verificar la salida de los analizadores configurados.
Tal vez te preguntes por qué es importante conocer en detalle el resultado del análisis de texto.
Es muy importante, ya que la mayoría de los usuarios de búsquedas tropiezan con la siguiente pregunta durante su tanteo inicial con cualquier sistema de búsqueda de texto completo,
Pn. ¿Por qué la búsqueda no devuelve ningún resultado, incluso cuando he definido el índice según las directrices y sé que los tokens de búsqueda existen en los documentos?
Esto ocurre principalmente debido a,
- Un fallo en los analizadores configurados en la definición del índice - provoca la tokenización o curado de los datos en contra de sus expectativas. es decir, los tokens emitidos por los analizadores (o que se indexan en el sistema) no son los que usted espera que sean.
- Sin saberlo, ha seleccionado un analizador diferente durante la búsqueda, en contra de lo que se define según la asignación de campos en la definición del índice.
El texto del documento se analiza cuando se escribe en el índice, y por separado se analizan también los términos de búsqueda cuando se realiza una búsqueda. Normalmente, por defecto, se elegirán los analizadores de campo especificados en la definición del índice para analizar el contenido de la consulta si se trata de una consulta de ámbito de campo.
Para facilitar la comprensión y la fijación del canal de análisis de índices, FTS ha introducido un punto final de descanso en la versión 6.5.0, /api/index/{indexName}/analyzeDoc que acepta un documento json en el cuerpo de la petición y devuelve una respuesta json que contiene los tokens analizados según los analizadores configurados con el índice dado.
Puede utilizar este punto final para explorar y depurar los resultados del analizador en sus entornos de desarrollo o de ensayo. Este endpoint es incluso seguro para probarlo en un sistema de producción. La respuesta muestra literalmente los tokens que se habrían indexado como parte del índice si se hubieran indexado documentos similares. Puede utilizar el mismo punto final para comprobar el resultado del análisis de la consulta pasando sólo el campo de consulta junto con el texto de la consulta como documento json con un tipo de documento coincidente según lo definido por la asignación del tipo de índice.
Para corregir el desajuste del analizador entre el índice y el tiempo de consulta, tiene que utilizar consultas de ámbito de campo o bien anular los analizadores durante el tiempo de consulta, ya que muchas consultas ofrecen una opción para ello.
Pn. ¿Cómo se sabe si el clúster FTS tiene el tamaño correcto o hay signposts para detectar un clúster insuficientemente aprovisionado?
El dimensionamiento de los clústeres suele incluir la configuración de recursos de sistema suficientes, como la cuota de memoria RAM/FTS, la potencia de procesamiento de la CPU y la topología de clúster adecuada. La topología del clúster comprende además el número de particiones y el número de nodos aptos para un volumen de datos determinado y la carga de consulta/indexación. Hemos visto que muchos de nuestros clientes acaban utilizando clústeres infradimensionados sin seguir ninguna directriz de dimensionamiento. No vamos a entrar aquí en los detalles de dimensionamiento, ya que es un tema muy específico para cada caso de uso del cliente. Se recomienda a los usuarios que contacten con el equipo de Couchbase para que les ayuden con las directrices de dimensionamiento personalizadas para sus respectivos requisitos.
Pero hay algunos indicadores sencillos ya integrados en el sistema que pueden indicar que su clúster está infradotado.
- Progreso de la indexación realmente lento, incluso en ausencia de carga de consultas o mutaciones constantes de documentos.
- Las consultas de búsqueda se rechazan con el código de estado http 429. Esto indica que la cuota de memoria FTS de su sistema es insuficiente.
- Muchas consultas lentas en los gráficos de estadísticas pueden aludir a un mal dimensionamiento o a consultas de búsqueda subóptimas.
Las consultas subóptimas se refieren aquí a aquellas consultas que no están cuidadosamente escritas para obtener los mejores resultados con las cláusulas de búsqueda adecuadas. A veces hemos visto clientes que intentan realizar consultas compuestas complejas con más de 250 subconsultas. La mayor ineficiencia que se esconde aquí es que el sistema de búsqueda tiene que escanear una gran franja de datos indexados (principalmente de discos) para obtener los resultados correctos, frente a una consulta mejor orientada que obtendría los mismos resultados con sólo rozar una superficie más pequeña del índice. El resultado es un uso mucho mejor de los recursos del sistema.
