Couchbase XDCR Elasticsearch 速度和删除

Question

我们正在考虑实现某种消息缓存，它可以保存我们发送到搜索索引的消息，这样我们就可以在索引关闭很长一段时间（例如，完整的重新索引）时持续存在“重新应用”消息。这些消息是我们索引的文档的创建或更新。如果空间足够便宜，使用像 Couchbase 这样可扩展的东西，我们甚至可以保存所有消息，但我还没有对消息大小和数量进行任何类型的估计。无论如何，我建议 Couchbase + XDCR + Elasticsearch 来完成这项任务，因为大部分工作都会自动完成，但是我还有 4 个问题：

1. 如果我们将此实现为缓存，我不希望 Elasticsearch 删除任何不在 Couchbase 中的文档，这可能吗（甚至可能是默认行为）？

2. 是否可以应用某种版本控制，以便索引中的文档不会被来自 Couchbase 的旧版本覆盖？

3. 如果我要向索引中添加一个新字段，我可能需要从实际的文档数据源重新索引，然后重新应用存储在 Couchbase 中的所有消息。我可能在 Elasticsearch 中有 1 亿个文档，并且说 Couchbase 中有 500,000 个文档我想重新应用到 Elasticsearch？速度会怎样。

4. 我能否在 Couchbase 和 Elasticsearch 之间应用任何类型的逻辑？

更新：

因此，我们将文档存储在 RDBMS 中，因为我们需要即时访问插入的文档以及其他一些内容。我们通过消息将文档的有限版本发送到搜索引擎。如果我们想向索引中添加一个字段，我们需要以某种方式从 RDBMS 重新索引系统。如果我们有这个 Couchbase 消息缓存，我们可以先将字段添加到消息中，然后关闭旧消息的索引并从 RDBMS 重新索引。然后我们可以重新打开消息的索引，整个消息“队列”将被索引而不会丢失任何内容。

这个系统（如果它工作的话）将不再需要一个 MQ 服务器、一个消息侦听器并确保索引中没有任何文档丢失。

版本控制是必要的，因为我们不想对实际上包含更新文档的索引应用“更新”（现在我想不确定这是否会发生）。

我很欣赏通过更改 Elasticsearch 插件代码来实现第 1 点和第 4 点的工作可能不是太好，但我想先确认这个想法是合理的！

Answer 1

今天的 Couchbase-Elasticsearch 集成应该被视为 Couchbase 的索引引擎。这意味着索引由 Couchbase 中的数据“管理/控制”。

XDCR 用于将“所有事件”发送到 Elasticsearch。这意味着每次创建、修改或删除文档（存储在 Couchbase 中）时都会更新/删除索引。

因此，存储在 Couchbase 存储桶中的“所有文档”都会被索引到 Elasticsearch。

让我们根据 Couchbase-Elasticsearch 的当前实现，一一回答您的问题。

1. 从 Couchbase 中删除文档时，Elasticsearch 索引会更新（条目已删除）。

2. 不确定是否理解问题。 “旧”版本如何来自 Couchbase？无论如何，每次修改存储在 Couchbase 中的文档时，都会更新 Elasticsearch 中的索引。

3. 不确定要在哪里添加新字段？如果这是存储在 Couchbase 中的文档，那么当文档将被发送到 Elasticsearch 时，索引将被更新。但根据我之前所说的：所有“存储”到 Couchbase 中的文档都将出现在 Elasticsearch 索引中。

4. 不像现在这样使用插件，但正如您所知，它是一个开源项目，因此您可以为其添加一些逻辑，甚至可以将您的想法贡献给项目 (https://github.com/couchbaselabs/elasticsearch-transport-couchbase)

所以让我问你更多问题： - 您如何将文档插入到您的应用程序中？ （Couchbase 在哪里？Elasticsearch？） - 文件的类型是什么？ - 你想在 Couchbase 中缓存什么？