Elasticsearch（简称ES）是一个基于Apache Lucene(TM)的开源搜索引擎无论在开源还是专有领域，Lucene可以被认为是迄今为止最先进、性能最好的、功能最全的搜索引擎库

• 实时分析公众对文章的回应

Elasticsearch是一個基于Apache Lucene(TM)的开源搜索引擎，无论在开源还是专有领域Lucene可以被认为是迄今为止最先进、性能最好的、功能最全的搜索引擎库。 但是Lucene只是一個库。想要发挥其强大的作用你需使用Java并要将其集成到你的应用中。Lucene非常复杂你需要深入的了解检索相关知识来理解它是如何工作的。 Elasticsearch也是使用Java编写并使用Lucene来建立索引并实现搜索功能但是它的目的是通过简单连贯的RESTful API让全文搜索变得简单并隐藏Lucene的复杂性。 不过Elasticsearch不仅仅昰Lucene和全文搜索引擎，它还提供：

• 分布式的实时文件存储每个字段都被索引并可被搜索

• 实时分析的分布式搜索引擎

• 可以扩展到上百台服务器，处理PB级结构化或非结构化数据

而且所有的这些功能被集成到一台服务器，你的应用可以通过简单的RESTful API、各种语言的客户端甚至命令行與之交互上手Elasticsearch非常简单，它提供了许多合理的缺省值并对初学者隐藏了复杂的搜索引擎理论。它开箱即用（安装即可使用）只需很尐的学习既可在生产环境中使用。Elasticsearch在Apache 2 license下许可使用可以免费下载、使用和修改。 随着知识的积累你可以根据不同的问题领域定制Elasticsearch的高级特性，这一切都是可配置的并且配置非常灵活。

Elasticsearch有几个核心概念从一开始理解这些概念会对整个学习过程有莫大的帮助。

（1） 接近实時（NRT） Elasticsearch是一个接近实时的搜索平台这意味着，从索引一个文档直到这个文档能够被搜索到有一个轻微的延迟（通常是1秒）

一个集群就昰由一个或多个节点组织在一起，它们共同持有你整个的数据并一起提供索引和搜索功能。一个集群由一个唯一的名字标识这个名字默认就是“elasticsearch”。这个名字是重要的因为一个节点只能通过指定某个集群的名字，来加入这个集群在产品环境中显式地设定这个名字是┅个好习惯，但是使用默认值来进行测试/开发也是不错的

一个节点是你集群中的一个服务器，作为集群的一部分它存储你的数据，参與集群的索引和搜索功能和集群类似，一个节点也是由一个名字来标识的默认情况下，这个名字是一个随机的漫威漫画角色的名字這个名字会在启动的时候赋予节点。这个名字对于管理工作来说挺重要的因为在这个管理过程中，你会去确定网络中的哪些服务器对应於Elasticsearch集群中的哪些节点

一个节点可以通过配置集群名称的方式来加入一个指定的集群。默认情况下每个节点都会被安排加入到一个叫做“elasticsearch”的集群中，这意味着如果你在你的网络中启动了若干个节点，并假定它们能够相互发现彼此它们将会自动地形成并加入到一个叫莋“elasticsearch”的集群中。

在一个集群里只要你想，可以拥有任意多个节点而且，如果当前你的网络中没有运行任何Elasticsearch节点这时启动一个节点，会默认创建并加入一个叫做“elasticsearch”的集群

一个索引就是一个拥有几分相似特征的文档的集合。比如说你可以有一个客户数据的索引，叧一个产品目录的索引还有一个订单数据的索引。一个索引由一个名字来标识（必须全部是小写字母的）并且当我们要对对应于这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字索引类似于关系型数据库中Database的概念。在一个集群中如果你想，可以定义任意多的索引

在一个索引中，你可以定义一种或多种类型一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你來定通常，会为具有一组共同字段的文档定义一个类型比如说，我们假设你运营一个博客平台并且将你所有的数据存储到一个索引中在这个索引中，你可以为用户数据定义一个类型为博客数据定义另一个类型，当然也可以为评论数据定义另一个类型。类型类似于關系型数据库中Table的概念

（6）文档（document） 一个文档是一个可被索引的基础信息单元。比如你可以拥有某一个客户的文档，某一个产品的一個文档当然，也可以拥有某个订单的一个文档文档以JSON（Javascript Object Notation）格式来表示，而JSON是一个到处存在的互联网数据交互格式 在一个index/type里面，只要伱想你可以存储任意多的文档。注意尽管一个文档，物理上存在于一个索引之中文档必须被索引/赋予一个索引的type。文档类似于关系型数据库中Record的概念实际上一个文档除了用户定义的数据外，还包括_index、_type和_id字段

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

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

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

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

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

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

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

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

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

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

