database-design - Cassandra -一张大 table vs多张 table

我目前正在尝试试用Cassandra数据库。
我正在使用DataStax开发中心和DataStax C＃驱动程序。

我当前的模型非常简单，仅包含：


ParameterId（int）-将用作表的ID。
价值（bigint）
MeasureTime（时间戳）


我将拥有1000个（不多不少）的参数，范围是1-1000。并且一次将获得每个参数的条目。第二，将运行多年。

我的问题是关于将表创建为以下更好的做法：

CREATE TABLE keyspace.measurement (
    parameterId int,
    value bigint,
    measureTime timestamp,
    PRIMARY KEY(parameterId, measureTime)
) WITH CLUSTERING ORDER BY (measureTime DESC)

或者最好创建仅由一个值和measureTime组成的1000个表，如果可以的话，我是否可以对MeasureTime进行范围查询？

最佳答案

您将为此打非常大的行。我建议不要使用表格格式，我会选择允许您控制行宽的内容。

根据您的查询要求，我将为您写下一个更合适的架构（IMHO）：

CREATE TABLE keyspace.measurement (
    parameterId int,
    granularity timestamp,
    value bigint,
    measureTime timestamp,
    PRIMARY KEY((parameterId, granularity), measureTime)
) WITH CLUSTERING ORDER BY (measureTime DESC)

这与您的非常相似，但是它具有一个主要优点：您可以配置行的宽度，并且没有任何热点。这个想法简直太简单了：parameterId和granularity字段都是分区键，所以它们可以告诉您数据的去向，而measureTime则可以使数据保持有序。假设您要每天查询一次，则将granularity的值yyyy-mm-dd存储到measureTime中，将当天的所有度量组合在一起。

这使您可以使用有效的范围查询来检索位于同一分区（因此每个给定的parameterId和granularity字段对）上的所有值。在日常配置中，每个分区最终将获得86400条记录。此数字可能仍然很高（建议的限制为10k IIRC），并且可以通过使用yyyy-mm-dd HH:00值按小时分组来降低tht值。

这种方法的缺点是，如果您需要来自多个分区的数据（例如，您每天进行分组，但是需要连续两天的数据，例如1月19日的最后6个小时，以及前6个小时1月20日的小时），则您需要执行多个查询。