Apache Solr 能否处理 TB 大数据
我是 apache solr 用户大约一年了。我使用 solr 作为简单的搜索工具，但现在我想使用 solr 处理 5TB 的数据。我假设当 solr 根据我使用的过滤器对其进行索引时，5TB 数据将是 7TB。然后我会每小时向同一个索引添加近 50MB 的数据。
1-使用单个 solr 服务器处理 5TB 数据是否有任何问题。 （没有分片）
a- solr 服务器能否在可接受的时间内回答查询
b- 提交 50MB 数据的预期时间是多少在 7TB 索引上。
c- 索引大小是否有上限。
2- 您提供的建议是什么
a- 我应该使用多少个分片
b- 我应该使用 solr 核心
c- 您提供的提交频率是多少。 （1 小时即可）
3-这种大数据有测试结果吗
没有可用的 5TB 数据，我只是想估计一下结果。
注意：您可以假设硬件资源不是问题。
I am an apache solr user about a year. I used solr for simple search tools but now I want to use solr with 5TB of data. I assume that 5TB data will be 7TB when solr index it according to filter that I use. And then I will add nearly 50MB of data per hour to the same index.
1- Are there any problem using single solr server with 5TB data. (without shards)
a- Can solr server answers the queries in an acceptable time
b- what is the expected time for commiting of 50MB data on 7TB index.
c- Is there an upper limit for index size.
2- what are the suggestions that you offer
a- How many shards should I use
b- Should I use solr cores
c- What is the committing frequency you offered. (is 1 hour OK)
3- are there any test results for this kind of large data
There is no available 5TB data, I just want to estimate what will be the result.
Note: You can assume that hardware resourses are not a problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您的大小适用于文本，而不是二进制文件（其文本通常会少得多），那么我认为您不能假装在一台机器上执行此操作。
这听起来很像 Logly 并且他们使用 SolrCloud 来处理如此大量的数据。
好吧，如果所有都是丰富的文档，那么索引的总文本大小将会小得多（对我来说，大约是起始大小的 7%）。不管怎样，即使数量减少了，我认为单个实例的数据仍然太多。
if your sizes are for text, rather than binary files (whose text would be usually much less), then I don't think you can pretend to do this in a single machine.
This sounds a lot like Logly and they use SolrCloud to handle such amount of data.
ok if all are rich documents then total text size to index will be much smaller (for me its about 7% of my starting size). Anyway, even with that decreased amount, you still have too much data for a single instance I think.