我们正在考虑实现某种类型的消息缓存，它会保留我们发送到搜索索引的消息，因此我们可以在索引长时间停机时持续存在（例如完整的重新索引）然后'重新申请'消息。这些消息是我们索引的文档的创建或更新。如果空间足够便宜，可以像Couchbase那样具有可扩展性，我们甚至可以保留所有消息，但我还没有对消息大小和数量做过任何估计。无论如何，我建议Couchbase + XDCR + Elasticsearch完成这项任务，因为大部分工作都会自动完成，但我还有4个问题：
如果我们将其作为缓存实现，我不希望Elasticsearch删除任何不在Couchbase中的文档，这是否可能（可能它甚至是默认行为）？
< / LI>是否可以应用某种版本控制，以便索引中的文档不会被来自Couchbase的旧版本覆盖？
如果我要向索引添加新字段，我可能需要从实际文档数据源重新索引，然后重新应用存储在Couchbase中的所有消息。我可能在Elasticsearch中有1亿个文档，在Couchbase中说500,000个文档，我想重新申请Elasticsearch？速度会是什么样的。
我可以在Couchbase和Elasticsearch之间应用任何类型的逻辑吗？
更新
因此，我们将文档存储在RDBMS中，因为我们需要即时访问插入的文档以及其他一些内容。我们通过消息将有限版本的文档发送到搜索引擎。如果我们想在索引中添加一个字段，我们需要以某种方式从RDBMS重新索引系统。如果我们有这个Couchbase消息缓存，我们可以先将字段添加到消息中，然后关闭旧消息的索引并从RDBMS重新索引。然后我们可以切换回消息的索引，并且消息的整个“队列”将被索引而不会丢失任何内容。
这个系统（如果有效）将不需要MQ服务器，消息监听器，并确保索引中没有文件丢失。
版本控制是必要的，因为我们不想对实际包含更新文档的索引应用“更新”（不确定现在是否会发生这种情况）。
我很欣赏通过更改Elasticsearch插件代码来实现第1点和第4点可能不是一件好事，但我想首先确认这个想法是合理的！
答案 0 :(得分：1)
今天的Couchbase-Elasticsearch集成应被视为Couchbase的索引引擎。这意味着索引由Couchbase中的数据“管理/控制”。
XDCR用于将“所有事件”发送到Elasticsearch。这意味着每次创建，修改或删除文档（存储在Couchbase中）时都会更新/删除索引。
因此，存储在Couchbase存储桶中的“所有文档”都会被索引到Elasticsearch中。
让我们根据Couchbase-Elasticsearch的当前实现逐一回答您的问题。
从Couchbase中删除文档时，Elasticsearch索引将更新（删除条目）。
不确定理解这个问题。 Couchbase如何使用“旧”版本？无论如何，每次修改存储在Couchbase中的文档时，Elasticsearch中的索引都会更新。
不确定要了解添加新字段的位置？如果这是存储在Couchbase中的文档，当文档将被发送到Elasticsearch时，索引将被更新。但根据我之前所说的内容：所有“存储”到Couchbase中的文档都将出现在Elasticsearch索引中。
不是今天的插件，但是你知道它是一个开源项目，所以你可以为它添加一些逻辑，甚至可以将你的想法贡献给项目（https://github.com/couchbaselabs/elasticsearch-transport-couchbase）< / p>
那么让我问你更多的问题： - 如何将文档输入到您的应用程序中？ （以及Couchbase？Elasticsearch？） - 什么类型的文件？ - 你想要什么缓存到Couchbase？