关于elasticsearch:Elasticsearch基本概念和索引原理

我是啤酒就辣条。

但行好事，莫问前程。

Elasticsearch是什么？

Elasticsearch是一个基于文档的NoSQL数据库，是一个分布式、RESTful格调的搜寻和数据分析引擎，同时也是Elastic Stack的外围，集中存储数据。Elasticsearch、Logstash、Kibana常常被用作日志剖析零碎，俗称ELK。

说白了，就是一个数据库，搜寻贼快(然而插入更新较慢，要不然其余数据库别玩了)。速度快，还能够进行分词，非常适合做搜寻，例如商城的商品搜寻。为什么快，前面讲原理的时候会说，不单单是缓存的问题，原理十分精彩。而且它是nosql的，数据格式能够轻易造。Elasticsearch还为咱们提供了丰盛的RESTful格调的API，写代码的老本极低。最初它反对分布式，高性能(搜寻快)，高可用(某些节点宕机能够接着用)，可伸缩(能够不便的减少节点，解决物理内存上线问题)，适宜分布式系统开发。

Elasticsearch基本概念

为了疾速理解Elasticsearch(前面可能会简称为ES)，能够与mysql几个概念做个比照。

是不是分明多了？咱们说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节点依据性能能够分为三种：

1. 主节点：职责是和集群操作相干的内容，如创立或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片调配给相干的节点。每个节点都可拜访集群的状态，然而只有主节点能够批改集群的状态。
2. 数据节点：数据节点次要是贮存数据的节点，对文档进行增删改查，聚合操作等等，数据节点对cpu，内存，io要求较高，当资源不够的时候，能够减少新的节点，很不便的进行数据拓展。
3. 客户端节点：本节点次要解决路由申请，散发索引的操作。实际上主节点和数据节点也有路由转发的性能，然而为了提高效率，还是倡议生产环境独自创立客户端节点。

分片相似于mysql中的分表，在一个索引拆分成几个小索引，散布在不同的节点(不同服务器)上，每个小索引都具备齐备的性能，当客户端发来申请的时候，客户端节点找到适合的分片上的小索引，进行数据查问，这一过程对于用户来说都是通明的，用户外表上看只是在操作一个索引。利用分片，能够防止单个节点的物理限度，还能够减少吞吐量。倡议最开始一个索引要用多少分片设计好，因为批改分片数量是个相当麻烦的过程。

作为分布式的数据库，ES必须为咱们提供数据冗余性能，这就是分片正本，就是将某个分片copy一份放到其余节点上。留神，这里分片和分片正本必须在不同的节点上！分片正本也能够进步吞吐量。分片正本不同于分片，能够很不便的进行批改。

说完了所有概念，再去看本节最开始那张图，有一个索引，分了3分片在三个节点上，并且每个分片在不同的节点上有分片正本。

Elasticsearch索引原理

看完下面的内容，你对Elasticsearch有了根本的意识，再去看基本操作(我前面要写一篇基操博客)，就能够在我的项目中应用Elasticsearch了。此刻你能够喘口气，以放松的心态看前面的内容。上面咱们就讲讲索引为什么快？

首先，咱们晓得mysql底层数据结构应用的是B+Tree，这种BTree，将搜寻工夫复杂度变成了logN，曾经很快了，咱们Elasticsearch要比它还快。Elasticsearch是怎么做的呢？首先贮存构造要优化，而后再进步下和磁盘的交互效率。

先说Elasticsearch索引构造，叫做倒排索引，啥是倒排索引呢？它的大略逻辑如下：

为了讲清楚这个概念，咱们先看个例子，如下为咱们user的数据：

Elasticsearch会为以上数据建设两个索引树:

以上的索引树就叫做倒排索引，每个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中。