SolrCloud 每天更新数百万次的可扩展性

Question

在当前架构中，我们使用基于分片的数据库模型[MYSQL] 和一个 Solr 服务器[非云模式]，专用于 32 GB 内存来保存 1 个分片数据[最多 1000 万个项目]。由于业务对计算逻辑的需求，应用程序需要每天对每个分片执行完整的重新索引。为了执行完整的重新索引，我们创建了临时 solr 服务器并将索引数据交换到 solr 服务器。这种方法效果很好，我们没有遇到任何问题。

由于我们正在从关系数据模型迁移到 nosql 模型，因此我们计划使用 Solr Cloud，因为基于分片的模型正在消失。我非常担心 Solr 云如何维持每天 2 亿次更新。 在这些更新期间，相同的 solr 服务器还负责为数百万个业务操作的 get 请求提供服务。

• Solr 服务器数量：30
• 每台服务器上的内存/RAM：32 GB
• 每台服务器上的大小：4 到 1000 万个项目 [4 到 20 GB]

有人建议我们，SolrCloud 在服务获取请求时是否会维持每天 2 亿次项目更新？

Answer 1

更新文档时，SOLR 会将旧版本标记为已删除，并插入新版本。任何查询都不会找到已删除的文档（*:* 查询将只返回未删除的文档），但它们仍会占用磁盘空间，并且它们确实会减慢您的搜索速度（通过炸毁过滤器查询的位图）。

SOLR 索引被分成大小不同的段。偶尔会合并一些片段，这也会从这些片段中消除已删除的文档。

但问题是，一个片段越大，它被合并的越少，它会积累更多的删除文档。

我们运行 SOLRCloud 设置，主集合中有 60 个 mio 文档，分为 6 个分片，磁盘上的总集合大小为 30-50 GB，大约每天 30 次 mio 更新；每个集群由两个 8 核 128 GB RAM 服务器组成。

我们对此问题的解决方案是确保我们设置中的每个分片小于 10 GB。为此，我们在每台服务器上独立运行了三个 SOLR 实例（在端口 8983、8984 和 8985 上）。在每个 shard 小于 10 GB 的情况下，SOLR 合并段的机制对我们来说效果很好。