Cassandra 查询灵活性

Question

我是大数据领域的新手，目前坚持一个基本决定。

对于一个研究项目，我需要每分钟将数百万条日志条目存储到我基于 Cassandra 的数据中心，这工作得很好。 （单数据中心，4个节点）

Log Entry
------------------------------------------------------------------
| Timestamp              | IP1         | IP2           ... 
------------------------------------------------------------------
| 2015-01-01 01:05:01    | 10.10.10.1  | 192.10.10.1   ...
------------------------------------------------------------------

每个日志条目都有一个特定的时间戳。日志条目应首先按不同的时间范围进行查询。正如建议的那样，我开始以大行的方式“模拟我的查询”。

Basic C* Schema
------------------------------------------------------------------
| row key              | column key a         | column key b     ... 
------------------------------------------------------------------
|  2015-01-01 01:05    | 2015-01-01 01:05:01  | 2015-01-01 01:05:23
------------------------------------------------------------------

更多细节： 列键是时间戳+uuid的组合，是唯一的，避免覆盖； 特定时间的日志条目通过其相同的分区键存储在节点附近；

因此，日志条目以每行的短时间间隔存储。例如，2015-01-01 01:05 的每个日志条目都具有一分钟的精度。查询并没有真正作为具有< 运算符的范围查询来执行，而是将条目选择为指定分钟的块。

基于范围的查询在相当长的响应时间内成功，这对我来说很好。

问题： 在下一步中，我们希望通过查询获得更多信息，这些信息主要集中在IP 字段上。例如：选择所有具有IP1=xx.xx.xx.xx和IP2=yy.yy.yy.yy的条目。

因此，很明显，当前模型无法用于其他以 IP 为中心的 CQL 查询。所以问题不是找到一个可能的解决方案，而是可能的技术的各种选择可能是一个可能的解决方案：

1. 尝试使用独立的 C* 解决方案解决问题。 （构建第二个模型并以不同的形式管理相同的数据）
2. 选择其他技术，例如 Spark...
3. 切换到 HDFS/Hadoop - Cassandra/Hadoop 解决方案...
4. 等等

由于我在这个领域缺乏知识，很难找到我应该采取的最佳方式。尤其是感觉使用集群计算框架会是一个过度的解决方案。

Answer 1

据我了解您的问题，您的表架构如下所示：

create table logs (
  minute timestamp,
  id timeuuid,
  ips list<string>,
  message text,
  primary key (minute,id)
);

有了这个简单的架构，你：

• 可以获取特定分钟的所有日志。
• 可以获取短的分钟范围内的日志事件。
• 想通过 IP 查询数据集。

在我看来，实现这个想法有多种方式：

• 在 IP 地址上创建二级索引。但在 C* 中，您将失去按时间戳查询的能力：C* 无法合并主索引和二级索引（如 mysql/pgsql）。
• 非规范化数据。一次将您的日志事件写入两个表，首先针对时间戳查询（分钟+ts 作为 PK）进行优化，其次针对基于 IP 的查询（IP+ts 作为 PK）进行优化。
• 使用 spark 进行 分析 查询。但是 spark 每次都需要执行（完整？）表扫描（以一种漂亮的分布式 map-reduce 方式，但仍然是表扫描）以提取您请求的所有数据，因此您的所有查询都需要大量是时候完成了。如果您计划进行大量低延迟查询，这种方式可能会导致问题。
• 使用 ElasticSearch 等外部索引进行查询，使用 C* 存储数据。

在我看来，C* 做这些事情的方式是为不同的查询设置一组单独的表。它将使您能够执行极快的查询（但会增加存储成本）。