消息系统的消息存储复制答案

【问题标题】：Message storage duplication for messaging systems消息系统的消息存储复制
【发布时间】：2023-03-17 12:05:02
【问题描述】：

在消息应用程序（twitter、facebook 等）的许多子系统设计中，我注意到存储用户消息历史记录的位置存在重复。另一方面，他们使用 ElasticSeach 或 Solr 等标记化索引器。很适合搜索。另一方面，仍然使用某种数据库来记录历史。为什么要复制？为什么 ES/Solr/EarlyBird 的同一个实例不能用于历史？其实是可以的。

【问题讨论】：

标签： database elasticsearch solr architecture system-design

【解决方案1】：

通常的问题如下 - 您想要搜索并且理想情况下您想要以不同的方式尝试索引数据（例如擦除索引并尝试新的 awesome 分析器，您最初忘记包含）。将数据源和索引相互分离，降低了系统耦合度。你不怕，你会丢失 Elasticsearch/Solr 中的数据。

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

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

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

【讨论】：

感谢您提供有用的答案！我希望 ES/Solr 作者认真对待所有这些因素（非常重要的因素），除非他们打算留在无 DB 领域，因为这确实是大量数据的重复。关于原始文本的交易，顺便说一句，如果有人需要，我觉得需要重新考虑设计，但谁知道......
@user1439579 公平地说，我不确定他们是否应该这样做。 Elasticsearch/Solr 有自己的定位，而不是试图成为一切，这很好
但从客户的角度来看，他们应该将资源翻倍

【解决方案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

【讨论】：

谢谢您，您的分析非常出色！还有一点：您提到了重播 Kafka 主题。您认为 Kafka 中的完整历史存储在这种情况下是一种好的做法吗？
酷，很高兴它有帮助！是的，在某些情况下，在 Kafka 主题中拥有完整的原始数据可能非常有意义，您可以轻松地重播。