cassandra - Cassandra 中的时间序列数据，每个月的键空间而不是一个键空间？

Question

我们有数千个传感器，可以生成我们想要存储在 Cassandra 中的测量时间序列数据。目前，我们每天存储约 5 亿条记录，下次该数量将增长 5-10 倍。

我们主要使用最新的测量数据。旧的测量数据几乎无法读取。

• 我们主要读取最新的测量结果(即一周前的测量结果)，
• 较旧的测量值(即年龄小于一个月)很少被读取(每周十次)，
• 非常旧的测量值(即年龄为 1-6 个月)很少被读取(每月一次)，
• 超过 6 个月的测量结果被视为冷数据，即从未读取过。

作为压缩策略，我们使用 DTCS。设置 ttl 不是一个选项，因为我们需要存储测量数据以用于存档目的。

我还不知道如何处理“旧数据几乎冷了”的事实。

更新:我想要避免的:我的 Cassandra 集群中有 20 TB，其中 18 TB 被使用，假设每年只使用一次(如果有的话)。我不想为不需要的 18 TB 付费。设置 ttl 不是一个选项，因为我们应该能够读取数据，例如从 2013 年 3 月开始的数据(此类请求的额外成本是可以的)。如果我们将 ttl 设置为例如 6 个月，那么我们就无法正确执行此操作。

我们目前正在评估两种设计方案，并寻找最具成本效益的方案:

1. 一个键空间，带有分区键(sensor_id、measurement_date)
2. 每月一个 key 空间，具有相同的分区 key (sensor_id、measurement_date)

(在这两种情况下，每行最多有 500K 列，大部分小于 100K)

2.的缺点是我们将拥有<100个键空间而不是1个，并且读取数据时的复杂性增加。2. 的优点是我们可以每月对它们进行快照/备份/删除/恢复，据我了解，如果我们采用选项 1，则很难做到这一点。这样，我们就不必调整我们的规模Cassandra 集群可容纳 TB 级的冷数据。

我的问题:2.对于我们的用例来说是一个合理的选择，还是这被认为是 Cassandra 中的反模式？

感谢您的帮助!

Answer 1

通常，您不希望将旧的冷数据放在单独的键空间中，因为这将很难维护(正如您所提到的)。现在，由于您对数据的分区方式，您面临的挑战似乎是非常宽的行。相反，我建议您按月“存储”数据。这可以通过修改分区键来完成，如下所示:

PRIMARY KEY ((year,month,sensor_id), measurement_date)

额外的括号是用于声明多个列作为分区键的 CQL 语法。这意味着您始终必须提供年、月和sensor_id 才能从此表中读取。但请记住，在 Cassandra 中，主键(与关系数据库不同)定义了数据在集群中的分布方式。因此，我们所做的实际上是在其自己的行中将传感器数据逆向一年一个月。因此，我们基本上通过多个键空间实现了您的想法，但以一种对 Cassandra 和开发人员更加友好的方式。

要将数据插入到该表中将非常容易。假设measurement_date是一个timeuuid(应该是这样，否则你可能会覆盖数据)这里是你的代码将执行的一般流程:

1. 生成当前时间的 timeuuid (UUIDv1)
2. 从 timeuuid 获取年份和月份部分

3. 然后执行 CQL 进行 INSERT:

   • 插入 time_series (年、月、sensor_id、measurement_date) VALUES (2016,4,'sensor_id','在此处生成 timeuuid');

就像我在从表中读取数据之前提到的那样应该非常简单。如果您想要更多信息，我有一个与您的数据建模问题相关的更长的回复 here .

由于您每天要写入 500K 测量值，因此您将需要进一步存储这些数据(有关更多详细信息，请参阅上面的 SO 答案)，因为通常当您的聚类列超过 10k 标记时，C* 开始表现不佳。

最后您可能想阅读Optimizing Cold SS Tables因为它提供了一些很好的信息。例如，您可以调整 Cold_reads_to_omit，这样您就不会浪费时间压缩非常冷的表。对于DTCS，您可以设置max_sstable_age_days来停止压缩特定年龄的SS表，以节省冷表上的IO。

更新:存储大小管理:如果您想继续只使用一张表来处理所有事情，则可以进行一些调整。首先确保表正在使用压缩(最好是 lz4)，接下来您可以降低复制因子，这也可以节省空间。我想如果你对旧数据和新数据有不同的 key 空间，你可以为每个数据使用不同的 RF 以节省空间。

对于您推送并需要存档的数据量，我鼓励您研究时间序列数据库 (TSDB)，例如 Graphite 和 InfluxDB。对于您的目标和挑战，TSDB 比使用 Cassandra 处理时间序列数据更容易使用和执行。