Хорошая практика между SQL и elasticsearch

Question

Представьте, что у вас есть база данных SQL, такая как mysql или postgresql. У вас есть две таблицы: пользователь и автомобиль. Один пользователь может управлять N автомобилями, автомобиль может управляться N пользователями, поэтому у вас есть третья таблица «дисков» с двумя внешними ключами.

Теперь вы хотите, чтобы пользователь вашего стола продолжал поиск elasticsearch, потому что вы хотите, чтобы пользователи искали по имени, электронной почте ... и т. Д. Возможно, вам также нужно выполнить поиск на автомобильном столе.

Я вижу три пути для достижения этой цели, я Поверенный хотел бы знать, что это лучший способ:

1) Покиньте базу данных SQL. Все ваши таблицы теперь находятся в поиске elastics. Вы можете выполнять поиск по своему желанию, но вы должны обрабатывать все свои ограничения вручную.

2) Сохраните структуру базы данных sql, вы сохраните три таблицы, первичные ключи и внешние ключи. Но ваши таблицы содержат только идентификатор elasticsearch соответствующей строки в elasticsearch. Например, в пользователе таблицы вы сохраняете user_id и добавляете user_elasticsearch_id, указывающий на строку elasticsearch, где вы нашли имя, адрес электронной почты ... и т. Д. Итак, у вас есть ограничения на sql, вы можете выполнять поиск, но вы должны поддерживать два стола.

3) Повторяющийся. Вы не трогаете свою базу данных sql, вы дублируете все строки в базе данных elasticsearch. У вас есть свои ограничения, вы можете искать, но снова вы должны поддерживать две таблицы, и у вас есть вдвое больше данных и в два раза больше памяти.

Теперь, смелый человек из stackoverflow, что бы вы сделали в этом случае?

спасибо.

Answer 1

Поскольку у вас может быть много бизнес-правил, смешанных с вашей базой данных и приложениями, использующими его, я был бы консервативным и поддерживал бы БД. И используйте ES для индексации пользовательских атрибутов, которые я хочу найти. ES вернет забитые результаты. Когда результат будет выбран, я бы переключился на БД, чтобы получить всю информацию и отношения.

Так что я бы выбрал 2b: сохранить БД и хранить ПК в ES, а не ID в БД).

Имейте в виду, что вы можете заставить ID en ES. Это может быть «user_PK» или что-то подобное.

Answer 2

Наиболее распространенная установка для критически важных бизнес-данных имеет, например, база данных SQL в качестве основного хранилища данных и Elasticsearch в качестве дополнительного индекса поиска. (= ваше решение 3).

Альтернатива для критически важных для бизнеса данных, таких как журналы и т. Д., Имеет автономный Elasticsearch.

Решение 2 кажется проводным, это не вариант для меня.