在当前架构中，我们使用基于分片的数据库模型[MYSQL]和一个Solr服务器[非云模式]专用于32 GB内存来保存1个分片数据[最多1000万个项目]。由于计算逻辑的业务需求，应用程序需要每天为每个分片执行完全重新索引。为了执行完全重新索引，我们创建了temp solr服务器，并将索引数据交换到solr服务器。这种方法很有效，我们没有遇到任何问题。
由于我们正在从关系数据模型转向nosql模型，我们计划采用Solr Cloud，因为基于分片的模型正在消失。我非常担心Solr云每天如何维持2亿次更新。 在这些更新期间，相同的solr服务器还负责为数百万的业务运营请求提供服务。
有人会建议我们，SolrCloud会在提供请求时每天维持2亿件物品更新吗？
答案 0 :(得分：1)
更新文档时，SOLR会将旧版本标记为已删除，并插入新版本。任何查询都不会找到已删除的文档（* *：*查询只会返回未删除的文档），但它们仍占用磁盘空间，而它们确实会降低搜索速度（通过炸毁过滤查询的位图）。
SOLR索引被分成相当不同大小的段。偶尔会合并一些段，这也会从这些段中删除已删除的文档。
问题是，一个片段越大，合并的次数就越少，而且它会积累的文档也会越多。
我们在主要集合中运行一个包含60个mio文档的SOLRCloud设置，分成6个分片，磁盘上30-50 GB的总集合大小，ca.每天30 mio更新;每个群集由两个8核128 GB RAM服务器组成。
我们解决此问题的方法是确保我们设置中的每个分片都小于10 GB。为此，我们在每台服务器上独立运行三个SOLR实例（在端口8983,8984和8985上）。每个碎片低于10 GB，SOLR的合并段机制对我们来说非常有效。