You know, for search

Elasticsearch作为当前流行的分布式搜索引擎，被广泛应用于日志检索，指标采集，APM，安全分析等领域。本文将对Elastic Stack的发展历程，基本原理，产品生态，主要功能和应用场景进行总结，以帮助大家对Elastic生态的前世今生能有一个清晰的了解。

1. 发展历程

1.1 美好的事物总有一个浪漫的开始

许多年前，一个叫Shay Banon的年轻人想为正在学习厨艺的新婚妻子编写一款菜谱搜索软件。在开发过程中，他发现搜索引擎库Lucene不仅使用门槛高，还有会有许多重复性工作。因此他决定在lucene基础之上封装一个简单易用的搜索应用库，并命名为Compress。Elasticsearch的前身就在这样浪漫的机缘下诞生了。

1.2 分布式为其注入了新的活力

之后shay找到了一份工作，工作内容涉及到大量的高并发分布式场景，于是他决定重写Compress，引入了分布式架构，并更名为Elasticsearch。Elasticsearch的第一个版本发布于2010年5月，发布后公众反响强烈。

1.3 开源力量助其腾飞

Elasticsearch在github上发布后，使用量骤增，并很快有了自己的社区。很快，社区中的 Steven Schuurman、Uri Boness 和 Simon Willnauer 与Shay Banon 一起成立了一家搜索公司Elasticsearch Inc.。
在Elasticsearch Inc.公司成立前后，另外两个开源项目也正在快速发展。一个是Jordan Sissel的开源可插拔数据采集工具Logstash, 另一个是Rashid Khan的开源数据可视化UI Kibana。由于作者间对彼此产品比较熟悉，因此决定合作发展，最终形成了Elastic Stack的经典技术栈ELK： Elasticsearch, Logstash, Kibana。

1.4 快速成长

之后Elasticsearch迅速发展，增加了许多新功能和特性 版本	发布日志	重要特性
0.7.0	2010.5.14	github上第一个版本
1.0.0	2014.2.14	备份恢复，聚合，熔断器，docvalues等
2.0.0	2015.10.28	组件版本统一，推出Elastic Cloud等
5.0.0	2016.10.26	商业组件整合为x-pack;使用Lucene6.0引入BKD树，稀疏数据优化等； beat引入module概念; 增加machine learning功能; shrink API; ingest node; painless 脚本等
6.0.0	2017.8.31	稀疏性docvalues支持，index sorting, sequence num, 滚动升级等
7.0.0	2019.4.10	引入新的集群协调层zen2; real内存熔断器等

2018年美东时间10月5日上午 9:30 整，纽约证券交易所的铃声响起，Elastic 成功上市。

2. 基本原理

2.1 最初的想法

Elasticsearch是一个分布式搜索引擎，底层使用Lucene来实现其核心搜索功能。虽然当前Elasticsearch拥有的众多的功能和解决方案，但是其核心仍然是全文检索。

• 什么是全文检索？
  生活中的数据可以分为结构化数据和非结构化数据。结构化数据是指格式和长度固定的数据，如一个人的年龄，姓名等。非结构化数据是指格式和长度不固定的数据，如一个文章的内容等。
  对于结构化数据，可以存储在DB中通过精确匹配找到。但是对于非结构化数据，一般查询时只能提供查询的局部信息或模糊信息，传统数据库无法根据这些信息进行查询（或者说效率很差）。
• 如何解决全文检索-倒排索引
  倒排索引时相对于正排索引而言的,如下图是正排索引和倒排索引的对比
  
  正排索引可以通过id查找到对应的文章，但是无法通过给的部分内容如love,找出含有该关键字的文档。 倒排索引会先对文档进行分析将其拆分成单个Term, 并存储包含该Term的文档id，这样便可以实现通过内容查找对应文档，如包含love的文档为文档1的第二个位置和文档2的第二个位置。倒排索引的逻辑结构如下图：
  
  当然这样的倒排索引建立起来会导致索引的大小迅速膨胀，lucene对此引入了一个特殊的数据结构叫FST，用于解决这个问题。感兴趣的朋友可以查询资料了解，公众号里后续也会专门介绍该数据结构。

2.2 Elasticsearch的改进

