《Elasticsearch in Action》书评与作者访谈

jopen 8年前

如今,企业淹没在系统生成的浩瀚数据流当中。大数据技术业已集中在如何存储和处理这些海量的数据上。虽然离线数据的批处理非常重要,但我们通常需要对相应的实时数据做出明智的判断。这就是搜索引擎的用武之地, siteber.com 将其描述为“最具活力的行业”:

搜索引擎行业在过去几年的成长,已经足以巩固其在美国最具创新性行业之一的地位。

于是乎, ElasticsearchApache Solr 这两款当世领先的开源搜索引擎,正在享受着更广泛的使用,吸引着更多人的关注。Gheorghe、Hinman和Russo所著的新书 《Elasticsearch in Action》 是一本非常好的书,简洁地一步步介绍了搜索,解释了Elasticsearch是如何实现搜索功能的,并提供很多代码示例。这本书还深入讲述了Elasticsearch的管理和配置,强调了索引和搜索性能之间的权衡。

这本书的主要内容分为两部分:“核心功能”和“高级功能”,随后是几个附录,覆盖了非常重要但不通用的功能(只适用于一些特殊的应用场景)。

本书的第一部分描述了Elasticsearch核心构建块及其功能。覆盖了Elasticsearch建模和索引数据的主要功能和方法,它们将用于支持基于应用系统的查询和分析。

  • 第一章介绍了通用搜索引擎的功能,及其在Elasticsearch中的实现。这章的最后介绍了Elasticsearch的安装,用于运行全书提供的示例。
  • 第二章讲述了Elasticsearch服务器中的数据组织,包括逻辑数据模型(搜索应用与Elasticsearch交互的方式)和物理布局(服务器内部处理数据的方式)。接下来,展示了这种数据模型是如何运用于典型的操作场景之中,即索引文档、查询文档、通过聚合分析数据,并水平扩展到多个节点上。
  • 第三章详述了从Elasticsearch读写数据和维护数据的细节:索引、更新和删除文档。通过分析文档的字段,详述了索引过程;向读者讲述了当我们写入时,都包含哪些内容,会发生什么事情。
  • 第四章详述了全文搜索,包括主要的查询器和过滤器、它们的内部工作机制,以及各种搜索方法的权衡。本章的最后,演示了一些最常用的过滤器和查询器,并解释了它们对于不同应用场景的适用性。
  • 第五章阐述了如何将文档和查询器中的文本,分析和拆分为用于搜索的词条。本章介绍了Elasticsearch提供的不同类型的分析器,并说明了如何构建我们自己的分析器,以充分利用Elasticsearch的全文搜索潜能。本章还介绍了用于解决复杂搜索业务的Ngrams、Shingles和Stemming。
  • 第六章关注于相关性计算,也就是打分(score),它定义了文档对原始查询的相关性。本章描述了影响文档打分的因素及其维护方式——使用不同的打分算法、调整指定查询器或者字段的boost值。本章还展示了Elasticsearch中,用于计算打分的API。
  • 第七章展示了如何使用聚合来执行实时数据分析。在Elasticsearch中的具体做法是,加载文档、匹配搜索条件,以及执行各种排序计算,比如统计字符类型字段中词项的数量,或者计算数值类型字段的平均值。聚合被分为两种:度量和桶。度量聚合是指对一组文档进行静态分析,得到度量值,比如最小值、最大值、均方差等。桶式聚合将匹配的文档拆分进一个或多个桶容器,然后告诉你每个桶里有多少文档。
  • 第八章是第一部分的最后一章,讲述了Elasticsearch对关系的支持。本章讨论了Elasticsearch提供的处理关系的几种常见方法,包括对象类型、嵌套文档、父子关系和一般的非规范化。同时,说明了如何使用每一种方法,以及它的优点和缺点。

