Solandra切分:内部思想

Question

刚开始在Solandra，并试图了解第二层细节的Solandra切分。

AFAIK创建配置为"solandra.shards.at.once“属性的碎片数量，其中每个碎片的大小为"solandra.maximum.docs.per.shard”。

在下一个级别上，它开始在每个碎片内创建由"solandra.maximum.docs.per.shard"/"solandra.index.id.reserve.size".定义的槽。

我从SchemaInfo CF的数据模型中了解到，在一个特定的碎片中，有不同的物理节点所拥有的槽，这是在节点之间为获取这些时隙而进行的一场竞赛。

我的问题是：

1. ，这是否意味着如果我请求写入特定的solr节点，例如。....solandra/abc/dataimport?command=full-import，该请求是否被分发到所有可能的节点，等等。这是分布式写入吗？因为在此之前，其他节点将如何在特定的shard.Ideally中竞争插槽，用于编写文档或文档集的代码将在单个物理JVM上执行。
2. 通过分片，我们试图在单个物理节点上编写一些文档，但是如果它是基于不同物理节点拥有的时隙编写的，那么我们实际上实现了什么，因为我们再次需要从不同的节点获取结果。我知道写吞吐量是最大化的。
3. 我们可以考虑调优这些数字吗？"solandra.maximum.docs.per.shard“，"solandra.index.id.reserve.size","solandra.shards.at.once”。如果在一个DC 6节点设置中只有一个切分和复制因子为5，那么我看到这个碎片的端点包含5个端点，按照复制Factor.But，第6个端点发生了什么。通过nodetool，我看到左边的第6个节点并没有真正得到任何数据。如果我在保持集群运行的同时将复制因子提高到6，这会解决问题并进行修复等，还是有更好的方法。

Answer 1

总之，使用shards.at.once参数来控制索引的并行性。这个数字越高，立即写入的碎片就越多。如果你把它设置为一个，你将永远写到只有一个碎片。通常，这应该设置为20% >集群中的节点数。因此，对于一个四节点集群，将其设置为5。

储备规模越大，节点之间的协调就越少。所以，如果你知道你有很多文件要写，那么就提出这个问题。

docs.per.shard越高，对给定碎片的查询就会变得越慢。一般来说，这应该是最多150万美元。

回答你的观点：

1. ，这将只从一个节点导入。但是它会同时根据碎片进行索引。

，

1. ，我认为问题是，您应该跨所有节点写入吗？是。
2. 是的，见上文。
3. ，如果您增加shards.at.once，则将快速填充