¿Elasticsearch replicación de otros datos del sistema?

Supongamos que quiero usar elasticsearch para implementar una búsqueda genérica en un sitio web. Se esperaría que la barra de búsqueda superior encuentre recursos de todo tipo en todo el sitio. Documentos seguros (subidos / indexados a través de tika) pero también cosas como clientes, cuentas, otras personas, etc.

Por razones arquitectónicas, la mayoría de las cosas que no son documentos (clientes, cuentas) existirán en una base de datos relacional.

Al implementar esta búsqueda, la opción n. ° 1 sería crear versiones de documentos de todo, y luego usar elasticsearch para ejecutar todos los aspectos de la búsqueda, sin depender en absoluto de la base de datos relacional para encontrar diferentes tipos de objetos.

La opción n. ° 2 sería usar elasticsearch solo para indexar los documentos, lo que significaría para una función general de “búsqueda de sitios”, tendría que asignar múltiples búsquedas a múltiples sistemas y luego agregar los resultados antes de devolverlos.

La opción n. ° 1 parece muy superior, pero la desventaja es que requiere que la búsqueda elástica en esencia tenga una copia de muchas cosas en la base de datos relacional de producción, además de que esas copias se mantengan frescas a medida que cambian las cosas.

¿Cuál es la mejor opción para mantener estas tiendas sincronizadas, y estoy en lo cierto al pensar que para la búsqueda general, la opción n. ° 1 es superior? ¿Hay una opción n. ° 3?

Ha enumerado prácticamente las dos principales opciones que existen cuando se trata de buscar en varios almacenes de datos, es decir, buscar en un almacén de datos central (opción n. ° 1) o buscar en todos los almacenes de datos y agregar los resultados (opción n. ° 2).

Ambas opciones funcionarían, aunque la opción n. ° 2 tiene dos inconvenientes principales:

  1. Se requerirá una gran cantidad de lógica para desarrollar en su aplicación a fin de “ramificar” las búsquedas en los múltiples almacenes de datos y agregar los resultados que obtiene.
  2. Los tiempos de respuesta pueden ser diferentes para cada almacén de datos y, por lo tanto, deberá esperar a que el almacén de datos más lento responda para presentar los resultados de búsqueda al usuario (a menos que evite esto utilizando diferentes tecnologías asíncronas, como Ajax). , websocket, etc.)

Si desea proporcionar una experiencia de búsqueda mejor y más confiable, la opción n. ° 1 claramente obtendría mi voto (de hecho, la mayoría de las veces lo hago de esta manera). Como ha indicado correctamente, el principal “inconveniente” de esta opción es que necesita mantener Elasticsearch sincronizado con los cambios en sus otros almacenes de datos maestros.

Como sus otras tiendas de datos serán bases de datos relacionales, tiene algunas opciones diferentes para mantenerlas sincronizadas con Elasticsearch, a saber:

  • usando la entrada Logstash JDBC
  • usando la herramienta de importación JDBC

Estas dos primeras opciones funcionan estupendamente pero tienen una desventaja principal, es decir, no capturan DELETE en su tabla, solo capturarán INSERT y UPDATE. Esto significa que si alguna vez elimina un usuario, cuenta, etc., no podrá saber que tiene que eliminar el documento correspondiente en Elasticsearch. A menos que, por supuesto, decida eliminar el índice Elasticsearch antes de cada sesión de importación.

Para aliviar esto, puede usar otra herramienta que se basa en el binlog de MySQL y así podrá capturar cada evento. Hay uno escrito en Go , uno en Java y otro en Python .