ES分布式文档数据库讲解

ES分布式文档数据库讲解

简介ES是一个基于RESTful web接口并且构建在Apache Lucene之上的开源分布式搜索引擎。

同时ES还是一个分布式文档数据库，其中每个字段均可被索引，而且每个字段的数据均可被搜索，能够横向扩展至数以百计的服务器存储以及处理PB级的数据。

可以在极短的时间内存储、搜索和分析大量的数据。通常作为具有复杂搜索场景情况下的核心发动机。

ES就是为高可用和可扩展而生的。一方面可以通过升级硬件来完成系统扩展，称为垂直或向上扩展（Vertical Scale/Scaling Up）。

另一方面，增加更多的服务器来完成系统扩展，称为水平扩展或者向外扩展（Horizontal Scale/Scaling Out）。尽管ES能够利用更强劲的硬件，但是垂直扩展毕竟还是有它的极限。真正的可扩展性来自于水平扩展，通过向集群中添加更多的节点来分担负载，增加可靠性。ES天生就是分布式的，它知道如何管理多个节点来完成扩展和实现高可用性。意味应用不需要做任何的改动。

Gateway，代表ES索引的持久化存储方式。在Gateway中，ES默认先把索引存储在内存中，然后当内存满的时候，再持久化到Gateway里。当ES集群关闭或重启的时候，它就会从Gateway里去读取索引数据。比如LocalFileSystem和HDFS、AS3等。

DistributedLucene Directory，它是Lucene里的一些列索引文件组成的目录。它负责管理这些索引文件。包括数据的读取、写入，以及索引的添加和合并等。

River，代表是数据源。是以插件的形式存在于ES中。

Mapping不仅是告诉ES，哪个字段是哪种类型。还能告诉ES如何来索引数据，以及数据是否被索引到等。

Search Moudle，搜索模块，支持搜索的一些常用操作

Index Moudle，索引模块，支持索引的一些常用操作

Disvcovery，主要是负责集群的master节点发现。比如某个节点突然离开或进来的情况，进行一个分片重新分片等。这里有个发现机制。

发现机制默认的实现方式是单播和多播的形式，即Zen，同时也支持点对点的实现。另外一种是以插件的形式，即EC2。

Scripting，即脚本语言。包括很多，这里不多赘述。如mvel、js、python等。

Transport，代表ES内部节点，代表跟集群的客户端交互。包括 Thrift、Memcached、Http等协议

RESTful Style API，通过RESTful方式来实现API编程。

3rd plugins，代表第三方插件。

Java(Netty)，是开发框架。

JMX，是监控。

使用案例1、将ES作为网站的主要后端系统

比如现在搭建一个博客系统，对于博客帖子的数据可以直接在ES上存储，并且使用ES来进行检索，统计。ES提供了持久化的存储、统计和很多其他数据存储的特性。

注意：但是像其他的NOSQL数据存储一样，ES是不支持事务的，如果要事务机制，还是考虑使用其他的数据库做真实库。

2、将ES添加到现有系统

有些时候不需要ES提供所有数据的存储功能，只是想在一个数据存储的基础之上使用ES。比如已经有一个复杂的系统在运行，但是现在想加一个搜索的功能，就可以使用该方案。

3、将ES作为现有解决方案的后端部分

因为ES是开源的系统，提供了直接的HTTP接口，并且现在有一个大型的生态系统在支持他。比如现在我们想部署大规模的日志框架、用于存储、搜索和分析海量的事件，考虑到现有的工具可以写入和读取ES，可以不需要进行任何开发，配置这些工具就可以去运作。

设计结构1、逻辑设计

文档

文档是可以被索引的信息的基本单位，它包含几个重要的属性：

是自我包含的。一篇文档同时包含字段和他们的取值。是层次型的。文档中还可以包含新的文档，一个字段的取值可以是简单的，例如location字段的取值可以是字符串，还可以包含其他字段和取值，比如可以同时包含城市和街道地址。拥有灵活的结构。文档不依赖于预先定义的模式。也就是说并非所有的文档都需要拥有相同的字段，并不受限于同一个模式{

"name":"meeting",

"location":"office",

"organizer":"yanping"

}

{

"name":"meeting",

"location":{

"name":"sheshouzuo",

"date":"2019-6-28"

},

"memebers":["leio","shiyi"]

}

类型

类型是文档的逻辑容器，类似于表格是行的容器。在不同的类型中，最好放入不同的结构的文档。

