Репликация Elasticsearch других системных данных?

Предположим, что я хочу использовать elasticsearch для реализации общего поиска на веб-сайте. Ожидается, что в верхней строке поиска будут найдены ресурсы всех видов по всему сайту. Документы (загруженные/индексированные через tika), но также такие вещи, как клиенты, учетные записи, другие люди и т.д.

По соображениям архитектуры большинство материалов без документов (клиенты, учетные записи) будут существовать в реляционной базе данных.

При реализации этого поиска параметр # 1 должен был бы создавать версии документов всего, а затем просто использовать elasticsearch для запуска всех аспектов поиска, не полагаясь вовсе не на реляционную базу данных для поиска различных типов объектов.

Вариант № 2 должен был бы использовать elasticsearch только для индексации документов, что означало бы для общей функции поиска по сайту, вам придется обрабатывать несколько запросов для нескольких систем, а затем агрегировать результаты перед их возвратом.

Вариант №1 кажется намного превосходен, но недостатком является то, что он требует, чтобы эластичный поиск по существу имел копию большого количества вещей в производственной реляционной базе данных, плюс, чтобы эти копии были свежими, поскольку все меняется.

Какой лучший вариант для хранения этих магазинов в синхронизации, и правильно ли я полагаю, что для общего поиска опция № 1 превосходит? Есть ли вариант № 3?

Ответ 1

Вы в значительной степени перечислили две основные опции, которые существуют, когда речь идет о поиске по нескольким хранилищам данных, то есть поиск в одном центральном хранилище данных (опция # 1) или поиск во всех хранилищах данных и агрегирование результатов (опция # 2).

Оба варианта будут работать, хотя вариант № 2 имеет два основных недостатка:

В вашем приложении потребуется значительное количество логики, чтобы "разветвлять" результаты поиска по нескольким хранилищам данных и объединять полученные результаты.
Время отклика может быть разным для каждого хранилища данных, и поэтому вам придется ждать, пока самое медленное хранилище данных ответит, чтобы представить результаты поиска пользователю (если вы не обойдете это с помощью различных асинхронных технологий, таких как Ajax, веб-сокет и т.д.)

Если вы хотите обеспечить более качественный и надежный опыт поиска, вариант № 1, несомненно, получит мой голос (на самом деле, я использую этот способ в большинстве случаев). Как вы правильно заявили, основным "недостатком" этого параметра является необходимость синхронизации Elasticsearch с изменениями в других ваших хранилищах основных данных.

Поскольку ваши другие хранилища данных будут реляционными базами данных, у вас есть несколько различных вариантов синхронизации их с Elasticsearch, а именно:

используя вход Logstash JDBC
используя инструмент импорта JDBC

Эти первые два варианта работают отлично, но имеют один главный недостаток, то есть они не фиксируют УДАЛЕНИЯ на вашей таблице, они только фиксируют ВСТАВКИ и ОБНОВЛЕНИЯ. Это означает, что если вы когда-либо удаляете пользователя, учетную запись и т.д., Вы не сможете узнать, что вам нужно удалить соответствующий документ в Elasticsearch. Если, конечно, вы не решите удалять индекс Elasticsearch перед каждым сеансом импорта.

Чтобы облегчить это, вы можете использовать другой инструмент, который основан на binlog MySQL и, таким образом, сможет захватывать каждое событие. Там один написан на Go, один на Java и один на Python.

ОБНОВИТЬ:

Вот еще одна интересная статья в блоге на эту тему: Как синхронизировать Elasticsearch с реляционной базой данных с помощью Logstash