Cassandra 时间序列数据（正确的方法？）

Question

我们有一个包含大量时间序列数据的表。可能我们必须在该表中每毫秒存储几个条目。为了满足这些要求，表格看起来像

CREATE TABLE statistic (
    name        text,
    id          uuid,
    start       timestamp,
    other_data  ...,

PRIMARY KEY (name, start, id)
) WITH CLUSTERING ORDER BY (start DESC);

如您所见，该表由两个聚类键组成，start 存储数据到达的时间，id 的目的是避免数据同时到达时被覆盖。

现在可以了，我们可以像这样进行范围查询

SELECT * FROM statistic WHERE name ='foo' AND start >= 1453730078182
     AND start <= 1453730078251;

但我们还需要能够在查询中添加额外的搜索参数，例如

SELECT * FROM statistic WHERE name = 'foo' 
    AND start >= 1453730078182 AND start <= 1453730078251 AND other_data = 'bar';

这当然行不通，因为other_data 不是主键的一部分。如果我们将它添加到主键，我们会得到以下错误

InvalidRequest: code=2200 [Invalid query] message="PRIMARY KEY 列 "other_data" 不能被限制（前面的列 "start" 受非 EQ 关系限制）"

没关系，这不是Cassandra 的工作方式（我认为）。

我们解决问题的方法是使用上述（第一个）范围查询选择所需的（时间序列）数据，然后在我们的 Java 应用程序中过滤数据。这意味着我们遍历列表并剔除 Java 应用程序中不需要的所有数据。一个条目没有太多数据，但在最坏的情况下，我们可能会讨论数百万行。

现在我有两个问题：

1. 这是解决问题的正确方法吗？
2. Cassandra 是否能够处理这么多数据？

Answer 1

这当然行不通，因为 other_data 不是主键的一部分。如果我们将它添加到主键，我们会得到以下错误

这是 other_data 列上二级索引的最佳选择。在您的情况下，此索引将扩展，因为您始终提供分区键 (name)，因此 Cassandra 不会命中集群中的所有节点。

使用 other_data 上的二级索引，您的第二个 SELECT 语句将成为可能。

现在您的数据模型还有另一个问题，即分区大小。实际上，如果您要每个名称每毫秒插入几个条目，这将无法扩展，因为每个名称的分区会增长得非常快...

如果插入分布在不同的分区键（不同的名称）上，那很好