Elasticsearch-01-简介

1 简介

1.1 前世今生

前世（简化封装 Lucene ）

​ 2004年有一个以色列小伙子名字叫谢伊·班农（ShayBanon）他成亲不久来到伦敦。因为当时他的夫人正好在伦敦学厨师。初来乍到，也没有找到工作，于是班农就打算写一个叫作iCook的小程序来管理和搜索菜谱。一来练练手方便找工作；二来这个小工具还可以给夫人用。

​ 班农在编写 iCook 的程中使用了 Lucene ，感受到了直接使用 Lucene 开发程序的各种暴击和痛苦。于是他在 Lucene 之上封装了一个叫作 Compass 的程序框架，与 Hibernate 和 JPA 等 ORM 框架进行集成，通过操作对象的方式来自动调用 Lucene 以构建索引。

​ 这样做的好处是可以很方便地实现对 ”领域对象“ 进行索引的创建，并实现 ”字段级别“ 的检索，以及实现 “全文搜索” 功能。可以 Compass 大大简化了给 Java 程序添加搜索功能的开发。Compass 开源出来，变得很流行。

​ 在 Compass 编写到 2.x 版本的时候，社区面出现了更多需求，比如有处理更多数据的能力以及分布式的设计。班农发现只有重写 Compass ，才更好地实现这些分布式搜索的需求。于是 Compass 3.0 就没有了，取而代之的是一个全新的项目，也就是 Elasticsearch 。

​ 得益于之前 Compass 的技术积累，Elasticsearch 问世之初就考虑到了易用性。

​ Elasticsearch 作为一个独立的搜索服务器提供了非常方便的搜索功能。用户完全不用关心底层 Lucene 的细节，只需要通过标准的 Http+RESTful 格的 API 就可以行索引数据的增删改查。数据的输入输出用 JSON 格式，以文档和面向对象的方式，样就非常方便地理解和表达领域数据。

​ 简单来说，Elasticsearch 就是一个 Compass 的 RESTful 实现。

​ 同时 Elasticsearch 基于分片和副本的方式实现了一个分布式的 Lucene Directory ，再结合 Map-reduce 的理念实现了一个简单的搜索求分发合并的策略，轻松化解了海量索引和分布式高可用的问题。

今生（Elastic Stack，https://www.elastic.co/cn/what-is/elk-stack）

• Logstash

  ​ Logstash 是一个开源的日志处理工具，用 JRuby 写的。主要特点是基于灵活的 Pipeline 管道架构来处理数据。什么意思呢？可以理解为将数据放进一个管道内进行处理，并且就和真正的自来水管一样，管道由一截一截管子组成。每一个小管代表着一个数据处理的流程，每一个流程只做一件事情，然后可以根据数据的处理需要，选择多个不同类型的管子灵活组装。

  ​ 一开始 Elasticsearch 只是作为其中的一个输出存储，主要用于存储日志数据。不过，随着大家的使用发现， Elasticsearch 不仅可以存储大量的数据，水平伸缩也很方便，而且还具有很高的查找效率（全文搜索）。

  ​ 全文搜索在日志分析里面是非常基础的一个功能。通过一个关键字就能定位具体的详细日志，相比存放到关系型数据库和普同的文件存储，Elasticsearch 优势非常明显。于是 Logstash 搭配 Elasticsearch 变得很受欢 。

• Kibana

  ​ 由于 Logstash 自带的 UI 查询日志的界面有点简陋，于是有一个叫作 Rashid Khan 的运维工程师表示完全忍不了了，用 PHP 写了一个叫作 Kibana 的程序，一个更好看和更好用的前端界面。PHP 写完一版，他又用 Ruby 写一版，后面又用 AngularJS 写了一版，不仅有日志的搜索和查看，还加上了一些统计展示功能。

  ​ 这个时候 Elasticsearch 已经有 Facet 概念，也就是分面统计（1.0 之后推出了 Aggregation 来代替 Facet ），可以对数据中的某个字段进行单个维度的统计，支持多种统计类型。比如，TermFacet 可以计算字段中某些值出现了多少次；Histogram Facet 可以按时区进行汇总统计等。这些统计功能在前端 UI 就可以利用起来，展示一些饼图、时间曲线等等。在运维的分析里面自然也都是需要的。慢慢的，Kibana越做越复杂，支持的功能越来越多。

• Beats

  ​ Beats 是一系列非常轻量型的单一功能数据采集器，常见的有 Packetbeat 、Metricbeat、Auditbeat、Filebeat

Elastic Stack 是一套完整的，从全局性能监控到代码级别排障的技术栈

• Elastic Stack 完整版图

  

1.2 应用场景

1.2.1 企业搜索

简介

​ 企业搜索就是企业用的搜索服务。既可以是对内提供搜索服务，也可以是对外的搜索服务。对内的话主要搜索项目信息、文档信息、代码信息等；对外基于公司业务而提供搜索

特点

• 数据来源不同
• 数据内容不同
• 更新频率不同
• 数据完整行不同
• 搜索结果不同
• 不同用户需求不同

总结

