Cassandra DB 中列族的性能答案

【问题标题】：Performance of Column Family in Cassandra DBCassandra DB 中列族的性能
【发布时间】：2018-10-21 17:43:05
【问题描述】：

我有一个表，我的查询将完全基于 id 和 created_time，我还有 50 个其他列将完全基于 id 和 created_time 进行查询，我可以通过两种方式设计它，

由多个小表格组成，每个表格包含 5 列，用于所有 50 个参数
包含所有 50 列的单个表，其中 id 和 created_at 作为主表键

哪个更好，我的行数会大大增加，所以建模时我应该在意列族的长度吗？

【问题讨论】：

标签： database cassandra cassandra-2.0 cassandra-3.0

【解决方案1】：

实际上，您需要有小表来减少单个表的负载，并且还应该尝试维护基于查询的表。如果使用的查询包含读取所有 50 列的语句，那么您可以继续使用单个表。但是，如果您计划在每个查询中获取部分数据，那么您应该维护基于查询的小表，这些表将在节点之间均匀地重新分配数据，或者按照 alex 的建议维护多个分区（但您无法获得基于范围的查询）。

【讨论】：

【解决方案2】：

这实际上取决于您如何构建分区键和分区内的数据分布。 CQL 有some limits，例如，每个分区最多 20 亿个单元，但这是理论上的限制，也是实际的限制 - 例如，没有大于 100Mb 的分区等 (DSE has recommendations in the planning guide)。

如果您总是按 id 和 created_time 搜索，而不是对 created_time 进行范围查询，那么您甚至可能拥有由两者组成的复合分区键 - 这将在集群中更均匀地分布数据。否则，请确保分区内没有太多数据。

或者您可以将另一部分添加到分区键中，例如，有时人们会将截断的日期时间添加到分区键中，例如，将时间四舍五入为小时或一天 - 但这会影响您的查询。这真的取决于他们。

【讨论】：

但是，我将根据时间进行范围查询，在该间隔内取平均值、最小值、最大值，我的查询将是，选择 column1 where id=id and created_at>time 和 created_at
是的，这就是我提到它的原因 - 如果您需要进行范围查询（从您的问题中不清楚），那么您需要确保分区不会太大 - 这个当一个id 拥有比其他更多的数据时，这是典型的问题。

【解决方案3】：

有点像 Alex 提到的那样，这里的决定因素将是您的各个分区的大小（这是列大小的扩展）。

实际上，您可能会遇到双向问题 - 太窄的分区可能与太宽的分区一样有问题，因此您可能希望尝试进行基准测试并查看哪种方法最有效。我怀疑对于正常数据模型（远离病态边缘情况），两者都可以正常工作，并且您不会看到有意义的差异（假设 3.11）。

在 3.11.x 中，Cassandra 在跳过未请求值方面比在 3.0.x 中做得更好，所以如果您确实选择将它们全部加入一个表中，请考虑使用 3.11.2 或任何最新可用版本3.11（或更新的）分支。

【讨论】：