课程资源新技术研讨elasticsearch

Elasticsearch分布式搜索引擎搜索通过一些关键字，查询出跟这些关键字相关的信息全文搜索是指计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。什么是Elasticsearch？Elasticsearch是一个开源的搜索引擎，建立在一个全文搜索引擎库

ApacheLucene™

基础之上。Lucene可以说是当下最先进、高性能、全功能的搜索引擎库—​无论是开源还是私有。Elasticsearch是使用Java编写的，它的内部使用Lucene做索引与搜索，它的目的是通过隐藏Lucene的复杂性,使全文检索变得简单，取而代之的提供一套简单一致的RESTfulAPI。它可以被下面这样准确的形容：一个分布式的实时文档存储，每个字段可以被索引与搜索一个分布式实时分析搜索引擎能胜任上百个服务节点的扩展，并支持PB级别的结构化或者非结构化数据数据结构Elasticsearch是面向文档的，它存储整个对象或文档。它使用JSON作为文档的序列化格式，JSON序列化为大多数编程语言所支持，并且已经成为NoSQL领域的标准格式。倒排索引Elasticsearch使用一种称为倒排索引的结构，它适用于快速的全文搜索。一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文档列表。例如，假设我们有两个文档，每个文档的content域包含如下内容：1.Thequickbrownfoxjumpedoverthelazydog2.Quickbrownfoxesleapoverlazydogsinsummer为了创建倒排索引，首先将每个文档的content域拆分成单独的词（我们称它为词条或tokens），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档。分析和分析器分析包含下面的过程：首先，将一块文本分成适合于倒排索引的独立的词条，之后，将这些词条统一化为标准格式以提高它们的“可搜索性”字符过滤器首先，字符串按顺序通过每个字符过滤器，在分词前整理字符串。一个字符过滤器可以用来去掉HTML，或者将&转化成and。分词器其次，字符串被

分词器

分为单个的词条。一个简单的分词器遇到空格和标点的时候，可能会将文本拆分成词条，默认标准分词器根据Unicode联盟定义的单词边界划分文本。Token过滤器最后，词条按顺序通过每个token过滤器。这个过程可能会改变词条（例如，小写化Quick），删除词条（例如，像a，and，the等无用词），或者增加词条（例如，像jump和leap这种同义词）。排序与相关性相关性查询语句会为每个文档生成一个_score字段来代表相关性。Elasticsearch的相似度算法被定义为检索词频率/反向文档频率，TF/IDF，包括以下内容：检索词频率检索词在该字段出现的频率？出现频率越高，相关性也越高。字段中出现过5次要比只出现过1次的相关性高。反向文档频率每个检索词在索引中出现的频率？频率越高，相关性越低。检索词出现在多数文档中会比出现在少数文档中的权重更低。字段长度准则字段的长度是多少？长度越长，相关性越低。检索词出现在一个短的title要比同样的词出现在一个长的content字段权重更大。排序按照字段的值排序通过时间来排序。多级排序根据时间和相关性结合排序，不同的排序条件顺序得到不同结果。多值字段排序一种情形是字段有多个值的排序，需要记住这些值并没有固有的顺序；一个多值的字段仅仅是多个值的包装。对于数字或日期，你可以将多值字段减为单值，这可以通过使用min、max、avg或是sum排序。有时，相关性评分对你来说并没有意义，还有其它的排序方式集群原理集群原理一个运行中的Elasticsearch实例称为一个节点，而集群是由一个或者多个拥有相同配置的节点组成，它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。当一个节点被选举成为主节点时，它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。任何节点都可以成为主节点。作为用户，我们可以将请求发送到

集群中的任何节点

，包括主节点。每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。集群状态State有三种状态标识集群运行状态。green：所有的主分片和副本分片都正常运行。

yellow：所有的主分片都正常运行，但不是所有的副本分片都正常运行。

red：有主分片没能正常运行。添加索引

Elasticsearch添加数据时需要用到索引——保存相关数据的地方。索引实际上是指向一个或者多个物理分片的逻辑命名空间。

Elasticsearch是利用分片将数据分发到集群内各处的。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。当你的集群规模扩大或者缩小时，Elasticsearch会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。一个分片可以是主分片或者副本分片。索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改。添加节点当第二个节点加入到集群后，3个副本分片将会分配到这个节点上——每个主分片对应一个副本分片。这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。当第三个节点加入到集群后，为了分散负载而对分片进行重新分配。拥有6个分片（3个主分片和3个副本分片）的索引可以最大扩容到6个节点，每个节点上存在一个分片，并且每个分片拥有所在节点的全部资源。如果我们想要扩容超过6个节点，可以修改副本分片数量。故障处理如果关闭节点或遇到意外情况挂掉节点，发生的第一件事情就是选举一个新的主节点：Node2。

新的主节点立即将分片在Node2和Node3上对应的副本分片提升为主分片。如果我们同样关闭了Node2，依然可以保持在不丢任何数据的情况下运行，因为Node3为每一个分片都保留着一份副本。内部分片原理使文本可被搜索如何使文本可被搜索，最好的支持一个字段多个值就是使用倒排索引，这个倒排索引相比特定词项出现过的文档列表，会包含更多其它信息。它会保存每一个词项出现过的文档总数，在对应的文档中一个具体词项出现的总次数，词项在文档中的顺序，每个文档的长度，所有文档的平均长度，等等。倒排索引被写入磁盘后是不可改变的:它永远不会修改。Elasticsearch基于Lucene，引入了按段搜索的概念。每一

段本身都是一个倒排索引，但索引在Lucene中除表示所有段的集合外，还增加了

提交点

的概念—一个列出了所有已知段的文件一个

Lucene索引

我们在Elasticsearch称作

