为日期查询构造Cassandra表

如何解决为日期查询构造Cassandra表

我正在学习Cassandra，作为练习数据集，我正在从Yahoo获取历史股票数据。每个交易日都会有一个记录。

很显然，我需要将股票代码作为分区键的一部分。我看到有关是否应该将日期作为分区键的一部分，还是将其设置为群集列的信息？

实际上，股票市场每年开放〜253天。因此，单个股票每年将有253条记录。我不是要建立一个完整的数据库，而是要对其进行设计以适应/正确地进行。

如果我将日期作为分区键的一部分，那难道不会分散到各个节点上吗？使日期范围查询变慢？

解决方法

如果我将日期作为分区键的一部分，那难道不会分散到各个节点上吗？使日期范围查询变慢？

是的，请在两个帐户上均进行更正。该建模方法称为“时间段”，其主要用例是随着时间增长的时间/事件数据。好消息是，除非您的分区预计会变大，否则您无需这样做。根据您目前的预测，每个分区每年写入253行，那么每年的数据量只会少于40kb（请参见下面使用nodetool tablehistograms进行的计算）。

出于您的目的，我认为通过symbol进行分区和通过day进行集群应该足够。

CREATE TABLE stockquotes (
 symbol text,day date,price decimal,PRIMARY KEY(symbol,day))
 WITH CLUSTERING ORDER BY (day DESC);

在大多数基于时间的用例中，我们倾向于更多地关注最近的数据（对于您的情况，这可能是正确的，也可能不是。）如果是这样，则以day降序写入数据将提高这些查询的性能。

然后（在写入一些数据之后），这样的日期范围查询将起作用：

SELECT * FROM stockquotes 
WHERE symbol='AAPL'
  AND day >= '2020-08-01' AND day < '2020-08-08';

 symbol | day        | price
--------+------------+--------
   AAPL | 2020-08-07 | 444.45
   AAPL | 2020-08-06 | 455.61
   AAPL | 2020-08-05 | 440.25
   AAPL | 2020-08-04 | 438.66
   AAPL | 2020-08-03 | 435.75

(5 rows)

要验证分区大小，可以使用nodetool tablehistograms（一旦将数据刷新到磁盘上）。

bin/nodetool tablehistograms stackoverflow.stockquotes
stackoverflow/stockquotes histograms
Percentile      Read Latency     Write Latency          SSTables    Partition Size        Cell Count
                    (micros)          (micros)                             (bytes)
50%                     0.00              0.00              0.00               124                 5
75%                     0.00              0.00              0.00               124                 5
95%                     0.00              0.00              0.00               124                 5
98%                     0.00              0.00              0.00               124                 5
99%                     0.00              0.00              0.00               124                 5
Min                     0.00              0.00              0.00               104                 5
Max                     0.00              0.00              0.00               124                 5

每年分区大小= 124字节x 253 = 31kb

鉴于分区的大小，此模型可能至少对30年的数据有效（ 30），然后再放慢速度（我建议保持分区quartercentiry之类的设备上进行存储就足够了吗？无论如何，短期内都会没事的。

编辑：

似乎PK中使用的任何日期部分都会在节点之间散布数据，不是吗？

是的，分区键中使用的日期部分会将数据分散到各个节点上。这实际上就是这样做的重点。您不想以未绑定行增长的反模式而告终，因为分区最终将变得如此之大，以致于无法使用。这个想法是关于确保适当的数据分发。

让我们说1 /秒，我需要跨年查询等等。

因此，使用时间存储的技巧是在数据分发和查询灵活性之间找到一个“快乐的媒介”。不幸的是，在某些情况下查询可能会触及多个分区（节点）。但是想法是建立一个模型来很好地处理其中的大多数问题。

这里的示例问题是一年1秒，这有点极端。但是解决这个问题的想法是相同的。一天有86400秒。根据行的大小，这甚至可能每天都太多了。但是为了争辩，可以说。如果我们每天忙碌，则PK看起来像这样：

PRIMARY KEY ((symbol,day),timestamp)

WHERE子句开始看起来像这样：

WHERE symbol='AAPL' AND day IN ('2020-08-06','2020-08-07');

从另一方面来说，几天没事，但查询整年会很麻烦。此外，我们不希望构建253天的IN子句。实际上，我不建议人们在IN上使用位数不能超过个位数。

这里一种可能的方法是从应用程序触发253个异步查询（每天一个），然后在该处组装并排序结果集。在这里使用Spark（在RDD中执行所有操作）也是一个不错的选择。实际上，Cassandra并不是报告API的理想数据库，因此探索一些其他工具很有用。