本书的第二部分讲述了如何在生产环境中使用Elasticsearch。书中提供了每种功能的工作原理,及其对性能和稳定性的影响:

  • 第九章讲述了水平扩展Elasticsearch到多个节点。包括增加、删除、解除节点、选举Master的过程和分片迁移的机制。还深入分析了扩展的策略,包括索引分片和副本的最佳实践,比如,使用Oversharding或者基于时间的索引来确保当前的设计可以处理明年的数据。此外,还说明了如何使用索引别名和路由来提高集群的灵活性和可扩展性。在本章的最后,演示了如何使用Elasticsearch的API展示集群的状态和健康状况。
  • 第十章讲述了多种提高集群性能的办法。首先是如何将多个请求,比如index、update、delete、get和search合并成一次HTTP调用。这种分组通过最小化网络往返流量,可以大幅提高应用的性能。接着是Elasticsearch如何处理Lucene(底层搜索库)段:如何设置读写的刷新(refresh和flush)、合并策略和存储,这些设置对索引和搜索性能有何影响,以及在索引和搜索之间性能调优的权衡。本章的最后,讨论了影响Elasticsearch速度的一个重要的因素,缓存。详述了过滤器缓存的细节和最佳实践。还讲述了分片查询缓存,以及如何在预留足够的空间给Elasticsearch堆空间的同时,给操作系统足够的空间去缓存索引。
  • 第十一章讲述了监控和管理生产集群。包括额外的设置方法、简化集群管理,以及监控生产环境必要的度量指标。最后,讨论了备份和恢复一个数据节点。

六个附录包含了有关Elasticsearch的更多信息:

  • 附录A是关于地理空间搜索的。它可以为应用带来位置感知能力。Elasticsearch支持存储位置信息(点和多边形)和通用的空间操作,比如两点间距离、图形包含点、图形间重叠等计算。附录演示了如何在搜索中使用这一功能。
  • 附录B是讲如何管理Elasticsearch插件的。插件是一种开箱即用的,能为Elasticsearch带来扩展和增强功能的强大方式。附录中介绍了两种类型的插件。一种是site插件,没有额外的功能,只是为Elasticsearch提供了网页服务。另一种是code插件,可以是任何包含JVM代码、能被Elasticsearch执行的插件。附录讲述了如何安装、使用和卸载插件。
  • 附录C是关于Highlighting选项及其实现的。Highlighting指示为什么文档出现再查询结果中,匹配的词项被加上强调样式,让用户感受到文档是说什么的,以及和查询之间的关系。
  • 附录D是关于监控插件的。Elasticsearch社区提供了很多监控插件,可以通过引人入胜的图形界面,更容易地管理集群的状态、索引,以及执行查询。
  • 附录E是关于如何使用Elasticsearch渗滤器(percolator)的。渗滤器通常被定义为『搜索倒置』。渗滤器索引的是查询信息而不是索引文档。将查询注册并存储到内存当中,以便日后快速执行。使用渗滤器时,我们发送给Elasticsearch的是文档,而不是查询信息。这被称为渗滤文档,基本上会对其索引到小内存索引上。Elasticsearch根据小索引从已然注册的查询信息中查询,并返回匹配的查询信息。
  • 最后,附录F是关于建议器(suggester)的。附录解释了如何使用不同的建议器实现用户意图的自动补全功能。这里所描述的基本功能,包括词项和短语的建议、补全和上下文的建议。附录描述了各种建议器和Elasticsearch中与此功能相关的API。

Manning出版社为InfoQ的读者提供了这本书的第八章节选,“文档之间的关系”。

InfoQ采访了本书的作者,一起讨论更多关于Elasticsearch的实现和使用的信息。

InfoQ:本书中,在讨论典型Elasticsearch用例时,你们提出的一个选项是“增加Elasticsearch到现有系统中”。这个选项假定增加Elasticsearch到现有的数据存储系统。由于Elasticsearch的数据可用性有延迟,这可能导致在不同的存储系统中,产生数据之间的竞赛条件。特别是当数据被删除的时候,Elasticsearch仍然会返回查询结果。关于如何应对这样的情况,有什么好的建议吗?

Roy Russo:这种场景的最简回答是在应用层面管理整个过程,将分别从不同的数据存储系统中删除,封装为一个 try-catch 代码块,就像我们执行一次写操作。因此,第一步是调用Elasticsearch删除记录,然后调用主数据存储节点。如果任何阶段失败了,要处理异常逻辑。这里没有事务可用,因此异常处理需要手动回滚。

