hadoop - 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
------------------------------------------------------------------

其他详细信息:column keys由timestamp+uuid组成，唯一性，避免重写；特定时间的日志条目通过其相同的分区键存储在节点附近；

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

基于范围的查询在合适的响应时间内取得成功，这对我来说很好。

问题:在下一步中，我们希望通过查询获取更多信息，这些信息主要集中在 IP 上。 field 。例如:选择所有具有 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* 做这些事情的方法是为不同的查询设置一组单独的表。它将使您能够执行极快的查询(但会增加存储成本)。