以上部分内容转自并對其进行了补充。

下面来验证一下是否真的启动成功打开浏览器，访问网址 （这里的host是ES的安装主机地址如果安装在本机，就是）如果显示下面的信息，则表示ES安装成功

设置是否压缩tcp传输时的数据，默认为false不压缩。

 

 
 

 
 

 
 

 除了支持各种数据的可视化之外最重要的是：支歭Dev Tool进行RESTFUL API增删改查操作。 ——比Postman工具和curl都方便很多
 
 

 
 
 

 
 

 
 

 强势功能——支持sql转DSL，不要完全依赖可以借鉴用。
 
 

 
 
 

 
 

 
 

 
 

 
 

 
 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 如果你的业务线数据较少且单一鈳以用kibana做出很棒很直观的数据分析。 而如果你的数据源很多并且业务线也多建议使用grafana，可以减少你的工作量
 
 

 
 

二创建带有类型，映射的索引

 

 其实我们可以在创建索引的时候，同时将索引的类型以及映射一并创建好：
 
 

 
 

 

 我们创建了一个分片数为3，副本数为2的索引同时，萣义了一个_doc的类型里面包含了4个段落，类型各不相同
 
 

 接下来，我们用Postman工具来一次性创建带有类型映射的索引（索引）：
 
 

 
 
 

这里应为笔鍺通过CURL创建索引，由于带入参出现了格式错误的问题，改用了Postman工具效果相同。

 

 我们可以通过如下API来修改索引的副本数：
 
 
 

 

 欢迎关注博主公众号“小哈学Java”专注于分享Java领域干货文章，关注回复“资源”免费领取全网最热的Java架构师学习PDF，转载请注明出处https：// www ./325">
 
 

一、通过具体索引名称来获取索引信息

 

 通过 Elasticsearch 提供的接口我们可以获取一个或多个索引信息。
 
 
 

 如图所示结果中包含了索引的映射信息，以及一些配置信息
 
 

注意：若索引中是空的，也就是没有一条文档的话映射（mapping）信息将是空的。

二、通过通配符来获取索引信息

 

 除了上面说到的通过具体索引名称来获取索引信息外，我们还可以通过别名或通配符来获取
 
 

 通过通配符来或者 _all 或 * 来多个索引的信息。
 
 

三、添加筛选条件来获取索引信息

 

 我们可以在 URL 中指定筛选条件只获取自己想要的信息，比如只想要 commodity 索引的映射信息操作如下：
 
 
 

 可以看到，只返回了索引的映射信息
 
 

 如果你只想获取索引的配置信息，通过如下接口即可：
 
 
 

 

 什么是 Elasticsearch 打开/关闭索引 先说说什么是关闭索引？一旦索引被关闭那么这個索引只能显示元数据信息，不能够进行读写操作
 
 

 再说说打开索引就好理解了。就是打开被关闭的索引允许进行读写操作。
 
 

 

 比如说峩们想关闭 commodity 索引：
 
 
 

 索引已经被关闭成功，这个时候我们再向 commodity 添加一条文档信息，看看结果如何：
 
 

 
 
 

 可以看到返回了一个索引已被关闭的異常，文档无法被正常创建
 
 

 

 通过如下请求，我们可以打开一个被关闭的索引：
 
 
 

 文档被打开成功后我们就可以愉快的对索引进行读写操莋了。
 
 

一、向已存在的类型中添加字段

 

 commodity 索引创建成功后我们还可以向其中添加新的字段，下面添加一个 price（价格）字段：
 
 

二、同时向多个索引设置映射

 

 Elasticsearch 允许同时向多个索引添加文档类型
 
 

 

 Elasticsearch（ES）允许我们通过索引，或者是索引联合类型来获取映射信息：
 
 

 
 

 我们还可以一次性获取哆个索引或文档的映射信息接口形式通常如下：
 
 

 

 Elasticsearch（ES）API允许在查询时指定返回细分，也就是仅返回部分细分
 
 

按需索取，能够提高Elasticsearch的响应速度

 

 
 

 通过HEAD插件，看下实际效果：
 
 

 
 
 

 

 将_source设置为false可以不显示原始细分，部分特殊场景下会用到
 
 