​ 企业搜索的业务场景决定了企业搜索的特点和需求， Elastic 在 Elasticsearch 强大功能的基础之上，构建了更加易用的企业搜索解决方案 Elastic Enterprise Search。Elastic Enterprise Search 对企业搜索场景提供了从部署到权限控制、从文档接入到查询优化、从前端 UI 到结果控制的全场景覆盖的支持能力，虽然其相比自己构建一套企业搜索系统的门槛已非常低，易用性也非常好，但毕竟是一套接口完善、功能众多、相对复杂的系统。

1.2.2 可观测性

简介

”If you can’t measure it, you can’t manager it”

​ 要做到良好的管理一个系统，我们需要先做到良好的观测和测量。业界对可测性的定义由Logging（日志），Metrics （指标）和 Tracing （跟踪）组成。通常，需要多个技术栈的建设，才能实现完整的可观测性。而 Elastic Stack 则是一个一站式全栈的可观测性解决方案

1.3 重大版本变更

参考资料：https://www.cnblogs.com/flyrock/p/11614396.html

5.x

• Lucene 6.x 的支持，磁盘空间少一半；索引时间少一半；查询性能提升25%；支持IPV6。

• Internal engine级别移除了用于避免同一文档并发更新的竞争锁，带来15%-20%的性能提升

• Shrink API ，它可将分片数进行收缩成它的因数，如之前你是15个分片，你可以收缩成5个或者3个又或者1个，那么我们就可以想象成这样一种场景，在写入压力非常大的收集阶段，设置足够多的索引，充分利用shard的并行写能力，索引写完之后收缩成更少的shard，提高查询性能

• 提供了第一个Java原生的REST客户端SDK

• IngestNode，之前如果需要对数据进行加工，都是在索引之前进行处理，比如logstash可以对日志进行结构化和转换，现在直接在es就可以处理了

• 提供了 Painless 脚本，代替Groovy脚本

• 移除 site plugins ，就是说 head 、 bigdesk 都不能直接装 es 里面了，不过可以部署独立站点（反正都是静态文件）或开发 kibana 插件

• 新增 Sliced Scroll类型，现在Scroll接口可以并发来进行数据遍历了。每个Scroll请求，可以分成多个Slice请求，可以理解为切片，各Slice独立并行，利用Scroll重建或者遍历要快很多倍。

• 新增了Profile API

• 新增了Rollover API

• 新增Reindex

• 提供了第一个Java原生的REST客户端SDK 基于HTTP协议的客户端对Elasticsearch的依赖解耦，没有jar包冲突，提供了集群节点自动发现、日志处理、节点请求失败自动进行请求轮询，充分发挥Elasticsearch的高可用能力

• 引入新的字段类型 Text/Keyword 来替换 String

• 限制索引请求大小，避免大量并发请求压垮 ES

• 限制单个请求的 shards 数量，默认 1000 个

6.x

• 稀疏性 Doc Values 的支持
• Index sorting，即索引阶段的排序。
• 顺序号的支持，每个 es 的操作都有一个顺序编号（类似增量设计）
• 无缝滚动升级
• Removal of types，在 6.0 里面，开始不支持一个 index 里面存在多个 type
• Index-template inheritance，索引版本的继承，目前索引模板是所有匹配的都会合并，这样会造成索引模板有一些冲突问题， 6.0 将会只匹配一个，索引创建时也会进行验证
• Load aware shard routing， 基于负载的请求路由，目前的搜索请求是全节点轮询，那么性能最慢的节点往往会造成整体的延迟增加，新的实现方式将基于队列的耗费时间自动调节队列长度，负载高的节点的队列长度将减少，让其他节点分摊更多的压力，搜索和索引都将基于这种机制。
• 已经关闭的索引将也支持 replica 的自动处理，确保数据可靠。

7.x

• 集群连接变化：TransportClient被废弃 以至于，es7的java代码，只能使用restclient。然后，个人综合了一下，对于java编程，建议采用 High-level-rest-client 的方式操作ES集群

• ES安装包内嵌jdk，官方表示未来的es版本将不在支持11一下的JDK

• Lucene 9

• 重大改进-正式废除单个索引下多Type的支持 es6时，官方就提到了es7会删除type，并且es6时已经规定每一个index只能有一个type。在es7中使用默认的_doc作为type，官方说在8.x版本会彻底移除type。 api请求方式也发送变化，如获得某索引的某ID的文档：GET index/_doc/id其中index和id为具体的值

• 7.1开始，Security功能免费使用

• ECK-ElasticSearch Operator on Kubernetes

• 引入了真正的内存断路器，它可以更精准地检测出无法处理的请求，并防止它们使单个节点不稳定

• Zen2 是 Elasticsearch 的全新集群协调层，提高了可靠性、性能和用户体验，变得更快、更安全，并更易于使用（更换了选主算法，根本上解决了脑裂问题）

  • 新功能
    • New Cluster coordination
    • Feature - Complete High Level REST Client
    • Script Score Query

• 性能优化

  • Weak-AND算法提高查询性能
  • 默认的Primary Shared数从5改为1，避免Over Sharding
  • 更快的前 k 个查询
  • 间隔查询(Intervals queries) 某些搜索用例（例如，法律和专利搜索）引入了查找单词或短语彼此相距一定距离的记录的需要。 Elasticsearch 7.0中的间隔查询引入了一种构建此类查询的全新方式，与之前的方法（跨度查询span queries）相比，使用和定义更加简单。 与跨度查询相比，间隔查询对边缘情况的适应性更强。