【发布时间】：2018-02-08 00:44:01
【问题描述】：
我正在尝试使用 Cassandra 存储来自某些传感器的数据。 我阅读了很多关于 Cassandra 时间序列数据模型的文章。我从Getting Started with Time Series Data Modeling 开始，“时间序列模式 2”看起来是最好的方法。 所以我创建了一个复制因子为 2 的键空间和一个像这样的表
CREATE TABLE sensors_radio.draw (
dvid uuid,
bucket_time date,
utc_time double,
fft_size int,
n_avg int,
n_blocks int,
power double,
sample_rate double,
start_freq double,
PRIMARY KEY ((dvid, bucket_time), utc_time)
dvid 是唯一的设备 ID，bucket_time 是一天（例如 2017-08-30），utc_time 是时间戳。
我的查询是
SELECT utc_time,start_freq,sample_rate,fft_size,n_avg,n_blocks,power
FROM sensors_radio.draw
WHERE dvid=<dvid>
AND bucket_time IN (<list-of-days>)
AND utc_time>=1.4988002E9
AND utc_time<1.4988734E9;
如您所见，我需要检索多天的数据，这意味着读取集群中的多个分区。在我看来，查询性能看起来很差，由于 IN 反模式，这是可以理解的。
编辑：我试图通过将查询拆分为多个来避免 IN 反模式，但我没有得到任何性能提升。
我考虑通过使用 month 而不是 day 作为 bucket_time 来增加我的分区大小，以使用我的查询来查询单个分区。
但我担心分区会增长太多！通过阅读this question 的答案，我发现在一个月内我的分区将拥有大约 5 亿个单元（远低于 20 亿个限制），但它当然会超过 100MB 大小限制和 100000 行限制。
在这种情况下推荐的数据模型是什么？大磁盘分区是个问题吗？
提前致谢。
附言。我在由 3 个节点（8 核，16GB 内存）组成的集群上使用 Cassandra 3.10
【问题讨论】：
-
IN 实际上是一种反模式，因为多分区查询通常“太慢”。此外，磁盘上的大分区还会导致压缩和读取性能出现其他一些问题。
-
我强烈建议从 3.2 迁移到 3.11，尤其是 3.9 之前的版本有很多问题。
-
对不起，我的错误。我正在使用 Cassandra 3.10。如果我更新到 3.11，我会丢失数据吗？
-
升级 cassandra 是相当安全的 - 留意你的配置。阅读您对新 cassandra.yaml 的所有更改并查找
nodetool upgradesstables（请参阅 docs.datastax.com/en/cassandra/3.0/cassandra/tools/…）
标签： cassandra time-series