字段

ES中，每个文档，其实是以json形式存储的。而一个文档可以被视为多个字段的集合。

映射

每个类型中字段的定义称为映射。例如，name字段映射为String。

索引

索引是映射类型的容器一个ES的索引非常像关系型世界中的数据库，是独立的大量文档集合。

关系型数据库与ES的结构上的对比

2、物理设计

节点

一个节点是一个ES的实例，在服务器上启动ES之后，就拥有了一个节点，如果在另一个服务器上启动ES，这就是另一个节点。甚至可以在一台服务器上启动多个ES进程，在一台服务器上拥有多个节点。多个节点可以加入同一个集群。

当***的节点启动后，它会利用多播(multicast)(或者单播，如果用户更改了配置)寻找集群中的其它节点，并与之建立连接。这个过程如下图所示：

节点主要有3种类型，第一种类型是client_node，主要是起到请求分发的作用，类似路由。第二种类型是master_node，是主的节点，所有的新增，删除，数据分片都是由主节点操作（elasticsearch底层是没有更新数据操作的，上层对外提供的更新实际上是删除了再新增），当然也能承担搜索操作。第三种类型是date_node，该类型的节点只能做搜索操作，具体会分配到哪个date_node，就是由client_node决定，而data_node的数据都是从master_node同步过来的

分片

一个索引可以存储超出单个结点硬件限制的大量数据。比如，一个具有10亿文档的索引占据1TB的磁盘空间，而任一节点都没有这样大的磁盘空间；或者单个节点处理搜索请求，响应太慢。

为了解决这个问题，ES提供了将索引划分成多份的能力，这些份就叫做分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。

分片之所以重要，主要有两方面的原因：

1、允许你水平分割/扩展你的内容容量

允许你在分片（潜在地，位于多个节点上）之上进行分布式的、并行的操作，进而提高性能/吞吐量

至于一个分片怎样分布，它的文档怎样聚合回搜索请求，是完全由ES管理的，对于作为用户的你来说，这些都是透明的。

2、在一个网络/云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了。这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的，ES允许你创建分片的一份或多份拷贝，这些拷贝叫做复制分片，或者直接叫复制。

复制之所以重要，主要有两方面的原因：

（1）在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。

（2）扩展你的搜索量/吞吐量，因为搜索可以在所有的复制上并行运行

总之，每个索引可以被分成多个分片。一个索引也可以被复制0次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改变复制数量，但是不能改变分片的数量。

默认情况下，ES中的每个索引被分片5个主分片和1个复制，这意味着，如果你的集群中至少有两个节点，你的索引将会有5个主分片和另外5个复制分片（1个完全拷贝），这样的话每个索引总共就有10个分片。一个索引的多个分片可以存放在集群中的一台主机上，也可以存放在多台主机上，这取决于你的集群机器数量。主分片和复制分片的具体位置是由ES内在的策略所决定的。

3、插件HEAD

elasticsearch-head是一个界面化的集群操作和管理工具

● node：即一个 Elasticsearch 的运行实例，使用多播或单播方式发现 cluster 并加入。

● cluster：包含一个或多个拥有相同集群名称的 node，其中包含一个master node。

● index：类比关系型数据库里的DB，是一个逻辑命名空间。

● alias：可以给 index 添加零个或多个alias，通过 alias 使用index 和根据index name 访问index一样，但是，alias给我们提供了一种切换index的能力，比如重建了index，取名● customer_online_v2，这时，有了alias，我要访问新 index，只需要把 alias 添加到新 index 即可，并把alias从旧的 index 删除。不用修改代码。

● type：类比关系数据库里的Table。其中，一个index可以定义多个type，但一般使用习惯仅配一个type。

● mapping：类比关系型数据库中的 schema 概念，mapping 定义了 index 中的 type。mapping 可以显示的定义，也可以在 document 被索引时自动生成，如果有新的 field，Elasticsearch 会自动推测出 field 的type并加到mapping中。

● document：类比关系数据库里的一行记录(record)，document 是 Elasticsearch 里的一个 JSON 对象，包括零个或多个field。

● field：类比关系数据库里的field，每个field 都有自己的字段类型。

