消息传递系统的消息存储副本

Question

在许多用于消息传递应用程序的子系统设计中（Twitter，Facebook等），我注意到用户消息历史记录的存储位置重复。另一方面，他们使用令牌化索引器，例如ElasticSeach或Solr。这对搜索很有用。另一方面，仍使用某种数据库进行历史记录。为什么要重复？为什么不能将ES / Solr / EarlyBird的同一实例用于历史记录？实际上可以。

Answer 1

以下是常见的问题-您想要搜索，理想情况下还希望以其他方式尝试索引数据（例如，擦除索引并尝试新的 awesome分析器，而您最初忘记包括在内） ）。将数据源和索引彼此分开会使系统耦合度降低。您不必担心，您会丢失 Elasticsearch / Solr 中的数据。

我通常强烈反对将 Elasticsearch / Solr 称为数据库。实际上，它不是不是。例如，它们都不支持transactions，如果您要按照标准关系逻辑更新多个文档，则会使您的工作更加困难。

最后但并非最不重要的-在 Elasticsearch / Solr 中最困难的操作之一是检索存储的值，因为这样做并没有太多优化，特别是如果您想一次返回10k文档。在这种情况下，单独的数据源也将有所帮助，因为您将只能从Elasticsearch / Solr返回匹配文档 id ，然后从数据源检索所需的内容并将其返回给用户。

摘要非常简单- Elasticsearch / Solr 应该更多地视为搜索引擎，而不是数据存储。

Answer 2

可以肯定的是ES本身不是数据库，也永远不会是数据库。但是no one says you cannot use it as such确实有很多人这样做。这实际上取决于您的特定用例，最后，这完全是您准备进行权衡以支持您的特定需求的问题。与一般的几乎所有技术一样，没有一种千篇一律的方法，而ES（或类似技术）也没有什么不同。

真理的主要来源不一定是关系型DBMS，也不一定是按照您的意思“复制”数据，它可以是任何具有数据副本并允许您重建ES的东西。索引，以防出现问题。我已经看到许多不同的“真理来源”。可能只是：

• 包含您的历史日志或业务数据的原始平面文件
• 您可以随时轻松重播的Kafka主题
• 您定期从ES获取的快照
• 关系数据库
• 您给它起名字...

关键是，如果由于某种原因（发生这种情况）出错，您希望能够从真实的数据库，备份或原始数据中重新创建ES索引。您应该将其视为安全网。即使您只拥有一个MySQL数据库，也通常会对其进行备份，因此您已经在某种程度上“复制”了数据。

但是，在架构系统时，您需要考虑的一件事是，由于ES是搜索和分析引擎，因此您不一定需要将所有数据都存储在ES中，因为您应该将其存储在那里需要什么来满足您的搜索和分析需求，并能够随时重新创建该信息。最后，ES只是整个体系结构的子系统，就像您的数据库，消息传递队列或Web服务器一样。

也值得一读：Using ElasticSeach as primary source for part of my DB