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，从而减少不必要的磁盘读次数