时间序列数据库——索引用ES、聚合分析时加载数据用什么？docvalues的列存储貌似更优优点一些。那分布式计算呢？ES作

分布式计算

分布式聚合如何作得快

Elasticsearch/Lucene从最底层就支持数据分片，查询的时候能够自动把不一样分片的查询结果合并起来。Elasticsearch的document都有一个uid，默认策略是按照uid 的 hash把文档进行分片。

一个Elasticsearch Index至关于一个MySQL里的表，不一样Index的数据是物理上隔离开来的。Elasticsearch的Index会分红多个Shard存储，一 部分Shard是Replica备份。一个Shard是一份本地的存储（一个本地磁盘上的目录），也就是一个Lucene的Index。不一样的Shard 可能会被分配到不一样的主机节点上。一个Lucene Index会存储不少的doc，为了好管理，Lucene把Index再拆成了Segment存储（子目录）。Segment内的doc数量上限是1的 31次方，这样doc id就只须要一个int就能够存储。Segment对应了一些列文件存储索引（倒排表等）和主存储（DocValues等），这些文件内部又分为小的 Block进行压缩。

时间序列数据通常按照日期分红多个Elasticsearch Index来存储，好比logstash-2014.08.02。查询的时候能够指定多个Elasticsearch Index做为查找的范围，也能够用logstash-*作模糊匹配。

美妙之处在于，虽然数据被拆得七零八落的，在查询聚合的时候甚至须要分为两个阶段完成。可是对于最终用户来讲，使用起来就好像是一个数据库表同样。全部的合并查询的细节都是隐藏起来的。

对于聚合查询，其处理是分两阶段完成的：

• Shard本地的Lucene Index并行计算出局部的聚合结果；
• 收到全部的Shard的局部聚合结果，聚合出最终的聚合结果。

这种两阶段聚合的架构使得每一个shard不用把原数据返回，而只用返回数据量小得多的聚合结果。相比Opentsdb这样的数据库设计更合理。 Opentsdb其聚合只在最终节点处完成，全部的分片数据要汇聚到一个地方进行计算，这样带来大量的网络带宽消耗。因此Influxdb等更新的时间序列数据库选择把分布式计算模块和存储引擎进行同机部署，以减小网络带宽的影响。

除此以外Elasticsearch还有另一个减小聚合过程当中网络传输量的优化，那就是Hyperloglog算 法。在计算unique visitor（uv）这样的场景下，常常须要按用户id去重以后统计人数。最简单的实现是用一个hashset保存这些用户id。可是用set保存全部 的用户id作去重须要消耗大量的内存，同时分布式聚合的时候也要消耗大量的网络带宽。Hyperloglog算法以必定的偏差作为代价，能够用很小的数据 量保存这个set，从而减小网络传输消耗。

为何时间序列须要更复杂的聚合？

关系型数据库支持一些很复杂的聚合查询逻辑，好比：

• Join两张表；
• Group by以后用Having再对聚合结果进行过滤；
• 用子查询对聚合结果进行二次聚合。

在使用时间序列数据库的时候，咱们常常会怀念这些SQL的查询能力。在时间序列里有一个特别常见的需求就是降频和降维。举例以下：

12:05:05 湖南 81
12:05:07 江西 30
12:05:11 湖南 80
12:05:12 江西 32
12:05:16 湖南 80
12:05:16 江西 30

按1分钟频率进行max的降频操做得出的结果是：

12:05 湖南 81
12:05 江西 32

这种按max进行降频的最多见的场景是采样点的归一化。不一样的采集器采样的时间点是不一样的，为了不漏点也会加大采样率。这样就可能致使一分钟内采样屡次，并且采样点的时间都不对齐。在查询的时候按max进行降频能够得出一个统一时间点的数据。

按sum进行降维的结果是：

12:05 113

常常咱们须要舍弃掉某些维度进行一个加和的统计。这个统计须要在时间点对齐以后再进行计算。这就致使一个查询须要作两次，上面的例子里：

• 先按1分钟，用max作降频；
• 再去掉省份维度，用sum作降维。

若是仅仅能作一次聚合，要么用sum作聚合，要么用max作聚合。没法知足业务逻辑的需求。为了不在一个查询里作两次聚合，大部分的时间序列数据库都要求数据在入库的时候已是整点整分的。这就要求数据不能直接从采集点直接入库，而要通过一个实时计算管道进行处理。若是可以在查询的时候同时完成降频和降维，那就能够带来一些使用上的便利。

这个功能看似简单，其实很是难以实现。不少所谓的支持大数据的数据库都只支持简单的一次聚合操做。Elasticsearch 将要发布的 2.0 版本的最重量级的新特性是Pipeline Aggregation，它支持数据在聚合以后再作聚合。相似SQL的子查询和Having等功能都将被支持。

总结

时间序列随着Internet of Things等潮流的兴起正变得愈来愈常见。但愿本文能够帮助你了解到那些号称本身很是海量，查询很是快的时间序列数据库背后的秘密。没有完美的数据 库，Elasticsearch也不例外。若是你的用例根本不包括聚合的需求，也许Opentsdb甚至MySQL就是你最好的选择。可是若是你须要聚合海量的时间序列数据，必定要尝试一下Elasticsearch！