分片

。一个Elasticsearch

索引是分片的集合。动态更新索引流程如下：新文档被收集到内存索引缓存。不时地,缓存被提交：一个新的段—​一个追加的倒排索引—​被写入磁盘。一个新的包含新段名字的提交点被写入磁盘。磁盘进行同步—所有在文件系统缓存中等待的写入都刷新到磁盘，以确保它们被写入物理文件。3.新的段被开启，让它包含的文档可见以被搜索。4.内存缓存被清空，等待接收新的文档。近实时搜索Lucene允许新段被写入和打开—​使其包含的文档在未进行一次完整提交时便对搜索可见。这种方式比进行一次提交代价要小得多，并且在不影响性能的前提下可以被频繁地执行。随着按段（per-segment）搜索的发展，一个新的文档从索引到可被搜索的延迟显著降低了。新文档在几分钟之内即可被检索，但这样还是不够快。磁盘在这里成为了瓶颈。提交（Commiting）一个新的段到磁盘需要一个fsync来确保段被物理性地写入磁盘，这样在断电的时候就不会丢失数据。但是fsync操作代价很大;如果每次索引一个文档都去执行一次的话会造成很大的性能问题。近实时搜索在Elasticsearch中，写入和打开一个新段的轻量的过程叫做

refresh

。默认情况下每个分片会每秒自动刷新一次。文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。持久化变更在动态更新索引中，一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点，为了确保两次提交之间发生变化的文档不会丢失Elasticsearch增加了一个

translog

，或者叫事务日志，在每一次对Elasticsearch进行操作时均进行了日志记录。工作流程：1.一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了translog。持久化变更在动态更新索引中，提到一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点，为了确保两次提交之间发生变化的文档不会丢失Elasticsearch增加了一个

translog

，或者叫事务日志，在每一次对Elasticsearch进行操作时均进行了日志记录。工作流程：2.刷新（refresh），分片每秒被刷新（refresh）一次：这些在内存缓冲区的文档被写入到一个新的段中，且没有进行fsync操作。这个段被打开，使其可被搜索。内存缓冲区被清空。刷新（refresh）完成后,缓存被清空但是事务日志不会持久化变更在动态更新索引中，提到一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点，为了确保两次提交之间发生变化的文档不会丢失Elasticsearch增加了一个

translog

，或者叫事务日志，在每一次对Elasticsearch进行操作时均进行了日志记录。工作流程：3.继续这个过程，更多的文档被添加到内存缓冲区和追加到事务日志持久化变更工作流程：4.每隔一段时间默认是三十分钟或者translog超过阈值，​索引被刷新（flush）；一个新的translog被创建，并且一个全量提交被执行。所有在内存缓冲区的文档都被写入一个新的段。缓冲区被清空。一个提交点被写入硬盘。文件系统缓存通过fsync被刷新（flush）。老的translog被删除。执行一个提交并且截断translog的行为在Elasticsearch被称作一次

flush

。持久化变更translog提供所有还没有被刷到磁盘的操作的一个持久化纪录。当Elasticsearch启动的时候，它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放translog中所有在最后一次提交后发生的变更操作。translog也被用来提供实时CRUD。当你试着通过ID查询、更新、删除一个文档，它会在尝试从相应的段中检索之前，首先检查translog任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。段合并由于自动刷新流程每秒会创建一个新的段，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。段合并启动段合并不需要你做任何事。进行索引和搜索时会自动进行。具体流程如下：当索引的时候，刷新（refresh）操作会创建新的段并将段打开以供搜索使用。合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中。这并不会中断索引和搜索。段合并一旦合并结束，老的段被删除新的段被刷新（flush）到了磁盘。新的段被打开用来搜索。老的段被删除。合并大的段需要消耗大量的I/O和CPU资源，如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好地执行。执行分布式检索执行分布式检索分布式检索需要一种相比传统数据库更加复杂的执行模型因为我们不知道查询会命中哪些文档:这些文档有可能在集群的任何分片上。一个搜索请求必须询问索引（indexorindices）的所有分片的某个副本来确定它们是否含有任何匹配的文档。找到所有的匹配文档后，多分片中的结果必须组合成单个排序列表。为此，搜索被执行成一个两阶段过程，我们称之为querythenfetch。查询阶段在初始

查询阶段

时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。每个分片在本地执行搜索并构建一个匹配文档的优先队列。优先队列的大小取决于分页参数from和size。

from定义了目标数据的偏移值，size定义当前返回的事件数目。默认from为0，size为10，即所有的查询默认仅仅返回前10条数据。查询阶段包含以下三个步骤:客户端发送一个search请求到Node3，Node3就变成了协调节点，它会创建一个大小为from+size的空优先队列。Node3将查询请求转发到索引的每个主分片或副本分片中。每个分片在本地执行查询并添加结果到大小为from+size的本地有序优先队列中。每个分片返回各自优先队列中所有文档的ID和排序值给协调节点，也就是Node3，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。取回阶段查询阶段标识哪些文档满足搜索请求，但是我们仍然需要取回这些文档。具体步骤：协调节点首先决定哪些文档确实需要被取回。例如，如果我们的查询指定了{"from":90,"size":10}，最初的90个结果会被丢弃，只有从第91个开始的10个结果需要被取回。协调节点给持有相关文档的每个分片创建一个multi-getrequest，并发送请求给同样处理查询阶段的分片副本。分片加载文档体--_source字段—​如果有需要，用元数据和高亮搜索（结果中标识符合的字段）丰富结果文档。一旦所有的文档都被取回了，协调节点返回结果给客户端。深度分页先查后取的过程支持用from和size参数分页，但是这是有限制的。需要传递信息给协调节点的每个分片必须先创建一个from+siz