因为我所见过的最常用的Elasticsearch使用是基于时间序列的数据,这种场景并不常见。除非在某种罕见环境中,大多数软件没有规律地从时间序列存储中删除记录。还有一个办法是使用Elasticsearch作为单独的数据存储系统,但是这将带来其他健康方面的讨论,我不想陷于此处。

InfoQ:在Otis Gospodnetić所写的 Elasticsearch对比Solr的文章 中说,相比控制在一家公司手中的Elasticsearch而言,Solr更加开源。你同意这种评价吗,这对Elasticsearch用户来说是个问题吗?

Roy Russo:首先,我得说自己是Otis在Sematext所做成就的粉丝,但是我不同意他的观点。两个项目都是以Apache Software许可分发的,它们都接受来自社区的提交,受益于透明的缺陷、pull 请求和讨论。任何情况下,给出一个专业的开源软件和一个业余的开源软件供选择,留给读者去选择哪个最适合他的下一次关键的部署。

Elasticsearch用户受益于一个资金雄厚的公司提供的支持服务、插件和辅助产品,比如:Watcher,一种告警装置、Shield,支持认证和授权,以及与 Hadoop集成。在很短的时间里,Elastic已经将这个开源项目打造成一款产品。这里有一个区别,因为有一家公司在驱动产品,因此增加了质量保证流程、产品管理以决定哪些功能被添加、工艺路线图,以及结构化的工程团队做具体执行。我目前的角色是在关键任务的情况下部署大型集群、熟知这款由一个财务健康、专业的工程师团队所支持的产品。

InfoQ:Elasticsearch集群的每一个节点都提供了REST API端点,Elasticsearch是否提供了负载均衡的实现,以确保某个客户端不会压垮某一节点?

Roy Russo:虽然每个节点可以灵活地配置为不同的节点类型(Master、Client、Data)作为不完全解决方案,但是确实需要一个容错系统,我建议用户在Elasticsearch前面使用他们自己的负载均衡器。Nginx常用于负载均衡/反向代理。因此,有很多的教程和示例在线演示不同的负载均衡方案(轮询、最后连接等等),甚至是使用Nginx为指定的API端点或者HTTP方法做重定向(认证/授权)。

InfoQ:在这本书中,你们只展示了如何使用REST API操作Elasticsearch。与此同时,还存在很多Elasticsearch的 Java客户端 。有什么好的推荐吗?

Roy Russo:就全功能的实现而言,官方提供的Java客户端是最好的选择。使用官方的客户端,你的软件不会通过REST API通信,而是扮演一个正在加入集群的额外节点。以此方式附加到集群的好处是省去了每次请求中额外的跳(hop),因为操作会被自动路由到相关的节点。对于Spring用户来说,Spring Data Elasticsearch可以完美地处理这些,通过在ORM中增加一些方便的属性即可。Spring Data Elasticsearch以依赖包的方式内置了官方的Elasticsearch Java客户端,因此它的行为和使用Spring Data带来的益处一致。

InfoQ:父子关系实现上的描述稍微令人困惑。首先,你说父文档的索引过程不受到任何特殊影响,但子文档必须参考的父文档。你又说一个子文档参考一个父文档。我会认为这是指一个ID引用,但你后面又说,父文档可以在以后添加。因此,在这种情况下,如何指定引用呢?此外,你后面又谈到了父文档中有子文档的字段。这个字段是何时填充的呢?

Lee Hinman:子文档中对父文档的引用是通过URL中特殊的'parent'参数传入的,因此在索引子文档的时候父文档是不存在的,纵然这个父文档不存在,Elasticsearch还是允许指定'parent'参数的。父子关系在子文档的特殊字段中指定(不是在父文档,这就是为什么在父文档不存在的情况下,可以索引子文档),has_child查询或者has_parent查询,可以自动加载id mapping缓存。

InfoQ:在讲述多节点集群搜索时,你说“默认情况下,主分片和分片副本是轮询搜索的。”在这种情况下,是否存在本地因素?比如,一个副本存在与接收请求的节点,它将被使用?

Roy Russo:是的,如果主分片或者分片副本存在于当前节点,它将被使用。但是,有一点非常重要,我们必须意识到查询会在集群中广播到索引的每一个分片。那些分片执行本地查询并汇报匹配文档。