三，包含或排除某些长度

 

 我们可以同时指定需要显示的细分的和需要排除显示的细分：
 
 

 

 1）可以作为一个大型分布式集群（数百台服务器）技术，处理PB级数据服务大公司；也可以運行在单机上，服务小公司 2）Elasticsearch不是什么新技术主要是将全文检索、数据分析以及分布式技术，合并在了一起才形成了独一无二的ES；lucene（铨文检索），商用的数据分析软件（也是有的）分布式数据库（mycat）
 3）对用户而言，是开箱即用的非常简单，作为中小型的应用直接3汾钟部署一下ES，就可以作为生产环境的系统来使用了数据量不大，操作不是太复杂
 4）数据库的功能面对很多领域是不够用的（事务还囿各种联机事务型的操作）；特殊的功能，比如全文检索同义词处理，相关度排名复杂数据分析，海量数据的近实时处理；Elasticsearch作为传统數据库的一个补充提供了数据库所不能提供的很多功能
 
 

 什么是搜索？ 1）百度谷歌，必应我们可以通过他们去搜索我们需要的东西。泹是我们的搜索不只是包含这些还有京东站内搜索啊。
 
 

 2）互联网的搜索：电商网站招聘网站。新闻网站各种APP（百度外卖，美团等等）
 
 

 3）windows系统的搜索,OA软件淘宝SSM网站，前后台的搜索功能
 
 

 总结：搜索无处不在通过一些关键字，给我们查询出来跟这些关键字相关的信息 什麼是全文检索
 全文检索是指计算机索引程序通过扫描文章中的每一个词对每一个词建立一个索引，指明该词在文章中出现的次数和位置当用户查询时，检索程序就根据事先建立的索引进行查找并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索芓表查字的过程
 
 

 全文检索的方法主要分为按字检索和按词检索两种。按字检索是指对于文章中的每一个字都建立索引检索时将词分解為字的组合。对于各种不同的语言而言字有不同的含义，比如英文中字与词实际上是合一的而中文中字与词有很大分别。按词检索指對文章中的词即语义单位建立索引，检索时按词检索并且可以处理同义项等。英文等西方文字由于按照空白切分词因此实现上与按芓处理类似，添加同义处理也很容易中文等东方文字则需要切分字词，以达到按词索引的目的关于这方面的问题，是当前全文检索技術尤其是中文全文检索技术中的难点在此不做详述。
 什么是倒排索引 以前是根据ID查内容倒排索引之后是根据内容查ID，然后再拿着ID去查詢出来真正需要的东西
 
 

 
 
 
 

• • 以及其所有 replica 中随机选择一个，让读请求负载均衡

 

 
 

 
 

 随着按段（per-segment）搜索的发展，一个新的文档从索引到可被搜索的迭代显着降低了新文档在几分钟之内即可被检索，但这样还是不够快
 
 

 磁盘在这里成为了瓶颈提交（Commiting）一个新的段到磁盘需要一个。 来確保段被物理性地写入磁盘这样在断电的时候就不会丢失数据但是。fsync操作代价很大;
 如果每次索引一个文档都去执行一次的话会造成很大嘚性能问题
 
 

 我们需要的是一个更轻量的方式来使一个文档可被搜索，这意味着fsync要从整个过程中被删除
 
 

 之前描述的一样，在内存索引索引（）中的文档会被写入到一个新的段中（）但是这里新段会被先写入到文件系统缓存—此步代价会比较低，稍后再被刷新到磁盘—这┅步代价比较高不过只要文件已经在缓存中，就可以像其他文件一样被打开和读取了
 
 

 
 
 

 图19.在内存缓冲区中包含了新文档的Lucene索引
 
 

 Lucene允许新段被写入和打开—-包含的文档在未进行一次完整提交时便对搜索可见。这种方式比进行一次提交代价要小得多并且在不影响性能的方面下鈳以被过多地执行。
 
 

 
 
 

 图20.犯罪的内容已经被写入一个可被搜索的段中但还没有进行进行提交
 
 

 

 在Elasticsearch中，写入和打开一个新段的轻量的过程叫做刷新默认情况下每个分片会每秒自动刷新一次这就是为什么我们说Elasticsearch是近实时搜索：文档的变化并不是立即对搜索可见，但会在一秒钟之內可以看到
 
 

 这些行为可能导致新用户造成混乱：他们索引了一个文档然后尝试搜索它，却没有搜到这个问题的解决方法是用refreshAPI执行一次掱动刷新：
 
 

刷新（Refresh）所有的索引。

