Database 用于消息传递系统的消息存储复制

在许多消息传递应用程序的子系统设计（twitter、facebook e.t.c）中，我注意到用户消息历史记录的存储位置重复。另一方面，他们使用象ElasticSeach或Solr这样的标记索引器。这对搜索很有好处。另一方面，仍然使用某种类型的数据库作为历史记录。为什么要复制？为什么ES/Solr/EarlyBird的同一个实例不能用于历史？事实上，它是可以的。

通常的问题是以下几点-您想要搜索，理想情况下您想要以不同的方式尝试索引数据（例如，擦除索引并尝试新的awesome analyzer，您最初忘了包括它）。将数据源和索引彼此分离可以减少系统的耦合。您不必担心，您将在Elasticsearch/Solr中丢失数据

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

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

---

总结很简单-Elasticsearch/Solr应该更多地被认为是一个搜索引擎，而不是数据存储。

没错，ES本身不是一个数据库，也永远不会是。但是，很多人确实这样做了。这实际上取决于您的特定用例，最终这都是一个您为支持您的特定需求而准备进行权衡的问题。与几乎所有的技术一样，没有一刀切的方法，ES（以及类似的）也没有什么不同

事实的主要来源可能不一定是关系型DBMS，也不一定是“复制”数据。您的意思是，它可以是任何具有数据副本的数据，并允许您在出现问题时重建ES索引。我见过许多不同的“真相来源”。它可以是：

• 包含历史日志或业务数据的原始平面文件
• 卡夫卡主题，您可以随时轻松重播
• 定期从ES获取的快照
• 关系数据库
• 你说得对

关键是，如果由于任何原因出现问题（并且发生了这种情况），您希望能够重新创建ES索引，无论是从真实的数据库、备份还是原始数据。你应该把它看作一张安全网。即使您只有一个MySQL数据库，您通常也有它的备份，因此您已经以某种方式“复制”了数据

不过，在设计系统架构时，您需要考虑的一件事是，您可能不一定需要将所有数据都存储在ES中，因为ES是一个搜索和分析引擎，您应该只在其中存储支持您的搜索和分析需求所需的信息，并且可以随时重新创建该信息。最后，ES只是整个体系结构的一个子系统，就像数据库、消息队列或web服务器一样

---

也值得一读：

谢谢你的回答！我希望ES/Solr的作者认真对待所有这些因素（非常重要的因素），除非他们打算留在没有数据库的区域，因为这确实是大量数据的重复。关于原始文本的交易，顺便说一句，如果需要的话，我觉得需要重新考虑设计，但谁知道…@user1439579为了公平起见，我不确定他们是否应该这样做。Elasticsearch/Solr有自己的定位，不想成为一切，这很好，但从客户的角度来看，他们应该将资源翻一番谢谢，你的分析非常出色！还有一点：你提到重播卡夫卡主题。你认为卡夫卡的完整历史商店在这种情况下是一种很好的做法吗？酷，很高兴它有帮助！是的，在某些情况下，在卡夫卡主题中包含完整的原始数据可能非常有意义，您可以轻松地重播。