Cassandra时序数据时间范围查询：两种方案孰优孰劣？

我在不同位置部署了传感器，每个传感器每日产生约200万条多参数测量数据，查询需求为按位置+不超过几天的时间范围查询，示例查询如下：

SELECT * FROM meas WHERE latitude=46.1 AND longitude=15.1 AND measurementTime >= 2023-10-15T23:00:00Z AND measurementTime <= 2023-10-16T01:00:00Z;

为控制分区大小，我采用基于时间窗口的分桶方式，将分区按纪元日拆分，表结构如下：

CREATE TABLE meas (
    latitude double,
    longitude double,
    dayOfMeasurement int,
    measurementTime timestamp,
    param1 double,
    param2 double, 
    param3 double, 
    etc...
    PRIMARY KEY ((latitude, longitude, dayOfMeasurement), measurementTime)
) WITH CLUSTERING ORDER BY (measurementTime DESC)

现有两种查询方案：

方案1：使用IN子句 #

SELECT * FROM meas WHERE latitude=46.1 AND longitude=15.1 AND dayOfMeasurement IN (19646,19645) AND measurementTime >= 2023-10-15T23:00:00Z AND measurementTime <= 2023-10-16T01:00:00Z;

方案2：客户端拆分查询并合并结果 #

分别执行两个独立查询：

SELECT * FROM meas WHERE latitude=46.1 AND longitude=15.1 AND dayOfMeasurement=19645 AND measurementTime >= 2023-10-15T23:00:00Z AND measurementTime < 2023-10-16T00:00:00Z;

SELECT * FROM meas WHERE latitude=46.1 AND longitude=15.1 AND dayOfMeasurement=19646 AND measurementTime >= 2023-10-16T00:00:00Z AND measurementTime <= 2023-10-16T01:00:00Z;

请问哪种方案更优？若方案2更优，DataStax Java Driver是否有标准的结果合并方式？或者是否存在更合适的数据模型？

方案选择：方案2更优 #

方案2相比方案1有两个核心优势：

1. 避免Coordinator节点瓶颈：Cassandra的IN查询会由单个Coordinator节点依次请求所有目标分区，再汇总结果返回给客户端。而方案2中客户端可以并行发起多个查询，请求会分散到不同的节点（如果分区分布在不同节点），避免Coordinator成为单点性能瓶颈，尤其当查询涉及多个分区时，并行查询的延迟更低。
2. 更精准的数据过滤：方案2中每个查询的时间范围完全匹配对应dayOfMeasurement的区间，Cassandra可以利用聚类键measurementTime的有序性直接定位到目标数据，减少不必要的扫描；而方案1的IN查询虽然也有时间过滤，但Coordinator需要处理跨分区的数据筛选和合并，额外的处理成本更高。

DataStax Java Driver的结果合并方式 #

Driver本身没有直接的"合并结果"API，但可以通过异步API结合Java并发工具实现高效合并：

1. 并行执行异步查询：使用Driver的AsyncSession发起多个异步查询，得到CompletableFuture<AsyncResultSet>集合。
2. 等待所有查询完成：通过CompletableFuture.allOf()等待所有异步请求完成。
3. 合并并排序结果：由于每个查询的结果是按measurementTime DESC排序的，可以通过归并排序合并多个有序结果流；如果不需要严格排序，直接合并所有行即可。

示例代码片段：

// 假设已经初始化AsyncSession
AsyncSession session = ...;

// 定义两个查询语句
String query1 = "SELECT * FROM meas WHERE latitude=46.1 AND longitude=15.1 AND dayOfMeasurement=19645 AND measurementTime >= '2023-10-15T23:00:00Z' AND measurementTime < '2023-10-16T00:00:00Z'";
String query2 = "SELECT * FROM meas WHERE latitude=46.1 AND longitude=15.1 AND dayOfMeasurement=19646 AND measurementTime >= '2023-10-16T00:00:00Z' AND measurementTime <= '2023-10-16T01:00:00Z'";

// 发起异步查询
CompletableFuture<AsyncResultSet> future1 = session.executeAsync(SimpleStatement.newInstance(query1));
CompletableFuture<AsyncResultSet> future2 = session.executeAsync(SimpleStatement.newInstance(query2));

// 等待所有查询完成，合并结果
CompletableFuture.allOf(future1, future2)
    .thenApply(v -> {
        List<Row> allRows = new ArrayList<>();
        // 处理第一个结果集
        future1.join().all().forEach(allRows::add);
        // 处理第二个结果集
        future2.join().all().forEach(allRows::add);
        // 如果需要按measurementTime排序，这里可以添加排序逻辑
        allRows.sort(Comparator.comparing(Row::getTimestamp, Comparator.reverseOrder()));
        return allRows;
    })
    .thenAccept(rows -> {
        // 处理合并后的结果
        rows.forEach(row -> System.out.println(row.getTimestamp("measurementTime")));
    })
    .exceptionally(ex -> {
        // 处理异常
        ex.printStackTrace();
        return null;
    });

更合适的数据模型建议 #

当前的日分桶模型已经适配查询模式，但可以做以下优化：

1. 解决经纬度精度问题：使用double存储经纬度可能存在精度丢失，导致相同实际位置的查询无法命中同一分区。建议将经纬度乘以1e6后转成bigint（比如46.1转成46100000），或者使用Geohash编码成字符串，确保同一位置的查询能精准命中分区。
2. 替换纪元日为date类型：将dayOfMeasurement的类型从int改为date，语义更清晰，Cassandra内部会将date存储为纪元日整数，性能无差异，但查询时可以直接使用日期字符串（比如'2023-10-15'），更易维护。
3. 考虑更小的时间桶：如果查询的时间范围经常小于1天，且单小时数据量（约8.3万条）在合理分区大小内，可以将分桶粒度改为小时（比如hourOfMeasurement），进一步减少单查询扫描的数据量。

内容的提问来源于stack exchange，提问作者jernejt