Intenté originalmente publicar una publicación similar en la lista de correo elasticsearch (https://groups.google.com/forum/?fromgroups=#!topic/elasticsearch/BZLFJSEpl78) pero no obtuve ninguna respuesta útil, así que pensé en intentar probar Stack Overflow. Esta es mi primera publicación en SO, así que le pido disculpas si no encaja del todo en el molde al que está destinado.Personalizando el algoritmo de búsqueda de Elasticsearch
Actualmente estoy trabajando con una universidad ayudándolos a implementar un conjunto de pruebas para refinar aún más algunas investigaciones que han estado llevando a cabo. Su investigación se basa en la búsqueda dinámica de esquemas. Después de pasar algún tiempo evaluando las diversas soluciones de búsqueda de código abierto, decidí usar elasticsearch como plataforma base y me pregunto cuál sería la mejor manera de proceder. He pasado aproximadamente una semana investigando la documentación de búsqueda elástica y el código en sí y también leyendo la documentación de Lucene, pero estoy luchando por ver un camino claro hacia adelante.
El objetivo del proyecto es proporcionar a las investigaciones una pieza de software que puedan usar para completar las revisiones del algoritmo de búsqueda para probar y refinar. Les gustaría poder escribir el algoritmo enchufable en otros lenguajes además de Java que sea compatible con la JVM como Groovy, Python o Closure, pero ese no es un requisito difícil. Parte de eso será proporcionarles una interfaz para ejecutar consultas y ver resultados y una interfaz de administrador para agregar documentos a un índice. Me siento cómodo con todo eso gracias a la muy poderosa y completa API REST. De lo que no estoy tan seguro es de cómo proceder con la implementación del algoritmo de búsqueda conectable.
algoritmo del investigador requiere 4 entradas a la función:
- Los términos de la consulta (s).
- A Palabra (término) x Matriz del documento en un índice.
- Una matriz de documento x Word (término) en un índice.
- Una lista de frecuencia de palabras (término) en un índice. Esa es la cantidad de veces que aparece cada palabra en todo el índice.
Para sus propósitos, un documento no corresponde a un documento real del mundo real (en realidad los llaman eventos de texto). Por el contrario, por ahora, corresponde a una oración (tener ese configurable también podría ser útil). Me imagino que la mejor manera de manejar esto es dividir documentos en sus oraciones (usando Apache Tika o algo similar), poniendo cada oración como su propio documento en el índice. Estoy seguro de que puedo hacer esto en la interfaz de usuario de administración que proporciono utilizando el complemento mapper-attachement como punto de partida. El inconveniente es que dividir el documento antes de dárselo a elasticsearch no es una forma muy configurable de hacerlo. Si quieren cambiar la resolución a su algoritmo, tendrían que volver a agregar todos los documentos al índice. Si el índice almacenara los documentos completos tal como están y el algoritmo de búsqueda pudiera elegir qué resolución trabajar en cada consulta, sería perfecto. Sin embargo, no estoy seguro si es posible o no.
El siguiente problema es cómo obtener las tres entradas que requieren y pasarlas a su algoritmo de búsqueda conectable. Realmente estoy luchando por dónde empezar con este. Al mirar a Luecene, parece que necesito proporcionar mi propia implementación de búsqueda/consulta, pero no estoy seguro de si esto es correcto o no. Tampoco parece haber ningún complemento de búsqueda en el sitio elasticsearch, por lo que ni siquiera estoy seguro de si es posible. Lo importante aquí es que el algoritmo necesita operar en el nivel de índice con los términos de consulta disponibles para generar su esquema antes de usar el esquema para calificar cada documento en el índice. Por lo que puedo decir, esto significa que la interfaz de scripting proporcionada por elasticsearch no será de ninguna utilidad. La descripción de la interfaz de scripting en la guía elasticsearch hace que suene como un script que funciona en el nivel de documento y no en el nivel de índice.Otras preocupaciones/consideraciones son la capacidad de programar este algoritmo en una variedad de idiomas (al igual que la interfaz de scripting) y la capacidad de aumentar lo que devuelve la API REST para una búsqueda para incluir el esquema generado por el algoritmo (que supongo que significa Tendré que definir mi propio (s) punto (s) REST (s)).
¿Alguien puede darme algunos consejos sobre dónde comenzar aquí? Parece que tendré que escribir mi propio complemento de búsqueda que pueda aceptar scripts ya que es el algoritmo central. El complemento será responsable de organizar las 4 entradas que describí anteriormente antes de pasar el control al script. También será responsable de obtener el resultado del script y devolverlo a través de su propia API REST. ¿Esto parece lógico? Si es así, ¿cómo empiezo a hacer esto? ¿Qué partes del código necesito para mirarlo?