消息系统的消息存储复制
Message storage duplication for messaging systems
在消息传递应用程序（twitter、facebook e.t.c）的许多子系统设计中，我注意到用户消息历史记录存储位置的重复。另一方面，他们使用像 ElasticSeach 或 Solr 这样的标记索引器。这对搜索有好处。另一方面，仍然使用某种数据库来记录历史。为什么要复制？为什么 ES/Solr/EarlyBird 的同一个实例不能用于历史记录？其实是可以的。
通常的问题如下 - 您想要搜索并且理想情况下您想要以不同的方式尝试索引数据（例如擦除索引并尝试新的 awesome analyzer，即你忘了最初包括）。将数据源和索引彼此分离可以降低系统的耦合度。你不怕，你会丢失 Elasticsearch/Solr.
中的数据
我通常强烈反对将Elasticsearch/Solr称为数据库。因为事实上，它是 而不是 。例如 none 支持 transactions，如果您想按照标准关系逻辑更新多个文档，这会让您的生活变得更加艰难。
最后但并非最不重要的一点 - Elasticsearch/Solr 中最难的操作之一是检索存储的值，因为它没有优化到这样做，特别是如果你想一次 return 10k 个文档。在这种情况下，单独的数据源也会有所帮助，因为您将能够 return 仅 匹配 文档 ids 来自 Elasticsearch/Solr然后从数据源中检索所需的内容，然后 return 将其提供给用户。
总结很简单 - Elasticsearch/Solr 应该更多地认为是搜索引擎，而不是数据存储。
没错，ES 本身不是数据库，而且永远不会。但是no one says you cannot use it as such，而且很多人确实这样做了。这实际上取决于您的具体用例，最终这完全取决于您为支持您的特定需求而准备做出的权衡。与一般的几乎所有技术一样，没有一种放之四海而皆准的方法，对于 ES（以及类似技术）来说也不例外。
真实的主要来源不一定是关系 DBMS，它们不一定是 "duplicating" 您所指意义上的数据，它可以是任何具有您的数据副本并允许您重建你的 ES 索引以防出现问题。我见过很多很多不同的 "sources of truth"。它可以简单地是：
- 包含历史日志或业务数据的原始平面文件
- Kafka主题，随时轻松回放
- 您定期从 ES 获取的快照
- 关系数据库
- 你的名字...
关键是，如果由于任何原因出现问题（并且发生了这种情况），您希望能够重新创建 ES 索引，无论是来自真实数据库、备份还是原始数据。您应该将其视为安全网。即使您只有一个 MySQL 数据库，您通常也有它的备份，所以在某种程度上您已经是 "duplicating" 数据了。
不过，在构建系统时，您需要考虑的一件事是，您可能不一定需要在 ES 中拥有全部数据，因为 ES 是一个搜索和分析引擎，您应该只在那里存储支持您的搜索和分析需求所需的内容，并能够随时重新创建该信息。最后，ES 只是您整个架构的一个子系统，就像您的数据库、消息队列或 Web 服务器一样。
还值得一读：
在消息传递应用程序（twitter、facebook e.t.c）的许多子系统设计中，我注意到用户消息历史记录存储位置的重复。另一方面，他们使用像 ElasticSeach 或 Solr 这样的标记索引器。这对搜索有好处。另一方面，仍然使用某种数据库来记录历史。为什么要复制？为什么 ES/Solr/EarlyBird 的同一个实例不能用于历史记录？其实是可以的。
通常的问题如下 - 您想要搜索并且理想情况下您想要以不同的方式尝试索引数据（例如擦除索引并尝试新的 awesome analyzer，即你忘了最初包括）。将数据源和索引彼此分离可以降低系统的耦合度。你不怕，你会丢失 Elasticsearch/Solr.
中的数据我通常强烈反对将Elasticsearch/Solr称为数据库。因为事实上，它是 而不是 。例如 none 支持 transactions，如果您想按照标准关系逻辑更新多个文档，这会让您的生活变得更加艰难。
最后但并非最不重要的一点 - Elasticsearch/Solr 中最难的操作之一是检索存储的值，因为它没有优化到这样做，特别是如果你想一次 return 10k 个文档。在这种情况下，单独的数据源也会有所帮助，因为您将能够 return 仅 匹配 文档 ids 来自 Elasticsearch/Solr然后从数据源中检索所需的内容，然后 return 将其提供给用户。
总结很简单 - Elasticsearch/Solr 应该更多地认为是搜索引擎，而不是数据存储。
没错，ES 本身不是数据库，而且永远不会。但是no one says you cannot use it as such，而且很多人确实这样做了。这实际上取决于您的具体用例，最终这完全取决于您为支持您的特定需求而准备做出的权衡。与一般的几乎所有技术一样，没有一种放之四海而皆准的方法，对于 ES（以及类似技术）来说也不例外。
真实的主要来源不一定是关系 DBMS，它们不一定是 "duplicating" 您所指意义上的数据，它可以是任何具有您的数据副本并允许您重建你的 ES 索引以防出现问题。我见过很多很多不同的 "sources of truth"。它可以简单地是：
- 包含历史日志或业务数据的原始平面文件
- Kafka主题，随时轻松回放
- 您定期从 ES 获取的快照
- 关系数据库
- 你的名字...
关键是，如果由于任何原因出现问题（并且发生了这种情况），您希望能够重新创建 ES 索引，无论是来自真实数据库、备份还是原始数据。您应该将其视为安全网。即使您只有一个 MySQL 数据库，您通常也有它的备份，所以在某种程度上您已经是 "duplicating" 数据了。
不过，在构建系统时，您需要考虑的一件事是，您可能不一定需要在 ES 中拥有全部数据，因为 ES 是一个搜索和分析引擎，您应该只在那里存储支持您的搜索和分析需求所需的内容，并能够随时重新创建该信息。最后，ES 只是您整个架构的一个子系统，就像您的数据库、消息队列或 Web 服务器一样。
还值得一读：