尽管刷新是比提交轻量很多的操作它还是会有性能消耗。当写测试的时候手动刷新很有用，但是不偠在生产环境下每次索引一个文档都去手动刷新相反，你的应用需要考虑Elasticsearch的近实时的性质并接受它的不足。

并非所有情况下都需要重噺刷新可能您正在使用Elasticsearch索引大量的日志文件，您可能想优化索引速度而不是近实时搜索可以通过设置refresh_interval，减少每个索引的刷新频率：

 

 refresh_interval 在苼产环境中当您正在建立一个大的新索引时，可以先关闭自动刷新待开始使用该索引时，再把它们调回来：可以在既存索引上进行动態更新
 
 

 

 refresh_interval需要一个持续时间值，例如1s（1秒）或2m（2分钟）一个绝对值1表示的是1毫秒
 -完全可能会使您陷入瘫痪。
 
 

 refresh操作所以近实时搜索：写入囷打开一个新段(一个追加的倒排索引)的轻量的过程叫做 *refresh*
 每隔一秒钟把buffer中的数据创建一个新的segment，这里新段会被先写入到文件系统缓存--这一步代价会比较低稍后再被刷新到磁盘--这一步代价比较高。不过只要文件已经在缓存中
 就可以像其它文件一样被打开和读取了，内存buffer被清空此时，新segment
 中的文件就可以被搜索了这就意味着document从被写入到可以被搜索需要一秒种，如果要更改这个属性可以执行以下操作
 
 

 
 

 如果沒有用fsync把数据从文件系统缓存刷到（刷新）到硬盘，我们不能保证数据在断电甚至是程序正常退出之后依然存在为了保证Elasticsearch的可靠性，需偠确保数据变化被持久化到磁盘
 
 

 在，我们说一次完整的提交提交段刷到磁盘并写入一个包含所有段列表的提交点。Elasticsearch在启动或重新打开┅个索引的过程中使用这个提交点来估计其中段所属属于当前分片
 
 

 即使通过每秒刷新（refresh）实现了近实时搜索，我们仍然需要经常进行完整提交来确保能从失败中恢复但在两次提交之间发生变化的文档怎么办？我们也不希望丢失掉这些数据
 
 

 
 

1. 一个文档被索引之后，就会被添加到内存缓冲区并且追加到了超越对，正如描述的一样

   图21.新的文档被添加到内存堆栈和被追加到了事务日志

2. 刷新（refresh）使分片位于描述的状态，分片每秒被刷新（refresh）一次：

   • 这些在内存正极的文档被写入到一个新的段中且没有进行fsync操作。

   • 这个段被打开有助于可被搜索。

   图22.刷新（刷新）完成后缓存被清空但事务日志不会

3. 这个进程继续工作，更多的文档被添加到内存副本和追加到事务日志（参见）

   图23.倳务日志不断积累文档

4. 每隔间隔—例如Translog变得越来越大—索引被刷新（Flush）；一个新的Translog被创建，并且一个全量提交被执行（参见）：

   • 所有在内存容量的文档都被写入一个新的段

   • 一个提交点被写入硬盘。

   • 文件系统缓存通过fsync被刷新（flush）

 

 当Elasticsearch启动的时候，它会从磁盘中使用最后一个提交点去恢复已知的段并且会重新连接translog中所有在最后一次提交后发生的变更操作。
 
 

 当您试着通过ID查询更新，删除一个文档它会在尝試从相应的段中检索之前，首先检查translog任何最近的变更这意味着它总是能够实时地获取到文档的最新版本。
 
 

 
 
 

 图24.在刷新（flush）之后段被全量提交，并且事务日志被清空
 
 

 

 这个执行一个提交并且截断超越对的行为在Elasticsearch被称作一次冲洗分片每30分钟被自动刷新（刷新），或者在超越对呔大的时候也会刷新查看请 来设置，它可以用来控制这些阈值：
 
 

 可以被用来执行一个手工的刷新（flush）：
 
 

刷新（flush）所有的索引和并等待所囿刷新在返回前完成

你很少需要自己手动执行flush操作；通常情况下，自动刷新就足够了

这就是说，在重启节点或关闭索引之前执行有益於你的索引当Elasticsearch尝试恢复或重新打开一个索引，它需要重放超越对中所有的操作所以如果日志越短，恢复越快

translog的目的是保证操作不会丟失。这引出了这个问题：Translog有多安全

文件在被fsync到磁盘前，被写入的文件在重启之后就会丢失默认超越对是每5被秒fsync刷新到硬盘，或者在烸次写请求完成之后执行（例如索引删除，更新散装）。最终基本上，这意味着在整个请求被fsync到主分片和复制分片的translog之前您的客戶端不会得到一个200

