cassandra查询灵活性

我对大数据领域相当陌生，目前正被一个根本性的决定绊倒。
对于一个研究项目，我需要每分钟将数百万个日志条目存储到我的基于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
------------------------------------------------------------------

附加细节：列键是timestamp+uuid的组合，具有唯一性，避免重写；特定时间的日志条目通过相同的分区密钥存储在节点附近；
因此，每行以短时间间隔存储日志条目。例如，的每个日志条目 2015-01-01 01:05 精确到一分钟。查询并不是真正形成为带有 < 运算符，而是将条目选择为指定分钟的块。
基于范围的查询成功地获得了不错的响应时间，这对我来说很好。
问：下一步我们希望通过查询获得更多的信息，这些信息主要集中在 IP 现场。例如：选择所有具有 IP1=xx.xx.xx.xx 以及 IP2=yy.yy.yy.yy .
所以很明显，当前的模型对于额外的以ip为中心的cql查询非常不可用。因此，问题不在于找到一个可能的解决方案，而在于各种可能的技术选择，这些技术可能是一个可能的解决方案：
试着用独立的c*解决方案来解决这个问题(构建第二个模型并以不同的形状管理相同的数据）
选择其他技术，如spark。。。
切换到hdfs/hadoop-cassandra/hadoop解决方案。。。
等等
由于我在这个领域缺乏知识，很难找到我应该采取的最佳方法。尤其是觉得使用集群计算框架将是一个过度的解决方案。

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

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

使用此简单模式，您可以：
可以获取特定分钟内的所有日志。
可以获取短时间间隔的日志事件。
要按ip查询数据集。
在我看来，实现这个想法有多种方法：
在ip地址上创建辅助索引。但是在c中，您将失去按时间戳进行查询的能力：c无法合并主索引和辅助索引（如mysql/pgsql）。
反规范化数据。一次将日志事件写入两个表，第一个表针对时间戳查询（minute+ts作为pk）进行优化，第二个表针对基于ip的查询（ip+ts作为pk）。
使用spark进行分析查询。但是spark每次都需要执行（full？）表扫描（以一种漂亮的分布式map reduce方式，但是它是一个表扫描）来提取您请求的所有数据，因此您的所有查询都需要大量时间才能完成。如果计划进行大量低延迟查询，这种方法可能会导致问题。
使用外部索引，如elasticsearch进行查询，使用c存储数据。
在我看来，做这些事情的c方法是为不同的查询提供一组单独的表。它将使您能够执行非常快速的查询（但存储成本会增加）。

cassandra查询灵活性

1条答案

相关问题

热门标签

最新问答