jesterj
1.0.0
Un sistema de ingesta de documentos altamente flexible, escalable y tolerante a fallas diseñado para búsqueda.
Las construcciones se ejecutan en infraestructura amablemente donada por
Con frecuencia, los proyectos de búsqueda comienzan alimentando algunos documentos manualmente a un motor de búsqueda, a menudo a través de las funciones de procesamiento integradas "solo para prueba" de Solr, como SolrCell o post.jar. Estas funciones están documentadas e incluidas para ayudar al usuario a tener una idea de lo que puede hacer con Solr con una configuración mínima y complicada.
Esto es bueno y así debería ser en las primeras exploraciones. Desafortunadamente, también es una trampa potencial.
Con demasiada frecuencia, los usuarios que no conocen nada mejor y quizás se sienten engañados por el hecho de que estas interfaces están documentadas en el manual de referencia (y asumen que todo lo documentado debe ser "la forma correcta" de hacerlo) continúan desarrollando su sistema de búsqueda. automatizando el uso de esas mismas interfaces. Para ser justos con esos usuarios, algunas versiones anteriores de la guía Solr Ref no lograron identificar la naturaleza "sólo para probar" de la interfaz, a veces porque a la comunidad le tomó un tiempo darse cuenta de los peligros asociados con ella.
Desafortunadamente, la ingesta a gran escala de documentos para búsqueda no es trivial y esas interfaces de indexación no están diseñadas para uso en producción. El resultado habitual es que funciona "bien" para un corpus de prueba pequeño y luego se vuelve inestable en un corpus de producción más grande. El código escrito para alimentar dichas interfaces a menudo debe repetirse para varios tipos de documentos o para varios formatos de documentos, y puede conducir fácilmente a la duplicación y a la copia de funciones comunes. Además, después de invertir una cantidad sustancial de ingeniería para que dichas soluciones funcionen en un corpus grande, lo siguiente que descubren es que no tienen forma de recuperarse si la indexación falla a mitad de camino. En los peores casos, la falla está relacionada con el tamaño del corpus y las fallas se vuelven cada vez más comunes a medida que el corpus crece hasta que la posibilidad de completar y ejecutar la indexación es pequeña y el sistema finalmente no se puede indexar ni actualizar en absoluto si se permite el problema. para pudrirse. El resultado es una serie de dolores de crecimiento terribles, dolorosos y potencialmente costosos.
JesterJ se esfuerza por facilitar el inicio con una infraestructura de indexación sólida y completa, para que no tengas que reinventar la rueda. JesterJ está destinado a ser un sistema que no necesitará abandonar hasta que esté trabajando con una cantidad extremadamente grande de documentos (¡y con suerte, en ese momento ya estará obteniendo buenas ganancias que puedan pagar una gran solución personalizada!). Se proporciona una variedad de componentes de procesamiento reutilizables y escribir sus propios procesadores personalizados es tan simple como implementar una interfaz de 4 métodos siguiendo algunas pautas simples.
A menudo, la primera versión de un sistema para indexar documentos en Solr u otro motor de búsqueda es bastante lineal y sencilla, pero a medida que pasa el tiempo, las funciones y mejoras suelen añadir complejidad. Otras veces, el sistema es complejo desde el principio, posiblemente porque la búsqueda se está agregando a un sistema existente. JesterJ está diseñado para manejar escenarios de indexación complejos. Considere el siguiente flujo de trabajo de indexación hipotético:
JesterJ maneja estos escenarios con un único plan de procesamiento centralizado y se asegurará de que si el sistema se desconecta, no recibirá un segundo mensaje sobre un pedido recibido. El modo predeterminado de JesterJ es garantizar la entrega como máximo una vez para los pasos que no están marcados como seguros o idempotentes. Los pasos seguros no tienen efectos externos y los pasos idempotentes pueden repetirse en el camino hasta el punto final del procesamiento.
Consulte el sitio web y la documentación para obtener más información.
Por favor consulte la documentación en la wiki.
Versión actual : 1.0-Beta3. Esta es la mejor versión para usar y debería ser en su mayoría funcional. (problema conocido: #189)
Próxima versión: 1.0-Beta4 se publicará pronto si no se encuentran problemas graves dentro de dos semanas. Se lanzará 1.0.
NOTA: El código actual y la próxima versión 1.0 apuntan a cualquier diseño y carga que pueda ser atendido por una sola máquina. JesterJ está diseñado explícitamente para aprovechar máquinas con muchos procesadores. Puede diseñar su plan con duplicados de su paso más lento para aliviar los cuellos de botella. Cada duplicado implica un hilo adicional trabajando en ese paso. El escalado automático de subprocesos está previsto para la versión 1.1 y el escalado en muchas máquinas es una prioridad clave para las versiones 2.x. Como siempre, si desea estas funciones antes, inicie una discusión y contribuya con un PR si puede.
Actualmente sólo se ha probado periódicamente JDK 11. Cualquier distribución de JDK 11 debería funcionar. Está prevista la compatibilidad con Java 17 y futuras versiones LTS para futuras versiones.
Discuta características, haga preguntas, etc. en Discord: https://discord.gg/RmdTYvpXr9
En esta versión tenemos las siguientes características.
~/.jj/cassandraLa versión 1.0 está pensada para ser utilizable en sistemas de un solo nodo y, por lo tanto, adecuada para su uso en proyectos pequeños y medianos (decenas de millones o tal vez cientos de millones de documentos).
La mejor suposición en cualquier momento de lo que habrá en futuras versiones la dan los filtros de hitos en nuestra página de problemas.
