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

Question

Во многих проектах подсистем для приложений обмена сообщениями (twitter, facebook e.t.c) я замечаю дублирование того, где хранится история сообщений пользователя. С другой стороны, они используют индексатор токенов, такой как ElasticSeach или Solr. Это хорошо для поиска. С другой стороны до сих пор используют какую-то БД для истории. Зачем дублировать? Почему один и тот же экземпляр ES / Solr / EarlyBird нельзя использовать для истории? Это на самом деле может.

Answer 1

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

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

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

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

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

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

Answer 2

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

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

И последнее, но не менее важное: одна из самых сложных операций в Elasticsearch / Solr - это получение сохраненных значений, так как это не слишком оптимизировано для этого, особенно если вы хотите вернуть документы размером 10 тыс. Сразу. В этом случае также поможет отдельный источник данных, поскольку вы сможете вернуть только соответствующий документ идентификаторы из Elasticsearch / Solr, а затем получить необходимый контент из источника данных и вернуть его пользователю.

Сводка проста - Elasticsearch / Solr следует больше рассматривать как поисковые системы, а не как хранилище данных.