kubernetes - SolrCloud 时间路由别名架构

Question

这是围绕构建 SolrCloud Time Routed Alias 应用程序架构的一个更广泛的问题。我正在使用 SolrCloud 定期摄取时间序列数据，并让 SolrCloud 在 Kubernetes 集群中运行。每次我们向集群添加新 Pod 时，都会连接一个 Solr 节点。每个 pod 都有一个持久卷声明，所以这也是我们扩展存储的方式。

由于我正在尝试使用 Time Routed Aliases，它会创建一个具有抢先计算的新集合，并且当前根据 pod 中有多少可用磁盘空间将它们放置在 Solr pod 中，因此将为分片放置选择新的 pod每当引入新的 Pod 时。

但是，我想设计一个解决方案，通过将分片分布在较旧的 pod 中，我们可以避免热点Solr 节点，同时仍然保持 SolrCloud 架构，该架构随着每天摄取数据的大小而增长。

根据https://solr.apache.org/guide/8_6/solrcloud-autoscaling-policy-preferences.html中的可用策略，我不确定集合/集群级别的最佳配置是什么

我目前正在以每周间隔创建集合，我的用例涉及搜索至少2 周前的数据。因为摄取的数据将被放置在较新的 pod 中，所以我面向客户端的应用程序每次都会轰炸较新的 pod。

每个集合的复制因子为 2，numShards 参数为 2。

为了避免热点，我应该在集合/别名/集群级别上使用什么级别的配置？

标签： kubernetessolrsolrcloud