假设您有一个简单的 Cassandra 架构（使用 CQL3），可以每秒保存各种传感器的读数。 （时间序列）
create table sensor_readings (
sensorid varchar,
time timestamp,
value varchar,
primary key (sensorid, time)
)
是否有一种有效的方法可以在不同于记录的时间周期内检索数据？
例如，当所有数据都以每秒为基础存储时，您将如何仅检索每小时数据或每日数据？
您是否必须将所有数据检索到您的应用程序中，然后让您的应用程序过滤掉这些数据？或者 Cassandra 可以为您做这件事吗？
【问题讨论】：
标签： cassandra time-series cql nosql
不，这是你可以说 cassandra 的限制，它们现在没有像任何 RDBMS 数据库那样的日期功能，所以你不能有工具来检索和过滤数据。
正如您提到的，您已经检索了所有数据，然后在使用 java-script 或您必须用于过滤的东西之后。
【讨论】：
Cassandra 不会代表您进行任何聚合。因此，如果您需要以特定时间粒度对数据进行分组，则需要在插入时将数据点压缩到适当大小的时间窗口桶中。这是在 Cassandra 中处理时间序列数据时的常见模式。示例见this article。
或者，您可以在应用程序的查询时进行聚合，但您将从 Cassandra 流式传输大量数据。如果您可以在插入时执行此操作，您很可能会减少整体 IO 负载。
【讨论】：
由于 cassandra 不支持此类功能，您有两种不同的选择。当数据最初被持久化时，您可以在持久化过程之前计算聚合数据（并在以后持久化此类实体）。或者第二个 - 在成功持久化之后，这通常称为“按需”。
什么时候使用第一个，什么时候使用第二个选项？
首先显然更难，需要更多的资源。关键是，如果您总是需要该统计信息（聚合）并且这是您的应用程序的关键点，您应该在此过程中计算它们。如果聚合数据的使用率要低得多，您可以在用户要求时按需计算它们。
好吧，正如我在这里描述的问题，这两种方法似乎都是 RDBSM 索引方法与 NoSQL 中通常缺少索引之间的经典区别。 RDBMS 总是会计算它们，但会有一些性能损失和潜在的锁定问题。另一方面，一旦使用 NoSQL，通常需要您自己计算索引。
【讨论】：
经典的 Cassandra 方法是设计支持查询的附加表。 This is a concise paper describing the process.
所以，对于每小时数据，您将拥有另一个表格，例如
create table sensors_by_hour (
hour text,
sensorid varchar,
value varchar,
primary key (hour, sensorid)
)
您将同时写入两个表，显然是第二个在小时级别切割时间戳。这将为您提供特定小时的传感器和值。
等等
【讨论】：