假设我想使用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 语言编写了一种。
