Elasticsearch是一个分布式可拓展的实时搜索和分析引擎

  分布式实时文件存储,并将每一个字段都编入索引,使其可以被搜索

  实时分析的分布式搜索引擎

  可以拓展到上百台服务器,处理PB级别的结构化或非结构化数据

文件存储:Elasticsearch,面向文档型数据库,一条数据就是一个文档,用JSON作为文档序列化的格式

MySQL和Elasticsearch数据关系术语对比:

  关系数据库-数据库-表-行-列

  Elasticsearch-索引-类型-文档-字段

Elasticsearch的交互:可以使用Java API,也可以直接使用HTTP的Restful API方式

Elasticsearch强大的索引能力:精髓-一切设计都是为了提高搜索的性能

什么是倒排索引?举个例子

| ID | Name | Age | Sex |

| - - |:-------:| -----:| -----:|

| 1 | Kate | 24 | Female

| 2 | John | 24 | Male

| 3 | Bill | 29 | Male

ID是Elasticsearch自建的文档ID,Name、Age、Sex索引如下:

Name:| Term | Posting List |

   | -- |:----:|

   | Kate | 1 |

   | John | 2 |

   | Bill | 3 |

Age:| Term | Posting List |

  | -- |:----:|

  | 24 | [1,2] |

  | 29 | 3 |

Sex:| Term | Posting List |

  | -- |:----:|

  | Female | 1 |

  | Male | [2,3] |

Posting List

  Elasticsearch分别为每个field都建立了一个倒排索引,

  Kate ,24,Female,John,Male,Bill,29这些是Term。

  而1,2,3是文档ID,[1][3][1,2][2,3]这些就是Posting List。

  Posting List就是一个int的数组,存储了所有符合这个Term的文档ID。

Term Dictionnary

  Elasticsearch将所有的Term排个序,二分法查找Term,logN的查找效率。

Term Index

  Term Index是Term Dictionnary的索引,包含的是Term的一些前缀。

Frame Of Reference

  Elasticsearch要求Posting List是有序的,方便压缩。

  原理:通过增量,将原来的大数变成小数,仅储存增量值,再按bit排好队,最后通过字节存储。

Roaring Bitmaps

  Bitmap是一种数据结构,假设Posting List[1,3,4,7,10],对应的Bitmap就是[1,0,1,1,0,0,1,0,0,1],非常直观,用0/1表示某个值是否存在。

  Bitmap的缺点是存储空间随着文档个数线性增长。Roaring bitmaps需要用到某些指数特性:将posting list按照65535为界限分块,用<商,余数>的组合表示每一组id。

联合索引

  如果多个field索引的联合查询,倒排索引如何满足快速查询的要求呢?

  利用跳表的数据结构快速做”与“运算,或者利用bitset按位”与“。

Elasticsearch的索引思路:

  将磁盘里的东西尽量搬进内存,减少磁盘随机读取次数(同时也利用磁盘顺序读特性),结合各种压缩算法,用极其苛刻的态度使用内存。

所以,对于使用Elasticsearch进行索引时需要注意:

  不需要索引的字段,一定要明确定义出来,因为默认是自动建索引的

  同样的道理,对于String类型的字段,不需要analysis的也需要明确定义出来,因为默认也是会analysis的

  选择有规律的ID很重要,随机性太大的ID(比如java的UUID)不利于查询

关于最后一点,个人认为有多个因素:

  上面看到的压缩算法,都是对Posting list里的大量ID进行压缩的,那如果ID是顺序的,或者是有公共前缀等具有一定规律性的ID,压缩比会比较高;

  最影响查询性能的,应该是最后通过Posting list里的ID到磁盘中查找Document信息的那步,因为Elasticsearch是分Segment存储的,Term定位到Segment的效率直接影响了最后查询的性能,

  如果ID是有规律的,可以快速跳过不包含该ID的Segment,从而减少不必要的磁盘读次数