问题描述
我正在学习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的理想数据库，因此探索一些其他工具很有用。