一个更大的分区或几个更小但更分散的分区，用于Cassandra的范围查询？

Question

我们有一个表来存储按文件分区的数据。在json中，一个文件是200MB到8GB - 但显然有很多开销。压缩原始数据将大大降低这一点。我摄取了大约35 GB的json数据，只有一个节点获得了超过800 MB的数据。这可能是由于“写热点” - 但我们只写一次并且只读。我们不更新数据。目前，我们每个文件都有一个分区。

通过使用二级索引，我们在数据库中搜索包含特定地理位置（=第一个查询）的分区，然后将此查询的结果用于范围查询找到的分区的时间范围（=第二个查询）。 如果需要，甚至可能是整个文件，但在95％的查询中，只查询分区的块。

我们在6节点集群上的复制因子为2。数据相当均匀分布，每个节点根据nodetool status *tablename*拥有31,9％至35,7％（有效）数据。

良好的阅读表现对我们至关重要。

我的问题：

1. 对于分区而言，在数量或行大小方面有多大？这有经验法则吗？
2. 对于范围查询性能：将“大”分区拆分为更小的分区是否更好？我们使用“大”分区构建了我们的模式，因为我们认为当我们对分区进行范围查询时，最好将它全部放在一个节点上，以便可以轻松获取数据。请注意，由于RF 2，数据也可在一个副本上使用。

Answer 1

1. C *支持非常大的行，但并不意味着进入该级别是个好主意。 右限制取决于具体的用例，但良好的球场价值可能在10k到50k之间。当然，一切都是妥协，所以如果你有＆＃34;巨大的＆＃34; （以字节为单位）行然后严格限制每个分区中的行数。如果你有＆＃34;小＆＃34; （以字节为单位）排它们你可以放松一下限制。这是因为一个分区仅因 RF = 1 而导致一个节点，因此您对特定分区的所有查询都只会触及一个节点
2. 理想情况下，范围查询应仅转到一个分区。范围查询意味着在获取查询的节点上对分区执行顺序扫描。但是，您将自己限制为该节点的吞吐量。如果您在更多节点之间拆分范围查询（即通过添加诸如存储桶之类的内容来更改分区数据的方式），则需要从不同节点获取数据以及执行 parallel < / em>查询，直接增加总吞吐量。当然，您在不同的存储桶中丢失了记录的顺序，因此如果您的分区中的顺序很重要，那么这是不可行的。