ElasticSearch replicação de outros dados do sistema?

Suponha que eu queira usar o elasticsearch para implementar uma pesquisa genérica em um site. Espera-se que a barra de pesquisa superior encontre resources de todos os tipos diferentes no site. Documentos com certeza (carregados / indexados via tika), mas também coisas como clientes, contas, outras pessoas, etc.

Por razões de arquitetura, a maior parte do material não documentado (clientes, contas) existirá em um database relacional.

Ao implementar essa pesquisa, a opção nº 1 seria criar versões de documento de tudo e usar o elasticsearch para executar todos os aspectos da pesquisa, não confiando no database relacional para encontrar diferentes tipos de objects.

A opção 2 seria usar o elasticsearch apenas para indexar os documentos, o que significaria, para um recurso geral de “pesquisa no site”, a necessidade de agrupar várias pesquisas em vários sistemas e agregar os resultados antes de retorná-los.

A opção nº 1 parece muito superior, mas a desvantagem é que ela exige que a pesquisa elástica tenha essencialmente uma cópia de muitas coisas no database relacional de produção, além de que essas cópias sejam mantidas atualizadas à medida que as coisas mudam.

Qual é a melhor opção para manter essas lojas em sincronia, e estou correto em pensar que, para a pesquisa geral, a opção 1 é superior? Existe uma opção # 3?

Você listou as duas principais opções existentes quando se trata de pesquisar em vários armazenamentos de dados, ou seja, pesquisar em um armazenamento de dados central (opção 1) ou pesquisar em todos os armazenamentos de dados e agregar os resultados (opção 2).

Ambas as opções funcionariam, embora a opção 2 tenha duas principais desvantagens:

  1. Isso exigirá que uma quantidade substancial de lógica seja desenvolvida em seu aplicativo para “expandir” as pesquisas para os vários armazenamentos de dados e agregar os resultados que você recebe de volta.
  2. Os tempos de resposta podem ser diferentes para cada armazenamento de dados e, portanto, você terá que aguardar que o armazenamento de dados mais lento responda para apresentar os resultados da pesquisa ao usuário (a menos que você contorne isso usando diferentes tecnologias assíncronas, como Ajax , websocket, etc)

Se você deseja fornecer uma experiência de pesquisa melhor e mais confiável, a opção nº 1 claramente ganha meu voto (na verdade, eu uso isso na maioria das vezes). Como você afirmou corretamente, a principal “desvantagem” desta opção é que você precisa manter o Elasticsearch em sincronia com as mudanças em seus outros armazenamentos de dados principais.

Como seus outros armazenamentos de dados serão bancos de dados relacionais, você tem algumas opções diferentes para mantê-los em sincronia com o Elasticsearch, a saber:

  • Usando a Entrada Logstash JDBC
  • usando a ferramenta de importação JDBC

Essas duas primeiras opções funcionam muito bem, mas têm uma desvantagem principal, ou seja, elas não capturam DELETEs na sua tabela, elas só capturarão INSERTs e UPDATEs. Isso significa que, se você excluir um usuário, conta, etc., não poderá saber que precisa excluir o documento correspondente no Elasticsearch. A menos, claro, que você decida excluir o índice do Elasticsearch antes de cada session de importação.

Para aliviar isso, você pode usar outra ferramenta que se baseia no log binário do MySQL e será capaz de capturar todos os events. Há um escrito em Go , um em Java e outro em Python .