Elasticsearch是什么？
Elasticsearch是一个基于文档的NoSQL数据库，是一个分布式、RESTful风格的搜索和数据分析引擎，同时也是Elastic Stack的核心，集中存储数据。Elasticsearch、Logstash、Kibana经常被用作日志分析系统，俗称ELK。
说白了，就是一个数据库，搜索贼快(但是插入更新较慢，要不然其他数据库别玩了)。速度快，还可以进行分词，非常适合做搜索，例如商城的商品搜索。为什么快，后面讲原理的时候会说，不单单是缓存的问题，原理非常精彩。而且它是nosql的，数据格式可以随便造。Elasticsearch还为我们提供了丰富的RESTful风格的API，写代码的成本极低。最后它支持分布式，高性能(搜索快)，高可用(某些节点宕机可以接着用)，可伸缩(可以方便的增加节点，解决物理内存上线问题)，适合分布式系统开发。
Elasticsearch基本概念
为了快速了解Elasticsearch(后面可能会简称为ES)，可以与mysql几个概念做个对比。
| Elasticsearch | Mysql |
|---|
| 字段(Filed) | 属性(列) |
| 文档(Document) | 记录(行) |
| 类型(Type) | 表 |
| 索引(Index) | 数据库 |
是不是清楚多了？我们说Elasticsearch是基于文档的，就是因为记录元素(被搜索的最小单位)是文档。例如下面就是一个文档，
{
"email": "john@smith.com",
"first_name": "John",
"last_name": "Smith",
"info": {
"bio": "Eco-warrior and defender of the weak",
"age": 25,
"interests": [ "dolphins", "whales" ]
},
"join_date": "2014/05/01"
}
文档格式看起来很像Json吧。email、first_name等等就是Filed。由于结构是Json，所以value值就很方便放任意类型，这就是nosql的好处。
文档(Document)
ES中的一个对象将来会和Java代码中的一个对象对应。文档的每一个Filed可以是任意类型，但是一旦某索引(Index)(我们描述的时候，略过Type，但是Type依然存在)中插入了一个文档，某Filed被第一次使用，ES就会设置好此Filed的类型。例如你插入user的name是字符串类型，以后再插入文档，name字段必须是字符串类型。所以，建议在插入文档之前，先设置好每个Filed的类型。
如果插入文档的时候，不指定id，ES会帮助我们自动生成一个id，建议id是数字类型，这样搜索会快速很多。商城系统中的商品id建议使用雪花算法生成，这样既避免了自增id的安全性问题，又解决了字符串id检索慢的问题。
类型(Type)
关于Type，类型概念,在6.x版本中，一个索引(Index)可以拥有多个Type。在7.x版本(目前最新版本)，一个索引只能拥有一个Type，默认的type就是_doc，在7.x版本中，已经建议删除了。在未来的8.x版本会彻底删除。但是在7.x版本中，一个文档还必须归属于一个类型。
索引(Index)
都说ES中的索引类似于mysql中的数据库，我觉得未来索引有成为mysql中表概念的潜质。我们把相同特征(Filed数量和类型基本相同)的文档放到同一个索引(index)里面。这样方便提前通过mapping来规定各个Filed的类型。另外，索引名称必须全部小写，所以不建议写成驼峰式。
节点(Node)与分片(Shard)
由于生产环境下ES基本都是集群部署的，所以一定少不了节点的概念，一个节点就是一个ES实例，就是一个Java进程，这些Java进程部署在不同的服务器上，增加ES可用性。
ES节点根据功能可以分为三种：
- 主节点：职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。每个节点都可访问集群的状态，但是只有主节点可以修改集群的状态。
- 数据节点：数据节点主要是储存数据的节点，对文档进行增删改查，聚合操作等等，数据节点对cpu，内存，io要求较高，当资源不够的时候，可以增加新的节点，很方便的进行数据拓展。
- 客户端节点：本节点主要处理路由请求，分发索引的操作。实际上主节点和数据节点也有路由转发的功能，但是为了提高效率，还是建议生产环境单独创建客户端节点。
分片类似于mysql中的分表，在一个索引拆分成几个小索引，分布在不同的节点(不同服务器)上，每个小索引都具有完备的功能，当客户端发来请求的时候，客户端节点找到合适的分片上的小索引，进行数据查询，这一过程对于用户来说都是透明的，用户表面上看只是在操作一个索引。利用分片，可以避免单个节点的物理限制，还可以增加吞吐量。建议最开始一个索引要用多少分片设计好，因为修改分片数量是个相当麻烦的过程。
作为分布式的数据库，ES必须为咱们提供数据冗余功能，这就是分片副本，就是将某个分片copy一份放到其他节点上。注意，这里分片和分片副本必须在不同的节点上！分片副本也可以提高吞吐量。分片副本不同于分片，可以很方便的进行修改。
说完了所有概念，再去看本节最开始那张图，有一个索引，分了3分片在三个节点上，并且每个分片在不同的节点上有分片副本。
Elasticsearch索引原理
看完上面的内容，你对Elasticsearch有了基本的认识，再去看基本操作(我后面要写一篇基操博客)，就可以在项目中使用Elasticsearch了。此刻你可以喘口气，以放松的心态看后面的内容。下面我们就讲讲索引为什么快？
首先，我们知道mysql底层数据结构使用的是B+Tree，这种BTree，将搜索时间复杂度变成了logN，已经很快了，我们Elasticsearch要比它还快。Elasticsearch是怎么做的呢？首先储存结构要优化，然后再提高下和磁盘的交互效率。
先说Elasticsearch索引结构，叫做倒排索引，啥是倒排索引呢？它的大概逻辑如下：
为了讲清楚这个概念，我们先看个例子，如下为我们user的数据：
| ID | Name | Age |
|---|
| 1 | Kate | 24 |
| 2 | John | 24 |
| 3 | Bill | 29 |
| 4 | Kate | 26 |
| 5 | Brand | 29 |
Elasticsearch会为以上数据建立两个索引树:
| Term | Posting List |
|---|
| Kate | 1,4 |
| Brand | 5 |
| John | 2 |
| Bill | 3 |
| Term | Posting List |
|---|
| 24 | 1,2 |
| 26 | 4 |
| 29 | 3,5 |
以上的索引树就叫做倒排索引，每个Filed字段对应着一组Term，每个Term后面跟着的id(还记着吗，这个主键用户不指定就会自动生成，所以一定存在)就是Posting List，它是一组id，有了id再去磁盘中对应的文档就so fast了。
你有没有发现，Term如果按序找会快点，将Term按序排，在进行二分查找，是不是速度就跟BTree一样了，时间复杂度为LogN。这个有序的Term组就是Term Dictionary。
那么问题又来了，比如说数据库中有name前缀为A的同学1000万个，前缀为Z的同学有3个，我要查前缀为Z的同学，那二分查找不也很多次吗，所以，Elasticsearch把每个开头的地方标记一下，拿出来，再放到一颗树里，速度不是就快了嘛。这棵树就是Term Index。Term Index前缀不一定是第一个字符，比如A、Ab、Abz，这种都可以在Term Index树里。并且Term Dictionary可能会太大，会被放到磁盘中，避免内存占用太多。
再看下面这张结构图是不是清楚多了。
由于Term Index被放到内存中，所以最好压缩一下，减少内存使用，压缩使用的是FST，这个东西讲起来比较复杂，反正就是能压缩，内存变小就好了。
Term压缩完了，那么Posting List是不是也可以压缩一下，省省空间啊？既然都是id，使用过redis的同学瞬间会想到bitMap，就是有个巨大的数组，储存着0或1，有就是1，没有就是0。例如上面的3、5放在BitMap中就是 1，0，1，0，0，0。虽说空间已经明显小多了，但是如果一个Posting List只储存着1，10000001这两个id，最后产生的数字是不是过大呢。于是乎，Roaring bitmaps就出来了，进行了一次指数降级，简单点说就是取商和余数储存，被除数是65535。例如 1000，62101，131385，196658， 这几个id，首先分组，分组规则就是商一样，例如上面id可分组为[(0,1000),(0,62101)],[],[(2,6915)],[(3,53)]。注意，没有商为1的值，我用空数组表示。此时，将某个组中的数字放到一个bitmap中。
