高效的 Cassandra 键空间设计答案

【问题标题】：Efficient Cassandra keyspace design高效的 Cassandra 键空间设计
【发布时间】：2015-06-02 07:10:32
【问题描述】：

我有一个关于最佳 Cassandra 数据库设计的问题：具有大量细行的单个表是否有效，或者具有许多表的键空间有效？

上下文：我正在尝试存储来自多个传感器的数据。一种方法是使用一个表来存储来自所有传感器的数据。另一种方法是每个传感器有一个表。哪个更好？

请指教。

【问题讨论】：

标签： cassandra

【解决方案1】：

出于多种原因，我会选择更少的桌子：

正如 Andy Tolbert 在 his reply 中提到的那样，当您拥有 10 或 100 多个表时，每个表都会引入一些开销，这些开销会增加很多。将其视为增加您的开销/价值比率
如果您要处理大量表，您可能会在应用程序正常运行期间动态创建其中一些表。如果是这种情况，您可能会在 Cassandra 中看到错误，因为当它处于压力之下时，它可能无法在集群中传播一些新表的模式。我在 C* 2.0 中看到过这种情况，但我不确定在最新版本中是否仍然存在问题。
多表模式的大部分好处都可以通过对单表数据建模进行额外思考来获得。话虽如此，在某些情况下，将数据分离到离散表中确实是最合适的解决方案。这方面的一个例子是在某些多租户系统中，出于监管原因，不同租户的数据需要在物理上分开并单独备份。

【讨论】：

【解决方案2】：

为所有传感器设置 1 个表会更好，也更惯用。每个表都引入了一些开销（用于指标、文件等的 mxbeans），因此您不必拥有太多。

当您说“大量的瘦行”时，我不认为这是一个问题，您可以有许多唯一的键/分区（一些疯狂的大数字）。

【讨论】：

我认为“疯狂的大数”是 2^127 或 170,141,183,460,469,231,731,687,303,715,884,105,728
听起来不错（而且非常大！），这是来自分区器的唯一哈希数吗？我认为对于 murmur3 它使用哈希的前半部分，所以我认为它是 2^63（我可能是错的）。
是的，我认为 2^127 来自 RandomPartitioner 时代。我认为你是对的，Murmur3 类似于 -2^63 到 +2^63;这将是 2^63 * 2。与 2^127 不太一样，但仍然非常大！哈哈。