使用弹性搜索处理超过内存限制的文档处理

Question

我使用Elasticsearch.的Tire作为Ruby包装器我的问题是，我需要将10万个文档加载到内存中，并对它们进行某种复杂的计算。目前的程序如下：

1. 加载所有文件
2. Computation.new(all_documents)
3. 迭代所有文档并调用computation.calc(document)

此策略不适用于10万个文档，因为我将立即达到机器的内存限制。文档(JSON)被加载到Tire对象中，然后我将其转换为Ruby散列。

我该怎么做才能达到这个规模呢？我想到了以下几点，但我不确定( a)实现b)最好的解决方案是否好。

1. 初始化计算对象c = Computation.new
2. 加载m文档
3. c.preprocess(documents)
4. 重复步骤2和3，直到所有文档都被预处理为止。
5. 加载m文档
6. 迭代m文档
7. c.calc(document)
8. 重复步骤6和7，直到所有文档都被处理为止。

此外，从GC的角度来看，我不确定这将如何工作。

Answer 1

您的问题似乎是“如何在不耗尽内存的情况下将10万个ElasticSearch JSON对象序列化成Ruby？”更好的问题是：“如何尽可能轻松高效地对100000个ElasticSearch文档进行计算？”因为我们不知道你想要进行什么样的计算，所以我们必须把答案保持在一般水平。

1. 以尼尔·斯莱特的建议为例，尽可能多地使用ElasticSearch。例如，ES在DB/store中有很多不错的你能做的统计计算。
2. 对插入新文档进行预处理。例如，如果您知道您想要获得计数、平均值或其他针对整个集合的计算，只需计算每个项的统计量，然后将其存储在ES中即可。如果您在Rails中使用Tire，请将这些calc方法添加到before_save回调或其他东西中。
3. 避免将ES文档反序列化为Ruby对象。将100,000人全部转化为Ruby对象是在扼杀您的内存。看看是否可以通过将结果作为直接的JSON获取并使用ruby (或一些性能调优的替代方案，如multi)将它们转换为ruby散列来获得性能改进。它仍然会有一些内存，但不会像完整的Rails模型对象那样多。
4. 尝试将计算分解为步骤，并将它们作为后台作业或守护进程的任务提供。如果它们需要按顺序执行，则可以在下一个作业完成时启动第一个作业。
5. 如果上述任何一种方法都不起作用，那么可以找到一种方法来接近数据(直接使用javascript操作JSON )，或者考虑另一个数据存储，比如PostgreSQL，您可以在DB1000x中比在Ruby/Rails中进行大量的计算。

希望这能帮上忙！