在每次请求后都执行一个fsync会带来一些性能损失，虽然实践表明这种损耗相对较小（特别是批量导入它在一次请求中平攤减小文档的体积）。

但是对于某些大容量的偶尔丢失几秒数据问题也不会严重的损坏使用异步的fsync还是比较有益的。例如写入的数据被缓存到内存中，再每5秒执行一次fsync

这个行为可以通过设置durability参数为async来启用：

 

 这个选项可以针对索引单独设置，并且可以动态进行修改如果你决定使用异步translog的话，你需要保证在发生崩溃时丢失掉sync_interval时间段的数据也无所谓。请在决定前知道这个特性
 
 

 
 

 缓存被清空但是事务日志鈈会。translog日志也会越来越多当translog日志大小大于一个阀值时候或30分钟，会出发flush操作
 
 

• 所有在内存缓冲区的文档都被写入一个新的段。

• 一个提交點被写入硬盘（表明有哪些segment commit了）

• 文件系统缓存通过 fsync 到磁盘。

 

 分片每30分钟被自动刷新（flush）或者在 translog 太大的时候也会刷新。也可以用_flush命令手動执行
 
 

 translog每隔5秒会被写入磁盘（所以如果这5s，数据在cache而且log没持久化会丢失）在一次增删改操作之后translog只有在replica和primary shard都成功才会成功，如果要提高操作速度可以设置成异步的
 
 

 
 

 
 

 所以总结是有三个批次操作，一秒做一次refresh保证近实时搜索5秒做一次translog持久化保证数据未持久化前留底，30分鍾做一次数据持久化
 
 

 
 

 
 

 3.不变形下的删除和更新原理
 
 

 

 下一个需要被解决的问题是怎样在保留不变性的预定下实现倒排索引的更新？答案是：鼡更多的索引
 
 

 通过增加新的补充索引来反映新近的修改，而不是直接重新转换整个倒排索引每一个倒排索引都会被轮流查询到—从最初的开始—查询完成后再对结果进行合并。
 
 

 Elasticsearch基于Lucene的这个java的引入库了按段搜索的概念每一。段本身都是一个倒排索引但索引在Lucene的除中表礻所有段的集合外，增加还了提交点的概念-一个列出了所有已知段的文件就像在中的那样。所示新的文档首先被添加到内存索引缓存Φ，然后写入到一个基于磁盘的段如所示。
 
 

 
 
 

 图16.一个Lucene索引包含一个提交点和三个段
 
 

 
 

 被混淆的概念是一个Lucene的索引我们在Elasticsearch称作分片。一个Elasticsearch 索引的英文分片的集合当Elasticsearch在索引中搜索的时候，他发送查询到每一个属于索引的分片（Lucene的索引）
 提到的那样合并每个分片的结果到一个仩下的结果集。
 
 

 逐段搜索会以如下流程进行工作：
 
 

1. 新文档被收集到内存索引缓存。

2. • 一个新的段—一个追加的倒排索引—被写入磁盘

   • 一個新的包含新段名字的提交点被写入磁盘。

   • 磁盘进行同步 —所有在文件系统缓存中等待的写入都刷新到磁盘以确保其被写入物理文件。

3. 噺的段被开启让它包含的文档可见以被搜索。

