2

我们正在考虑实现某种消息缓存，它会保存我们发送到搜索索引的消息，这样我们就可以在索引下降很长一段时间（例如完全重新索引）时持续存在，然后're-应用'消息。这些消息是我们索引的文档的创建或更新。如果空间足够便宜，使用像 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 点的工作可能不是太好，但我想首先确认这个想法是合理的！

4

1 回答 1

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 在哪里？Elasticsearch？） - 文档的类型是什么？- 你想在 Couchbase 中缓存什么？

于 2013-02-01T08:25:59.917 回答