elasticsearch java对象 驼峰原则_Elasticsearch基本概念和索引原理

我是啤酒就辣条。

但行好事，莫问前程。

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节点根据功能可以分为三种：

1. 主节点：职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。每个节点都可访问集群的状态，但是只有主节点可以修改集群的状态。

2. 数据节点：数据节点主要是储存数据的节点，对文档进行增删改查，聚合操作等等，数据节点对cpu，内存，io要求较高，当资源不够的时候，可以增加新的节点，很方便的进行数据拓展。

3. 客户端节点：本节点主要处理路由请求，分发索引的操作。实际上主节点和数据节点也有路由转发的功能，但是为了提高效率，还是建议生产环境单独创建客户端节点。

分片类似于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中。