假设我想使用 Elasticsearch 实现网站的通用搜索，顶部搜索栏将能够在整个网站上查找各种不同类型的资源。文档当然是可以找到的（通过 tika 上传/索引），但也会有像客户、账户和其他人等其他东西。
出于架构原因，大多数非文档内容（客户、账户）将存在于关系型数据库中。
在实现此搜索时，选项＃1是创建所有内容的文档版本，然后仅使用 Elasticsearch 运行搜索的所有方面，完全不依赖关系型数据库来查找不同类型的对象。
选项＃2是仅使用 Elasticsearch 索引文档，这意味着对于通用的“站点搜索”功能，您必须将多个搜索分配给多个系统，然后聚合结果，然后返回它们。
选项＃1似乎更优越，但缺点是它要求 Elasticsearch 在生产关系型数据库中拥有许多东西的副本，并且这些副本在事物更改时保持更新。
保持这些存储同步的最佳选项是什么？我的想法是通用搜索使用选项＃1是更好的选择。是否有选项＃3？
您列出了跨多个数据存储搜索时的两种主要选择，即在一个中央数据存储中搜索（选项＃1）或在所有数据存储中进行搜索并聚合结果（选项＃2）。
这两个选项都可以使用，尽管选项＃2有两个主要缺点：
如果您想提供更好且更可靠的搜索体验，则选项＃1显然会得到我的支持（实际上我经常采用这种方式）。正如您正确指出的那样，这个选项的主要“缺点”是您需要将 Elasticsearch 与其他主数据存储中的更改保持同步。
由于您的其他数据存储将是关系型数据库，因此有几种不同的选项可让它们与 Elasticsearch 同步，即：
前两个选项效果很好，但有一个主要的缺点，即它们不会捕获表上的 DELETE 操作，它们只会捕获 INSERT 和 UPDATE 操作。这意味着，如果您删除用户、帐户等，则无法知道您必须在 Elasticsearch 中删除相应的文档。除非您在每次导入会话之前决定删除 Elasticsearch 索引。
为了缓解这个问题，你可以使用另一个基于MySQL binlog的工具，因此它能够捕获每个事件。有一种用Go编写的工具，一种用Java编写的工具，还有一种用Python编写的工具。 更新: 以下是另一篇有趣的博客文章： 如何使用Logstash将Elasticsearch与关系型数据库同步。
