Desde que el más ágil y refinado chamuscar liberado en Couchbase 6.0.0, el equipo de FTS ha estado muy entusiasmado con el futuro potencial de optimización desbloqueado con el nuevo esquema de indexación. Con la versión 6.5.0, nos hemos embarcado en un viaje sin fin de optimización y ajuste del rendimiento del motor de búsqueda de texto completo.
Permítanme compartir con ustedes algunas de las interesantes optimizaciones que introduciremos en la próxima versión 6.5.0.
Consultas geográficas
FTS admite dos tipos de consultas geográficas. Distancia entre puntos y rectángulo delimitado. Desde el inicio de la función, no hemos tenido ocasión de revisarla y mejorarla, aunque era casi seguro que la implementación de la consulta necesitaba mejoras tanto en términos de memoria como de utilización de la CPU. La buena noticia es que, de todas las mejoras de rendimiento previstas en la versión 6.5.0, las mayores se han producido con los cambios geográficos.
Oportunidad
Al analizar el elevado consumo de memoria de las consultas geográficas, quedó claro que existe un enorme potencial de ajuste del rendimiento sin explotar. En el caso de los tipos de consulta de distancia puntual y rectángulo delimitado, el motor de indexación (bleve) tiene que averiguar el rango de puntos geográficos a buscar (términos candidatos) que cumplen los criterios de búsqueda a partir de los parámetros de consulta dados. Bleve obtiene esos términos geográficos candidatos mediante ciertos pasos matemáticos.
Pero no filtraba los términos geográficos candidatos generados matemáticamente. En otras palabras, se estaba produciendo una ampliación involuntaria del espacio de búsqueda en segundo plano. Y esto estaba provocando la creación de demasiados iteradores de búsqueda de términos innecesarios o irrelevantes (por ejemplo, términos que ni siquiera existen en el índice), lo que conduce a una gran cantidad de objetos temporales internos para gestionar y además añadiendo una gran sobrecarga al recolector de basura.
Respuesta
Hemos optimizado este caso aplicando un filtrado de términos geográficos que básicamente valida la existencia de los puntos geográficos generados matemáticamente en el diccionario de términos y los califica sólo si están presentes en él. Este enfoque redujo significativamente el número de puntos geográficos/términos candidatos que se buscan en el índice invertido y, por tanto, mejoró tanto la latencia como el rendimiento de las consultas geográficas.
Recompensa
Esto ha supuesto una mejora de hasta 6X de latencia para consultas geográficas en nuestras pruebas internas.
Consultas difusas
En pre chamuscar días, cuando un fuzzy/edit-distance Cuando se recibe la consulta, el motor de indexación revisa todos y cada uno de los términos indexados en el campo de la consulta para calcular la distancia de edición y averiguar si el término actual se encuentra dentro de la distancia de edición solicitada con el término de la consulta. Y si cumple ese criterio de distancia de edición, buscará el término en el índice invertido para obtener la lista de documentos en los que aparece el término y los detalles necesarios según lo dispuesto en la consulta. (vectores de términos, valores de documentos etc)
El reciente formato de indexación scorch utiliza FiniteStateTransducers(FST) para implementar el diccionario de términos, que tiene este bonito aspecto DFA propiedad. Esto nos ayudó a mejorar el enfoque novato para encontrar los términos candidatos con una distancia de edición determinada respecto a la consulta.
El planteamiento consiste en construir un Levenshtein Automaton(LA) para el término dado en la consulta de distancia de edición. Este LA es un DFA que tiene la propiedad de emparejar todos los términos que están como máximo a una distancia de edición dada "d" en la consulta. A continuación, este LA DFA se uniría o intersecaría con el corpus de términos indexados original/Diccionario de Términos (FST DFA) para filtrar los términos candidatos que deben buscarse como parte de la consulta.
Oportunidad
Hasta el lanzamiento de la versión 6.0, estábamos haciendo la LA DFA de nuevo en cada consulta entrante y esta parte de construcción de la LA DFA resultó ser agotadora en términos de uso de memoria y velocidad de construcción de la DFA.
Respuesta
Inspirado en el original papel y la entrada del blog - levenshteinLa nueva construcción de autómatas Levenshtein adopta un enfoque de dos pasos. En el primer paso, precalcula un DFA paramétrico para un conjunto de distancias de edición predefinidas* y esta parte es completamente independiente de la cadena de consulta, por lo que puede precalcularse. En el segundo paso, este DFA paramétrico se utiliza para calcular el DFA LA por consulta. Esto hace que la construcción del DFA sea bastante rápida y de memoria amigable.
Recompensa
Las pruebas comparativas de Go micro han demostrado que la nueva implementación está a la altura de 5X más rápido y 12X mejor en el uso de la memoria. Y en nuestras pruebas internas de rendimiento, esto ha llevado a ~50% mejoras en el rendimiento de las consultas.
Me alegra ver que has llegado hasta aquí.
Permítanme hacer aquí una parada brusca para facilitar su atención y guardar los cuentos restantes para la Parte 2. La siguiente parte tratará de las mejoras de rendimiento con la adopción de gRPC en FTS, así como con consultas como rango numérico, prefijo, comodín, etc.
… Parte 2
{distancias de edición predefinidas* => en la actualidad, FTS admite distancias de edición de hasta 2. Es decir, sólo 1 y 2.
La razón principal es que, en cualquier corpus de documentos de tamaño razonable, habrá demasiados términos que coincidan a una distancia de edición > 2 del término buscado. Por lo tanto, cualquier búsqueda adicional en el índice consume muchos recursos, además de reducir la relevancia de la búsqueda.}