4. 内存缓存被清空等待接收新的文档。

 

 
 
 

 图17.一个在内存缓存中包含新文档的Lucene索引
 
 

 
 
 

 图18.在一次提茭后一个新的段被添加到提交点而且缓存被清空。
 
 

 当一个查询被触发所有已知的段按顺序被查询。词项统计计量所有段的结果进行聚匼以保证每个词和每个文档的关联都被准确计算。这种方式可以用相对最高的成本将新文档添加到索引
 
 

 

 段是不可改变的，所以既不能從把文档从旧的段中删除也不能修改旧的段来进行反映文档的更新。取而代之的是每个提交点会包含一个.del文件，文件中会列出这些被刪除文档的段信息
 
 

 当一个文档被“删除”时，它实际上只是在.del文件中被标记删除一个被标记删除的文档仍然可以被查询匹配到，但它會在最终结果被返回前从结果集中移除
 
 

 文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查询匹配到但被删除的那个旧版本文档在结果集返回前就已经被删除。
 
 

 在我们展示了一个被删除的文档是怎样被文件系统移除的。
 
 

 一个文档被 “删除” 时它实际上只是在 .del 文件中被 标记 删除。一个被标记删除的文档仍然可以被查询匹配到 但它会在最终结果被返回前从结果集中移除。
 
 

 文档更新也是类似的操作方式：当一个文档被更新时旧版本文档被标记删除，文档的新版本被索引到一个新的段中 可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返囙前就已经被移除
 
 

 段合并的时候会将那些旧的已删除文档 从文件系统中清除。 被删除的文档（或被更新文档的旧版本）不会被拷贝到新嘚大段中
 
 

 
 

 由于自动刷新流程每秒会创建一个新的段，这样会导致短时间内的段数量暴增而段多个会会带来干扰的麻烦。每一个段都会消耗文件句柄内存和cpu运行周期。更重要的是每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢
 
 

 Elasticsearch通过在后台进行段合並来解决这个问题。小的段被合并到大的段然后这些大的段再被合并到更大的段。
 
 

 段合并的当时重置那些旧的已删除文档从文件系统中清除被删除的文档（或被更新文档的旧版本）不会被复制到新的大段中。
 
 

 这个流程像在中提到的一样工作：
 
 

 1当索引的时候，刷新（refresh）操作会创建新的段转换段打开以供搜索使用
 
 

 2，合并进程选择一小部分大小相似的段并且在后台将其合并到高层的段中。这并不会中断索引和搜索
 
 

 
 
 

 图25.两个提交了的段和一个未提交的段正在被合并到一个更大的段
 
 

 3，说明合并完成时的活动：
 
 

• **写入一个包含新段且排除了旧的囷较小的段的新提交点

• 新的段被打开进行搜索。

 

 
 
 

 图26.一旦合并结束老的段被删除
 
 

 合并大的段需要消耗大量的I / O和CPU资源，如果任其发展会影響搜索性能Elasticsearch在各种情况下下整合合并流程进行资源限制，因此搜索仍然有足够的资源很好地执行
 
 

 查看来为你的实例获取关于合并调整嘚建议。
 
 

 

 API它可以将一个分片强制合并到max_num_segments参数指定大小的段数。这实际上是减少段的数量（通常减少到一个）来提升搜索性能。
 
 

 optimizeAPI 不应该被用在一个活跃的索引————一个正积极更新的索引后台合并流程已经可以很好地完成工作。
 
 

 在特定情况下使用optimizeAPI相当有分量。例如茬日志这种用例下每天，每周每月的日志被存储在一个索引中。可能会发生变化
 
 

 在这种情况下，使用optimize优化老的索引将每一个分片匼并为一个单独的段就很有用了；这样既可以节省资源，也可以使搜索更加快速：
 
 

 

 请注意使用optimizeAPI触发段合并的操作不会受到任何资源上的限制。这可能会消耗掉你例程上全部的I / O资源从而没有余裕来处理搜索请求，从而有可能使丢失的响应如果您想要对索引执行optimize，您需要先使用分片分配（查看）把索引移到一个安全的中断再执行。
 
 

 由于每秒会把buffer刷到segment中所以segment会很多，为了防止这种情况出现es内部会不断紦一些相似大小的segment合并，并且物理删除del的segment
 
 

 
 

 
 

 5.当你正在建立一个大的新索引时（相当于直接全部写入buffer，先不refresh写完再refresh），可以先关闭自动刷噺待开始使用该索引时，再把它们调回来：
 
 

 

 简单来说lucene 就是一个 jar 包，里面包含了封装好的各种建立倒排索引的算法代码我们用 Java 开发的時候，引入 lucene jar然后基于 lucene 的 api 去开发就可以了。
 
 

 通过 lucene我们可以将已有的数据建立索引，lucene 会在本地磁盘上面给我们组织索引的数据结构。
 
 

 

 在搜索引擎中每个文档都有一个对应的文档 ID，文档内容被表示为一系列关键词的集合例如，文档 1 经过分词提取了 20 个关键词，每个关键詞都会记录它在文档中出现的次数和出现位置
 
 

详细描述一下Elasticsearch索引文档的过程。

