我的环境：带Ubuntu 14.04的8GB Ram笔记本，Solr 4.3.1，carrot2workbench 3.10.0
My Solr Index：15980个文件
我的问题：使用kmeans算法对所有文档进行聚类
当我在carrot2workbench（查询：：）中删除查询时，在使用超过~1000个结果时，我总是会遇到Java堆大小错误。我用-Xms256m -Xmx6g启动了Solr，但它仍然存在。
它真的是堆大小问题还是可能在其他地方？
答案 0 :(得分：0)
您的怀疑是正确的，这是一个堆大小问题，或者更确切地说，是一个可伸缩性约束。直接来自carrot2常见问题：http://project.carrot2.org/faq.html#scalability
Carrot2聚类如何根据文档的数量和长度进行扩展？ 要记住Carrot2算法最重要的特性是它们执行内存中的聚类。因此，根据经验，Carrot2应成功处理多达一千个文档，每个文档分几段。对于旨在处理数百万个文档的算法，您可能需要查看Mahout项目。
开发人员也在此发布了这个内容：https://stackoverflow.com/a/28991477
虽然开发人员推荐使用Mahout，但这可能是要走的路，因为你不会像在carrot2中那样受到内存中聚类限制的约束，但可能还有其他可能性：
如果您真的喜欢胡萝卜2，但不一定需要k-means，您可以根据“群集时间为100000个片段[s]”字段和（***）查看商业Lingo3G。 ）http://carrotsearch.com/lingo3g-comparison上的评论它应该能够处理更多的文件。另请查看他们的常见问题解答条目：“Lingo3G可以群集的最大文档数量是多少？”在http://carrotsearch.com/lingo3g-faq
尝试最小化k-means执行群集的标签大小。不要对所有文档内容进行聚类，而是尝试在摘要/摘要上进行聚类，或者在它们上提取重要的关键字和聚类。
答案 1 :(得分：0)
好像胡萝卜对记忆的影响很大。
K-means不需要大量内存 - 每个文档一个整数。
所以你应该能够在内存中的百万文件上运行k-means;即使文件向量在内存中也是如此。
16k文档不是很多，所以我不明白为什么你应该遇到一个好的实现问题。他们真的希望你购买商业版来谋生！去Mahout对我来说似乎有些过分。我猜你的数据仍然适合主内存，所以不要浪费时间在网络上分发它，这比你的记忆慢了一百万倍。
也许自己实施k-means。这不难......