大型数据集的 Solr 索引答案

【问题标题】：Solr indexing of a large data set大型数据集的 Solr 索引
【发布时间】：2015-12-23 14:47:10
【问题描述】：

我有大约 50 TB 的内容。该集合中的文档数量约为 2.5 亿。每天的增量不是很大，我大约是 10000 个不同大小的文档，总计不到 50 MB。当前的索引工作耗时太长，估计需要 100 多天才能完成！！！
那么……这真的是那么大的数据集吗？对我来说，50 TB 的内容（在这个时代）并不是很大。你有这种大小的内容吗？如果你这样做了，你是如何减少一次性索引所花费的时间的？另外，您是如何缩短实时索引所花费的时间的？
如果你能回答..太好了。如果你能指出我正确的直接方向......也很感激。

提前致谢。
rd

【问题讨论】：

检查这个stackoverflow.com/a/31935578/2254048。如果它打开，还要禁用用于批量索引的 softCommit。另请阅读此wiki.apache.org/solr/SolrPerformanceFactors。
数字本身对于 Solr 来说毫无意义：简单的 CSV 导入可以处理 30K 文档/秒，足够复杂的 Tika 处理可能意味着 1 文档/分钟。如果 YoungHobbit 的建议没有帮助，请在更多信息中描述详细说明您正在处理哪些数据以及如何将它们添加到 Solr。

标签： performance indexing solr large-data-volumes

【解决方案1】：

有很多因素需要考虑。

您可以从客户端开始索引。您使用的是哪个客户端。它是 Solrj，还是任何侦听数据库（如 oracle 或 Hbase）或 REST API 的框架。这可能会有所不同，因为 Solr 擅长处理它们，但是客户端框架和客户端的数据准备也需要优化。例如，如果您使用 Hbase Indexer（它从 Hbase 表中读取并写入 Solr），您可以预期在几小时左右的时间内索引数百万。那么，这应该不会花费太多时间来完成 2.5 亿。
客户端后进入Solr环境。您在文档中索引了多少字段。您是否还存储了字段或字段类型的任何其他开销。
配置参数，如基于记录数或 RAM 大小的 autoCommit、上面评论中提到的 softCommit、索引数据的并行线程、硬件是需要考虑的一些要点。

您可以找到全面的检查清单here 并可以验证每个。快乐设计

【讨论】：