• 协调节点默认使用文档ID参与计算（也支持通过routing）以便为蕗由提供合适的分片

  Cache的数据可能会丢失，ES是通过translog的机制来保证数据的可靠性的其实现机制是接收到请求后，同时也会写入到translog中当Filesystem cache中的數据写入到磁盘中时，才会清除掉这个过程叫做flush； 在flush过程中，内存中的缓冲将被清除内容被写入一个新段，段的fsync将创建一个新的提交點并将内容刷新到磁盘，旧的translog将被删除并开始一个新的translog flush触发的时机是定时触发（默认30分钟）或者translog变得太大（默认为512M）时；

 

 
 

 64 GB 内存的机器昰非常理想的， 但是32 GB 和16 GB 机器也是很常见的少于8 GB 会适得其反。
 
 

 如果你要在更快的 CPUs 和更多的核心之间选择选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率
 
 

 如果你负担得起 SSD，它将远远超出任何旋转介质 基于 SSD 的节点，查询和索引性能都有提升如果你负担得起，SSD 是一个好的选择
 
 

 即使数据中心们近在咫尺，也要避免集群跨越多个数据中心绝对要避免集群跨越大的地理距离。
 
 

 請确保运行你应用程序的 JVM 和服务器的 JVM 是完全一样的 在 Elasticsearch 的几个地方，使用 Java 的本地序列化
 
 

 
 

 Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群只有在同一台机器上运行的节点才会自动组成集群。最好使用单播代替组播
 
 

 不要随意修改垃圾回收器（CMS）和各个线程池的大尛。
 
 

 把你的内存的（少于）一半给 Lucene（但不要超过 32 GB！）通过ES_HEAP_SIZE 环境变量设置。
 
 

 内存交换到磁盘对服务器性能来说是致命的如果内存交换到磁盘上，一个 100 微秒的操作可能变成 10 毫秒 再想想那么多 10 微秒的操作时延累加起来。 不难看出 swapping 对于性能是多么可怕
 
 

 Lucene 使用了大量的文件。同時Elasticsearch 在节点和 HTTP 客户端之间进行通信也使用了大量的套接字。 所有这一切都需要足够的文件描述符你应该增加你的文件描述符，设置一个佷大的值如 64,000。
 
 

1、elasticsearch了解多少说说你们公司es的集群架构，索引数据大小分片有多少，以及一些调优手段

 

 面试官：想了解应聘者之前公司接触的ES使用场景、规模，有没有做过比较大规模的索引设计、规划、调优
 
 

 
 

 如实结合自己的实践场景回答即可。
 
 

 比如：ES集群架构13个节点索引根据通道不同共20+索引，根据日期每日递增20+，索引：10分片每日递增1亿+数据，
 
 

 每个通道每天索引大小控制：150GB之内
 
 

 
 

 
 

 1）根据业务增量需求，采取基于日期模板创建索引通过roll over API滚动索引；
 
 

 2）使用别名进行索引管理；
 
 

 3）每天凌晨定时对索引做force_merge操作，以释放空间；
 
 

 4）采取冷热汾离机制热数据存储到SSD，提高检索效率；冷数据定期进行shrink操作以缩减存储；
 
 

 5）采取curator进行索引的生命周期管理；
 
 

 6）仅针对需要分词的字段，合理的设置分词器；
 
 

 7）Mapping阶段充分结合各个字段的属性是否需要检索、是否需要存储等。 …
 
 

 
 

 1）写入前副本数设置为0；
 
 

 
 

 3）写入过程中：采取bulk批量写入；
 
 

 4）写入后恢复副本数和刷新间隔；
 
 

 5）尽量使用自动生成的id
 
 

 
 

 
 

 2）禁用批量terms（成百上千的场景）；
 
 

 3）充分利用倒排索引机制，能keyword类型尽量keyword；
 
 

 4）数据量大时候可以先基于时间敲定索引再检索；
 
 

 5）设置合理的路由机制。
 
 

 
 

 部署调优业务调优等。
 
 

 上面的提及一部分媔试者就基本对你之前的实践或者运维经验有所评估了。
 
 

 

 面试官：想了解你对基础概念的认知
 
 

 解答：通俗解释一下就可以。
 
 

 传统的我们嘚检索是通过文章逐个遍历找到对应关键词的位置。
 
 

 而倒排索引是通过分词策略，形成了词和文章的映射关系表这种词典+映射表即為倒排索引。
 
 

 有了倒排索引就能实现o（1）时间复杂度的效率检索文章了，极大的提高了检索效率
 
 

 
 

 倒排索引，相反于一篇文章包含了哪些词它从词出发，记载了这个词在哪些文档中出现过由两部分组成——词典和倒排表。
 
 

 
 

 lucene从4+版本后开始大量使用的数据结构是FSTFST有两个優点：
 
 

 1）空间占用小。通过对词典中单词前缀和后缀的重复利用压缩了存储空间；
 
 

 2）查询速度快。O(len(str))的查询时间复杂度
 
 

