elasticsearch原理之搜索与聚合之谜

满足海量数据实时聚合要求的数据库不多，比较常见的有这么几种：

• 基于 Lucene构建的“搜索引擎”： Elasticsearch,  Crate.io（虽然是基于 Elasticsearch，但是聚合逻辑是自己实现的）， Solr；
• 列式存储数据库： Vertica（ C-store的后裔） Actian（ Monetdb的后裔）等；
• Druid.io。

其中Elasticsearch是目前市场上比较很少有的，能够在检索加载和分布式计算三个方面都做得一流的数据库。而且是开源并且免费的。它使用了很多技术来达到飞一般的速度。这些主要的优化措施可以列举如下。

• Lucene的inverted index可以比mysql的b-tree检索更快。
• 在 Mysql中给两个字段独立建立的索引无法联合起来使用，必须对联合查询的场景建立复合索引。而lucene可以任何AND或者OR组合使用索引进行检索。
• Elasticsearch支持nested document，可以把一批数据点嵌套存储为一个document block，减少需要索引的文档数。
• Opentsdb不支持二级索引，只有一个基于hbase rowkey的主索引，可以按行的排序顺序scan。这使得Opentsdb的tag实现从检索效率上来说很慢。
• Mysql 如果经过索引过滤之后仍然要加载很多行的话，出于效率考虑query planner经常会选择进行全表扫描。所以Mysql的存储时间序列的最佳实践是不使用二级索引，只使用clustered index扫描主表。类似于Opentsdb。
• Lucene 从 4.0 开始支持 DocValues，极大降低了内存的占用，减少了磁盘上的尺寸并且提高了加载数据到内存计算的吞吐能力。
• Lucene支持分segment，Elasticsearch支持分index。Elasticsearch可以把分开的数据当成一张表来查询和聚合。相比之下Mysql如果自己做分库分表的时候，联合查询不方便。
• Elasticsearch 从1.0开始支持aggregation，基本上有了普通SQL的聚合能力。从 2.0 开始支持 pipeline aggregation，可以支持类似SQL sub query的嵌套聚合的能力。这种聚合能力相比Crate.io，Solr等同门师兄弟要强大得多。

查询效率之快的三个重要技术：

mmap来加载单独需要索引的列(memory mapped byte buffer)；

各种posting list的压缩方案来压缩；

Roaring Bitmap数据结构做逻辑操作；

参考：

1、 elasticsearch原理篇, 文章从检索、加载、分布式聚合三个方面，深入的剖析了es比mysql、opentsdb等数据查询、聚合更快速的原因；

1.1、时间序列数据库的秘密（1）—— 介绍
http://www.infoq.com/cn/articles/database-timestamp-01
1.2、时间序列数据库的秘密(2)——索引
http://www.infoq.com/cn/articles/database-timestamp-02
1.3、时间序列数据库的秘密（3）——加载和分布式计算
http://www.infoq.com/cn/articles/database-timestamp-03