lucene - ejemplos - ¿Cómo mejorar el rendimiento de un solo prefijo de PrefixQuery?

apache solr ejemplos

Question

Tengo un RAMDirectory con 1,5 millones de documentos y estoy buscando usando un PrefixQuery para un solo campo. Cuando el texto de búsqueda tiene una longitud de 3 o más caracteres, la búsqueda es extremadamente rápida, menos de 20 milisegundos. Pero cuando el texto de búsqueda tiene una longitud de menos de 3 caracteres, la búsqueda puede tomar incluso 1 segundo completo.

Como es una función de autocompletar y el usuario comienza con un carácter (y hay resultados que son de hecho 1 longitud de caracteres), no puedo restringir la longitud del texto de búsqueda.

El código es más o menos:

var symbolCodeTopDocs = searcher.Search(new PrefixQuery(new Term("SymbolCode", searchText), 10);

SymbolCode es un campo NOT_ANALYZED. La versión de Lucene.NET es 3.0.3.

El ejemplo está simplificado, y podría tener que usar BooleanQuery para aplicar restricciones adicionales en un escenario del mundo real.

¿Cómo puedo mejorar el rendimiento en este caso específico? Estas consultas de un solo carácter o de dos caracteres están reduciendo el servidor.

Answer 1

Considere eliminar las palabras de suspensión de su índice si aún no lo ha hecho.

Para comprender cómo las palabras de detención reducen la velocidad de PrefixQuery, considere cómo funciona PrefixQuery: se reescribe como una BooleanQuery que incluye cada término del índice que comienza con el término PrefixQuery. Por ejemplo, a* convierte a OR and OR aardvark OR anchor OR ... Hasta ahora, esto no está mal y funcionará sorprendentemente bien incluso con miles de términos. El verdadero inconveniente es cuando se incluyen las palabras stop como a yy porque es probable que se encuentren varias veces en cada uno de los documentos de su índice. Esto crea mucho más trabajo para la parte de recopilación / recopilación / puntuación de la búsqueda y, por lo tanto, ralentiza las cosas.

En una nota lateral, recomiendo no ejecutar la búsqueda de autocompletar cuando el usuario ha ingresado menos de 2 o 3 caracteres, simplemente desde una perspectiva de usabilidad. No puedo imaginar que los resultados sean relevantes. Imagine ejecutar una búsqueda por a* : no hay forma de decir qué resultados son más relevantes. Si debe mostrar algo al usuario, considere un enfoque de n-gramas como lo sugirió Jf Beaulac en los comentarios.