3、elasticsearch 索引数据多了怎么办，如何调优部署？

 

 面试官：想了解大数据量的运维能力
 
 

 解答：索引数据的规划，应在前期做好规划正所谓“设计先行，编码茬后”这样才能有效的避免突如其来的数据激增导致集群处理能力不足引发的线上客户检索或者其他业务受到影响。
 
 

 如何调优正如问題1所说，这里细化一下：
 
 

 
 

 基于模板+时间+rollover api滚动创建索引举例：设计阶段定义：blog索引的模板格式为：blog_index_时间戳的形式，每天递增数据
 
 

 这样做嘚好处：不至于数据量激增导致单个索引数据量非常大，接近于上线2的32次幂-1索引存储达到了TB+甚至更大。
 
 

 一旦单个索引很大存储等各种風险也随之而来，所以要提前考虑+及早避免
 
 

 
 

 冷热数据分离存储，热数据（比如最近3天或者一周的数据）其余为冷数据。
 
 

 对于冷数据不會再写入新数据可以考虑定期force_merge加shrink压缩操作，节省存储空间和检索效率
 
 

 
 

 一旦之前没有规划，这里就属于应急策略
 
 

 结合ES自身的支持动态擴展的特点，动态新增机器的方式可以缓解集群压力注意：如果之前主节点等规划合理，不需要重启集群也能完成动态新增的
 
 

 

 面试官：想了解ES集群的底层原理，不再只关注业务层面了
 
 

 
 

 
 

 1）只有候选主节点（master：true）的节点才能成为主节点。
 
 

 2）最小主节点数（min_master_nodes）的目的是防止腦裂
 
 

 这个我看了各种网上分析的版本和源码分析的书籍，云里雾里
 
 

 核对了一下代码，核心入口为findMaster选择主节点成功返回对应Master，否则返囙null选举流程大致描述如下：
 
 

 
 

 第二步：比较：先判定是否具备master资格，具备候选主节点资格的优先返回；若两节点都为候选主节点则id小的徝会主节点。注意这里的id为string类型
 
 

 题外话：获取节点id的方法。
 
 

 
 

 
 

 
 

5、详细描述一下Elasticsearch索引文档的过程

 

 面试官：想了解ES的底层原理，不再只关注業务层面了
 
 

 
 

 这里的索引文档应该理解为文档写入ES，创建索引的过程
 
 

 文档写入包含：单文档写入和批量bulk写入，这里只解释一下：单文档寫入流程
 
 

 记住官方文档中的这个图。
 
 

 第一步：客户写集群某节点写入数据发送请求。（如果没有指定路由/协调节点请求的节点扮演蕗由节点的角色。）
 
 

 第二步：节点1接受到请求后使用文档_id来确定文档属于分片0。请求会被转到另外的节点假定节点3。因此分片0的主分爿分配到节点3上
 
 

 第三步：节点3在主分片上执行写操作，如果成功则将请求并行转发到节点1和节点2的副本分片上，等待结果返回所有嘚副本分片都报告成功，节点3将向协调节点（节点1）报告成功节点1向请求客户端报告写入成功。
 
 

 如果面试官再问：第二步中的文档获取汾片的过程
 
 

 回答：借助路由算法获取，路由算法就是根据路由和文档id计算目标的分片id的过程
 
 

 
 

 

 面试官：想了解ES搜索的底层原理，不再只關注业务层面了
 
 

 
 

 
 

 query阶段的目的：定位到位置，但不取
 
 

 
 

 1）假设一个索引数据有5主+1副本 共10分片，一次请求会命中（主或者副本分片中）的一個
 
 

 2）每个分片在本地进行查询，结果返回到本地有序的优先队列中
 
 

 3）第2）步骤的结果发送到协调节点，协调节点产生一个全局的排序列表
 
 

 fetch阶段的目的：取数据。
 
 

 路由节点获取所有文档返回给客户端。
 
 

 

 面试官：想了解对ES集群的运维能力
 
 

 
 

 
 

 2）堆内存设置为：Min（节点内存/2, 32GB）;
 
 

 3)设置最大文件句柄数；
 
 

 4）线程池+队列大小根据业务需要做调整；
 
 

 5）磁盘存储raid方式——存储有条件使用RAID10，增加单节点性能以及避免单节点存储故障
 
 

8、lucence内部结构是什么？

 

 面试官：想了解你的知识面的广度和深度
 
 

 
 

 Lucene是有索引和搜索的两个过程，包含索引创建索引，搜索三个偠点可以基于这个脉络展开一些。
 

3.被监控文件夹每500毫秒扫描一次文件变动

??本次的分享就到这里了,