@feuyeux
2016-01-22T20:29:01.000000Z
字数 7248
阅读 2465
Elasticsearch
最新出版的《Elasticsearch in Action》一书,是由Radu Gheorghe、Lee Hinman和Roy Russo共同撰写的,该书覆盖了Elasticsearch的基础功能、最佳管理实践,以及提高Elasticsearch稳定性和性能的实用性建议。InfoQ采访了几位作者,一起谈起了他们的这本书。
By Boris Lublinsky
如今,企业淹没在系统生成的浩瀚数据流当中。大数据技术业已集中在如何存储和处理这些海量的数据上。虽然离线数据的批处理非常重要,但我们通常需要对相应的实时数据做出明智的判断。这就是搜索引擎的用武之地,siteber.com将其描述为“最具活力的行业”:
搜索引擎行业在过去几年的成长,已经足以巩固其在美国最具创新性行业之一的地位。
于是乎,Elasticsearch和Apache Solr这两款当世领先的开源搜索引擎,正在享受着更广泛的使用,吸引着更多人的关注。Gheorghe、Hinman和Russo所著的新书《Elasticsearch in Action》是一本非常好的书,简洁地一步步介绍了搜索,解释了Elasticsearch是如何实现搜索功能的,并提供很多代码示例。这本书还深入讲述了Elasticsearch的管理和配置,强调了索引和搜索性能之间的权衡。
这本书的主要内容分为两部分:“核心功能”和“高级功能”,随后是几个附录,覆盖了非常重要但不通用的功能(只适用于一些特殊的应用场景)。
本书的第一部分描述了Elasticsearch核心构建块及其功能。覆盖了Elasticsearch建模和索引数据的主要功能和方法,它们将用于支持基于应用系统的查询和分析。
本书的第二部分讲述了如何在生产环境中使用Elasticsearch。书中提供了每种功能的工作原理,及其对性能和稳定性的影响:
六个附录包含了有关Elasticsearch的更多信息:
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》一书的合作者。
Radu Gheorghe 供职于Sematext,他为客户提供搜索咨询、产品支持,培训各种Elasticsearch和Solr的部署。他热衷于日志工具,比如rsyslog(是的,这可能是钟爱之一),他在Sematext也得到了负责日志分析服务Logsene的机会。
Matthew Lee Hinman 是一位充满激情的软件开发者,寻找具有挑战性的软件开发。活跃于开源社区,是Clojure和Elasticsearch社区的贡献者。Lee乐于在解决挑战性和趣味性问题的团队中工作。他非常关心代码质量,开源了他大部分业余时间编写的代码。
查看英文原文:“Elasticsearch in Action” – Book Review and Authors Interview