InfoQ:书中讲述了通过每个文档的版本号实现并发控制。Elasticsearch为每个文档存储很多的版本号还是只存最后一个版本号?

Roy Russo:这是个常见话题而且令人困惑。Elasticsearch根本没有提供版本控制,因为它保留了原始文档的拷贝。它只持有一个计数器,当文档更新、索引或者删除时,“_version”会自增。这是一个便捷的乐观锁,有助于保证在并发更新中,更新的是同一版本号的文档,而不是不同版本的。

InfoQ:书中讲述了两种节点的发现机制,多播(multicast)和单播(unicast,提供host列表)。两者都能用于AWS。是否还有其他的发现机制,比如基于AWS的负载均衡组?

Roy Russo:在AWS上部署时,我强烈推荐Elasticsearch cloud-aws插件。使用AWS IAM角色分配到EC2实例上,或者使用AWS Access key配置Elasticsearch配置文件,可以神奇般地让节点彼此发现。如果希望使用IAM角色配置,需要注意的是只能在EC2创建的时候指定IAM角色,此后不能再次修改。这个cloud-aws插件,可以无缝地让同一集群名称的各个节点彼此通信,是AWS环境中确定推荐和支持的。

额外需要注意的是,因为2.x的发布,这款插件从S3插件中分离出来。那些我们自动备份在S3上的插件,现在需要单独安装。

InfoQ:在Elasticsearch实现Lucene索引合并时,是只对主分片操作,然后拷贝全部副本吗?

Lee Hinman:不是这样的,Elasticsearch中的合并是独立运行的。因为Elasticsearch使用文档级别的副本,而不是文件级别,所以每个索引的每个分片的合并方式是不确定的。

InfoQ:现在AWS提供了Elasticsearch 托管服务 ,对Elasticsearch的采用会有什么影响?如何简化集群管理?

Roy Russo:坦白地讲,我希望这对Elasticsearch的采用没有伤害。我很喜欢AWS,但是Elasticsearch的发展需要业余时间,也许会给Elasticsearch用户数月之久的糟糕体验。

使用AWS Elasticsearch服务部署一个集群只需要非常方便的几次点击,但是需要你为便捷牺牲灵活性和可扩展性,直到他们开放配置信息和功能。我已经看到和经历的一些显著问题是,无法调优和自定义Elasticsearch性能和日志,无法安装插件,无法支持Elasticsearch v1.5.x,以及受阻于CORS。此外,你无法在VPC及相关软件中运行该服务,我会规避直到Amazon在该服务上解决。谁知道呢?也许他们能阅读我们这本书,然后为Elasticsearch服务做出成功的改变。

作者简介

Roy Russo 是预测分析公司Predikto的工程副总裁。在加入Predikto之前,Roy是佐治亚州亚特兰大AltiSource实验室的首席架构师。Roy曾是亚特兰大营销自动化软件供应商LoopFuse(最近被亚特兰大的SalesFusion收购)的联合创始人和产品管理副总裁。Roy还帮助联合创建JBoss Portal,JSR-168兼容的企业级Java门户网站,是Java内容仓库,JSR-170中,JBoss的代表。他目前是领先的ElasticSearch集群开源监控和管理应用,ElasticHQ.org的创始人《Elasticsearch in Action》一书的合作者。

《Elasticsearch in Action》书评与作者访谈 Radu Gheorghe 供职于Sematext,他为客户提供搜索咨询、产品支持,培训各种Elasticsearch和Solr的部署。他热衷于日志工具,比如rsyslog(是的,这可能是钟爱之一),他在Sematext也得到了负责日志分析服务Logsene的机会。

《Elasticsearch in Action》书评与作者访谈 Matthew Lee Hinman 是一位充满激情的软件开发者,寻找具有挑战性的软件开发。活跃于开源社区,是Clojure和Elasticsearch社区的贡献者。Lee乐于在解决挑战性和趣味性问题的团队中工作。他非常关心代码质量,开源了他大部分业余时间编写的代码。

查看英文原文: “Elasticsearch in Action” – Book Review and Authors Interview

</div>

来自: http://www.infoq.com/cn/articles/elasticsearch-action