直接喂ES - 是否需要队列？

Question

我正在考虑使用没有数据库的ES的可能性，从我的python应用程序构建我的数据并将其直接发送到ES实时。它告诉我很多复杂性，但我担心的是，我可能会非常快速地生成数据并无情地发送请求，即使ES可能还没准备好接受它。

我的问题是，在这种情况下，使用队列系统作为两者之间的缓冲区是有意义的，因此我的应用程序将所有内容发送到队列，然后队列尝试将其添加到ES，如果它没有重试则重试取得成功。

我不确定这是否是最合乎逻辑或最有效的方法。如果任何人有关于什么队列系统适合的任何信息或想法，或者我甚至需要一个，我会非常有兴趣听到。

詹姆斯

Answer 1

Elasticsearch批量索引API非常高效;它可以处理相当多的负载 - 当然，取决于您的源文档和分析仪的复杂性。请务必测试适当的批量批量大小对您的硬件和用例最有效（所提到的复杂性）。

另一种方法是使用Elasticsearch river概念（http://www.elasticsearch.org/guide/reference/river/，简介：http://www.elasticsearch.org/blog/the-river/）：仅在群集中的单个节点上运行到某种消息代理（redis，rabbitmq，couchdb，以及更多存在）。您的应用程序以任何支持的速度将文档推送到消息代理 - 通常非常快 - 并且Elasticsearch river使用批量索引在内部批量和索引中提取数据。

老实说，如果您不确定，请先尝试最简单的解决方案（直接批量索引）。如果这不起作用，请继续进行河流支持。

Answer 2

我是新来的，但我会尝试与ES分享自己的经验。 在这里，我们使用couchDB来存储我们正在索引到ES的json。但是，我们对这些文档进行了大量修改，例如创建新节点等。文档很大，数百个字段，超过15个嵌套集合。 最后，有成千上万的文档。

所以，是的，根据我的拙见，如果你可以通过你的应用程序创建你的文档，我不明白为什么ES会遇到麻烦。 但是对于python部分，我无法帮助，我们在这里用java做事。

然而，对于ES，我会

• 使用批量api。通过这种方式，ES（更多，更多）更有效率。
• 我可能会存储由于另一个索引（或文件或其他地方）中的随机错误而无法编制索引的文档的ID，以便您可以在以后重建和重新索引它们，而不是重试出错了。 （虽然我不知道python中的可行性）
• 不使用副本作为当前索引的索引。

对于错误重试，我的感情很复杂。如果错误是由于文档的错误构造或映射错误引起的，则每次重试都会失败。

在这里，我们每分钟索引数千个这样的文档，但仍然可以发出搜索和构面请求（尽管这些请求可能稍慢）。

这并不多，但我希望它有所帮助。 祝你好运。