关于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 中。