● shard：是一个Lucene 实例。Elasticsearch 基于 Lucene，shard 是一个 Lucene 实例，被 Elasticsearch 自动管理。之前提到，index 是一个逻辑命名空间，shard 是具体的物理概念，建索引、查询等都是具体的shard在工作。shard 包括primary shard 和 replica shard，写数据时，先写到primary shard，然后，同步到replica shard，查询时，primary 和 replica 充当相同的作用。replica shard 可以有多份，也可以没有，replica shard的存在有两个作用，一是容灾，如果primary shard 挂了，数据也不会丢失，集群仍然能正常工作；二是提高性能，因为replica 和 primary shard 都能处理查询。另外，如上图右侧红框所示，shard数和replica数都可以设置，但是，shard 数只能在建立index 时设置，后期不能更改，但是，replica 数可以随时更改。但是，由于 Elasticsearch 很友好的封装了这部分，在使用Elasticsearch 的过程中，我们一般仅需要关注 index 即可，不需关注shard。

shard、node、cluster 在物理上构成了 Elasticsearch 集群，field、type、index 在逻辑上构成一个index的基本概念，在使用 Elasticsearch 过程中，我们一般关注到逻辑概念就好，就像我们在使用MySQL 时，我们一般就关注DB Name、Table和schema即可，而不会关注DBA维护了几个MySQL实例、master 和 slave 等怎么部署的一样。

ES中的索引原理（1）传统的关系型数据库

二叉树查找效率是logN，同时插入新的节点不必移动全部节点，所以用树型结构存储索引，能同时兼顾插入和查询的性能。因此在这个基础上，再结合磁盘的读取特性(顺序读/随机读)，传统关系型数据库采用了B-Tree/B+Tree这样的数据结构做索引

（2）ES

采用倒排索引

那么，倒排索引是个什么样子呢？

首先，来搞清楚几个概念，为此，举个例子：

假设有个user索引，它有四个字段：分别是name，gender，age，address。画出来的话，大概是下面这个样子，跟关系型数据库一样

Term（单词）：一段文本经过分析器分析以后就会输出一串单词，这一个一个的就叫做Term

Term Dictionary（单词字典）：顾名思义，它里面维护的是Term，可以理解为Term的集合

Term Index（单词索引）：为了更快的找到某个单词，我们为单词建立索引

Posting List（倒排列表）：倒排列表记录了出现过某个单词的所有文档的文档列表及单词在该文档中出现的位置信息，每条记录称为一个倒排项(Posting)。根据倒排列表，即可获知哪些文档包含某个单词。（PS：实际的倒排列表中并不只是存了文档ID这么简单，还有一些其它的信息，比如：词频（Term出现的次数）、偏移量（offset）等，可以想象成是Python中的元组，或者Java中的对象）

（PS：如果类比现代汉语词典的话，那么Term就相当于词语，Term Dictionary相当于汉语词典本身，Term Index相当于词典的目录索引）

我们知道，每个文档都有一个ID，如果插入的时候没有指定的话，Elasticsearch会自动生成一个，因此ID字段就不多说了

上面的例子，Elasticsearch建立的索引大致如下：

name字段：

age字段：

gender字段：

address字段：

Elasticsearch分别为每个字段都建立了一个倒排索引。比如，在上面“张三”、“北京市”、22 这些都是Term，而[1，3]就是Posting List。Posting list就是一个数组，存储了所有符合某个Term的文档ID。

只要知道文档ID，就能快速找到文档。可是，要怎样通过我们给定的关键词快速找到这个Term呢？

当然是建索引了，为Terms建立索引，最好的就是B-Tree索引（MySQL就是B树索引最好的例子）。

我们查找Term的过程跟在MyISAM中记录ID的过程大致是一样的

MyISAM中，索引和数据是分开，通过索引可以找到记录的地址，进而可以找到这条记录

在倒排索引中，通过Term索引可以找到Term在Term Dictionary中的位置，进而找到Posting List，有了倒排列表就可以根据ID找到文档了

（PS：可以这样理解，类比MyISAM的话，Term Index相当于索引文件，Term Dictionary相当于数据文件）

（PS：其实，前面我们分了三步，我们可以把Term Index和Term Dictionary看成一步，就是找Term。因此，可以这样理解倒排索引：通过单词找到对应的倒排列表，根据倒排列表中的倒排项进而可以找到文档记录）

为了更进一步理解，用两张图来具现化这一过程：

（至于里面涉及的更加高深的数据压缩技巧，以及多个field联合查询利用跳表的数据结构快速做运算来查询，这些大家有兴趣可以自己去了解）

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。