学习Elasticsearch原理笔记

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

文件存储：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，从而减小没必要要的磁盘读次数