Дублирование хранилища сообщений для систем обмена сообщениями

Верно то, что ES НЕ является базой данных как таковой и никогда ею не будет. Но никто не говорит, что вы не можете использовать его как таковой, и многие действительно так делают. Это действительно зависит от вашего конкретного варианта использования, и, в конце концов, все зависит от компромиссов, на которые вы готовы пойти, чтобы удовлетворить свои конкретные потребности. Как и в случае почти любой технологии в целом, не существует универсального подхода, и с ES (и ему подобными) все в порядке.

Первичным источником правды может быть не обязательно реляционная СУБД, и они не обязательно «дублируют» данные в том смысле, в каком вы имели в виду, это может быть все, что имеет копию ваших данных и позволяет вам перестроить ваши индексы ES в случае что-то идет не так. Я видел много-много разных "источников правды". Это может быть просто:

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

Дело в том, что если по какой-либо причине что-то пойдет не так (а такое случается), вы захотите иметь возможность воссоздать свои индексы ES, будь то из реальной БД, из резервных копий или из необработанных данных. Вы должны рассматривать это как подстраховку. Даже если все, что у вас есть, это база данных MySQL, у вас обычно есть ее резервная копия, поэтому вы уже каким-то образом «дублируете» данные.

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

Также стоит прочитать: Использование ElasticSeach в качестве основного источник части моей БД

Обычная проблема заключается в следующем: вы хотите выполнить поиск, а в идеале попробовать проиндексировать данные другим способом (например, стереть индекс и попробовать новый отличный анализатор, который вы изначально забыли включить). Разделение источника данных и индекса друг от друга делает систему менее связанной. Вы не боитесь, что потеряете данные в Elasticsearch/Solr.

Обычно я категорически против того, чтобы называть Elasticsearch/Solr базой данных. Поскольку на самом деле это не. Например, ни один из них не поддерживает транзакции, что усложняет вашу жизнь, если вы хотите обновить несколько документов, следуя стандартной реляционной логике.