大数据 / 人工智能 / 区块链 / 数据库 / 热点
提到搜索引擎，大家可能首先会想到 Google、百度等互联网搜索网站，但是它们并不是今天的主角，我更想跟大家聊聊一个开源组件——Elasticsearch。纵宇轩 | 文
© 中兴数据智能（ZTE-DI）出品
Elasticsearch是什么？
Elasticsearch 是一个开源的搜索引擎，建立在一个全文搜索引擎库 Apache Lucene™ 基础之上。但是 Lucene 只是一个库，为了使用它，你需要使用 Java 并将 Lucene 直接集成到应用程序中。由于 Lucene 的原理是非常复杂的，因此想要充分发挥其功能其实并不是一件容易的事。Elasticsearch 也是使用 Java 编写的，它的底层使用 Lucene 做索引与搜索，它的目的是使全文检索变得简单，通过隐藏 Lucene 的复杂性，取而代之提供一套简单一致的 RESTful API。当然，Elasticsearch 并不仅仅是 Lucene，也不仅仅只是一个全文搜索引擎。它主要具有以下几个特点：
快速更新的版本
Elasticsearch 所在的社区是非常活跃的，其有一个显著的特点就是版本迭代与发布的周期非常快，几乎每年都会发布一个新的主要版本，而每个小版本的发布间隔通常只有二到四周。目前Elasticsearch 最新的发布版本为7.x，在Elasticsearch 7 发布的一年多的时间里，已经发布了20多个小版本。快速的版本发布可以让用户更快地体验到新的功能，当然这也是有代价的，如果你已经部署了 Elasticsearch，那么你就不得不考虑如何升级你的集群。这并不是一件简单的事情，特别是已经在生产环境中运行的集群，因此仍然有相当一部分集群在使用Elasticsearch 7之前的版本。但是这并不影响我们去了解Elasticsearch 7及其带来的新特性，例如更稳定的集群部署、更快的检索效率等，这也有助于我们来决策是否要升级我们的集群。
丰富的新特性
Elasticsearch官网介绍了7.x版本非常多的变化，包括各种新特性、功能和接口的变化以及 Bug 修复等。我们此处主要对一些比较常用的更新进行说明。1、支持 Lucene 8
Elasticsearch社区一如既往地希望支持最新的Lucene 版本，及其带来的新特性，因此Elasticsearch 7 底层使用了 Lucene 8。Lucene 8为Elasticsearch许多功能的改进奠定了基础，包括对top-k查询的搜索性能的改进等。Elasticsearch 7之前的版本使用名为Zen Discovery的集群协调机制，可以实现自由的集群缩扩容。但是这种机制也存在一定的缺陷，例如如果minimum_master_nodes没有正确配置的话，很容易发生脑裂并丢失数据。而Elasticsearch 7重新设计了集群协调机制，移除了minimum_master_nodes设置，由集群自己选择可以形成法定数量的节点。并且新的集群协调机制可以在很短时间内（亚秒级）完成选主。这进一步提升了集群协调的效率和健壮性。Elasticsearch 7增加了一个全新的断路器，可以跟踪JVM使用的内存情况。如果请求导致内存实际使用量过高，则会拒绝请求。另外，Elasticsearch 7还将聚合操作返回的bucket限制为10000以内，而这在之前的版本中是不受限制的。这样可以在分配堆内存比较低的情况下，一定程度上防止运行大型查询或聚合操作引起的集群故障。自适应分片访问选择，就是Elasticsearch会去记录各个数据节点过去的请求响应时间和在节点上的执行时间，还有节点上的线程池队列大小等，并计算出哪个节点的指标更好，接下来的这种请求就优先发送至该节点来处理。而之前的版本，对同一分片的一系列搜索请求以循环方式转发给主分片和每个副本。如果一个节点正好开始了很长时间的垃圾回收（GC），搜索请求仍然可能被转发到这种响应速度非常慢的节点，从而产生搜索延迟。而Elasticsearch 7默认开启了自适应副本选择的特性。每个节点会跟踪和比较搜索请求与其它节点的耗时，并使用这个数据调整向特定节点上的分片发送请求的频率，这可以很显著地提高搜索的吞吐量，减少搜索延迟。Elasticsearch可以提供近实时的搜索响应，主要因为默认间隔为一秒的自动刷新机制。这种频率的刷新虽然可以保证新写入的数据可以更快地被搜索到，但也在一定程度上对性能造成了影响，对于某些暂时无需被搜索的数据更是如此。Elasticsearch 7引入了搜索空闲的概念，在默认情况下，该分片如果在30秒内没有过任何搜索行为，那么这个分片就会被认为是搜索空闲。当分片处于这种阶段的时候，所有原计划的刷新任务都会被跳过，直到有搜索行为进来的时候才会触发下一次刷新任务。这会提高 Elasticsearch 的吞吐量，就像大量写入数据时关闭自动刷新可以提高写入速度那样。从Elasticsearch 5.6开始，就在逐步废弃type。Elasticsearch 6.x一个索引不再支持多个type，而到Elasticsearch 7则进一步不再推荐使用type，取而代之的是在请求中使用 _doc 直接作为参数的一部分。有相当多的用户在使用Elasticsearch时，并不会特别关注索引分片数的设置，但如果集群中分片较多的话，非常容易造成集群故障。因此Elasticsearch 7将默认的主分片数从5减少到1，这样可以尽量减少分片过多的情况。从Elasticsearch 7开始，High-level REST Client（HLRC）API的所有功能已经基本完成。对Java客户端而言，官方建议使用这种方式来访问集群，而原来的Transport Client则会被逐步废弃。其实很多用户最突出的入门障碍是不知道Elasticsearch是Java应用程序，特别是一些不熟悉Java的用户。因此在7.x中，Elasticsearch内置了一个OpenJDK发行版，以帮助用户更快地开始使用Elasticsearch，进一步做到开箱即用。同时，Elasticsearch也支持用户自己配置JDK，在启动Elasticsearch之前设置相应的JAVA_HOME即可。除了之前的纯文本日志外，Elasticsearch 7增加了JSON格式的日志记录，这意味着现在可以使用一些过滤工具以更结构化的方式来打印和处理日志。
当然，除了上述变化之外，Elasticsearch 7还提供了相当多的新功能和优化，想要进一步的了解的话，可以参考官网的文档，或者在实际开发和使用过程中进行探索。略显繁琐的升级
看到Elasticsearch 7带来了这么多的新特性以及性能提升，是不是已经迫不及待想要升级自己的集群了呢？先别急，前面我们提到Elasticsearch 版本发布的频率很快，一不留神可能你的集群就已经落后社区好几个版本了，如果只是小版本的变化那影响还不大，但是如果大版本都不一致那就需要谨慎考虑了。由于底层 Lucene 的特性，Elasticsearch 只能保证兼容前一个大版本的数据，即只有 Elasticsearch 6.x 版本可以直接升级到 Elasticsearch 7，更早的版本则必须考虑数据的兼容性问题。对于服务端部署而言，需要考虑当前版本如何稳定地升级到Elasticsearch 7：不能丢失数据是基本要求，如果可以不停止服务则更好。- 6.0-6.7需要停止整个集群，然后安装Elasticsearch 7并重启。当然也可以先滚动升级到6.8，然后再滚动升级至7.x；
- 5.x由于数据无法直接与7.x兼容，因此首先要升级到6.x，然后重建索引，保证集群中的数据为6.x的格式后，再按照上面的步骤升级至7.x；
- 更早的版本与上面类似，需要逐步升级大版本，重建数据，直到升级至 Elasticsearch 7。
另外，除了逐步升级的方式之外，还可以直接部署新的Elasticsearch 7集群，然后通过跨集群reindex的方式将数据迁移过来。这样的好处是不受原集群的版本限制，缺点则是需要更多的资源，而且效率也比较低。当然，reindex也有一些提高效率的手段，此处暂时不做深入讨论。除了服务端本身的升级外，如果还安装了一些插件，则插件的升级也需要考虑在内。如果其使用方式和要求发生了改变，也要考虑是否可以兼容。服务端升级完成并不意味着工作的结束，客户端也是一个非常重要的方面。Elasticsearch 支持很多不同的类型的客户端，以Java客户端为例，早期的版本推荐使用TransportClient，默认使用 9300 端口，以TCP的方式与集群进行交互。在Elasticsearch 7中这种客户端将被废弃，转为推荐使用REST Client，包括Low Level REST Client与High Level REST Client两种客户端，均使用HTTP方式访问集群，更加轻量级，兼容性也更好。另外，前面我们也提到Elasticsearch 7新版本带来了很多功能的新增和废弃，这也会导致相当一部分的接口发生改变。这些都需要开发者做出相当多的适配工作。最后说几句
Elasticsearch的更新进步是非常快的，这个组件到现在主要版本已经升级到了7，很多特性也在发生变化，使用群体也越来越广泛，在检索方面具有非常强大的能力。当然也有缺点，例如低版本的升级比较麻烦，对资源的要求比较高等等。但这都不会影响用户对Elasticsearch 的喜爱，毕竟爱她就要爱她的一切，不是吗？* 本文为中兴数据智能原创文章，转载请留言或评论获取授权。
