Solandra Sharding：内幕思考

Question

刚开始使用Solandra，并试图理解第二个 Solandra分级的详细信息。

AFAIK Soalndra创建了多个配置的分片（如 “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执行此请求 分布到所有可能的节点等。这是分布式写吗？ 因为在那之前，其他节点将如何竞争 特定分片内的槽。理想的是用于编写doc或 一组文档将在单个物理JVM上执行。

2. 通过分片，我们尝试在单个物理节点上编写一些文档 但如果它是基于不同的拥有的插槽写的 物理节点，我们真正实现了什么，因为我们再次需要 从不同节点获取结果。我明白写的 吞吐量最大化。

3. 我们可以调查这些数字 - ？ “solandra.maximum.docs.per.shard”， “solandra.index.id.reserve.size","solandra.shards.at.once”。

4. 如果我在一个DC中只有一个分片和复制因子为5 6节点设置，我看到这个分片的端点包含5 根据复制因子的端点。但是第6次会发生什么 一。我通过nodetool看到左边的第6个节点没有真正得到 任何数据。如果我将复制因子增加到6，同时保持 集群上，这将解决问题并做修复等 有更好的方法。

Answer 1

总体而言，shards.at.once参数用于控制索引的并行性。该数字越大，一次写入的分片越多。如果将其设置为1，则始终只写入一个分片。通常这应该设置为20％>集群中的节点数。所以对于一个四节点集群，将它设置为五个。

保留大小越高，节点之间的协调就越少。所以，如果你知道你有很多文件要写，那么提出这个。

docs.per.shard越高，给定分片的查询就越慢。一般来说，这应该是1-5M最大

回答你的观点：

1. 这只会从一个节点导入。但它会立即根据分片进行索引。

2. 我认为问题是你应该跨所有节点写吗？是。

3. 是的，见上文。

4. 如果你增加了shards.at.once，这将会很快填充