使用倒排索引实现全文检索都是Lucene已经具备的能力，Elasticsearch只是将这个能力封装起来提供给用户使用。那么Elasticsearch在lucene之上做了哪些改进和优化呢？ 首先我们先了解一下Lucene中的几个基本概念

• Index(索引)：一类业务数据的集合，类似于传统数据库DB的概念。
• Document(文档)：一条完整的数据记录，json格式，是数据存储和检索的基本单位，类似于传统数据库的一条记录。
• Field(字段)：文档的具体一个属性，类似于传统数据库的列。
• Term(分词)：全文检索特有词汇，在存储文档字段或检索时会先对传入的值进行拆分，使用拆分后的词进行存储和检索。

  2.2.1 分布式设计：

  为了支持对海量数据的存储和查询，Elasticsearch引入分片的概念，一个索引被分成多个分片，每个分片可以有一个主分片和多个副本分片，每个分片副本都是一个具有完整功能的lucene实例，可以独立进行存储和搜索。分片可以分配在不同的节点上，同一个分片的不同副本不能分配在相同的节点上。 在进行读写操作时，ES会根据传入的_routing参数（或mapping中设置的_routing, 如果参数和设置中都没有则默认使用_id), 按照公式shard_num = hash(\routing) % num_primary_shards,计算出文档要所在或要分配到的分片，再从集群元数据中找出对应主分片的位置，将请求路由到该分片进行读写操作。

2.2.2 近实时性-refresh操作

当一个文档写入Lucene后是不能被立即查询到的，Elasticsearch提供了一个refresh操作，会定时地调用lucene的reopen(新版本为openIfChanged)为内存中新写入的数据生成一个新的segment，此时被处理的文档均可以被检索到。refresh操作的时间间隔由refresh_interval参数控制，默认为1s, 当然还可以在写入请求中带上refresh表示写入后立即refresh，另外还可以调用refresh API显式refresh。

2.2.3 数据存储可靠性

1. 引入translog 当一个文档写入Lucence后是存储在内存中的，即使执行了refresh操作仍然是在文件系统缓存中，如果此时服务器宕机，那么这部分数据将会丢失。为此ES增加了translog， 当进行文档写操作时会先将文档写入Lucene，然后写入一份到translog，写入translog是落盘的(如果对可靠性要求不是很高，也可以设置异步落盘，可以提高性能，由配置index.translog.durability和index.translog.sync_interval控制)，这样就可以防止服务器宕机后数据的丢失。与传统的分布式系统不同，这里是先写入Lucene再写入translog，原因是写入Lucene可能会失败，为了减少写入失败回滚的复杂度，因此先写入Lucene.
2. flush操作 另外每30分钟或当translog达到一定大小(由index.translog.flush_threshold_size控制，默认512mb), ES会触发一次flush操作，此时ES会先执行refresh操作将buffer中的数据生成segment，然后调用lucene的commit方法将所有内存中的segment fsync到磁盘。此时lucene中的数据就完成了持久化，会清空translog中的数据(6.x版本为了实现sequenceIDs,不删除translog) 
3. merge操作 由于refresh默认间隔为1s中，因此会产生大量的小segment，为此ES会运行一个任务检测当前磁盘中的segment，对符合条件的segment进行合并操作，减少lucene中的segment个数，提高查询速度，降低负载。不仅如此，merge过程也是文档删除和更新操作后，旧的doc真正被删除的时候。用户还可以手动调用_forcemerge API来主动触发merge，以减少集群的segment个数和清理已删除或更新的文档。
4. 多副本机制 另外ES有多副本机制，一个分片的主副分片不能分片在同一个节点上，进一步保证数据的可靠性。

2.2.4 部分更新

lucene支持对文档的整体更新，ES为了支持局部更新，在Lucene的Store索引中存储了一个_source字段，该字段的key值是文档ID， 内容是文档的原文。当进行更新操作时先从_source中获取原文，与更新部分合并后，再调用lucene API进行全量更新， 对于写入了ES但是还没有refresh的文档，可以从translog中获取。另外为了防止读取文档过程后执行更新前有其他线程修改了文档，ES增加了版本机制，当执行更新操作时发现当前文档的版本与预期不符，则会重新获取文档再更新。