感谢社区同学小莫（@msx）的贡献，Elasticsearch 的 PHP 客户端的中文手册上线了。 为什么是 PHP，因为 PHP 是最好的语言（不服来辩啊）。   地址：https://www.elastic.co/guide/c ... .html    

本文翻译自QBox官方博客的“Elasticsearch索引性能优化”系列文章中的第二篇，版权归原作者 Adam Vanderbush所有。该系列文章共有三篇，其中第一篇已有同行翻译，参考链接http://www.zcfy.cc/article/how ... .html   后续还会有第三篇的推送，敬请关注。

  作者：Adam Vanderbush 译者：杨振涛@vivo   本系列文章重点关注如何最大化地提升elasticsearch的索引吞吐量和降低监控与管理负荷。 Elasticsearch是准实时的，这表示当索引一个文档后，需要等待下一次刷新后就可以搜索到该文档了。 刷新是一个开销较大的操作，这就是为什么默认要设置一个特定的间隔，而不是每索引一个文档就刷新一次。如果想索引大批量的文档，并不需要立刻就搜索到新的索引信息，为了优化索引性能甚至搜索性能，可以临时降低刷新的频率，直到索引操作完成。 一个索引库的分片由多个段组成。Lucene的核心数据结构中，一个段本质上是索引库的一个变更集。这些段是在每次刷新时所创建，随后会在后台合并到一起，以保证资源的高效使用；每个段都会消耗文件句柄、内存和CPU。工作在该场景背后的Lucene负责段的合并，一旦处理不当，可能会消耗昂贵的计算资源并导致Elasticsearch自动降级索引请求到一个单一线程上。 本文将继续关注Elasticsearch的索引性能调优，重点聚焦在集群和索引级别的各种索引配置项设置。   1 关注refresh_interval参数 这个间隔通过参数index.refresh_interval设置，既可以在Elasticsearch配置文件里全局设置，也可以针对每一个索引库单独设置。如果同时设置，索引库设置会覆盖全局配置。默认值是1s，因此最新索引的文档最多不超过1s后即可搜索到。 因为刷新是非常昂贵的操作，提升索引吞吐量的方式之一就是增大refresh_interval；更少的刷新意味着更低的负载，并且更多的资源可以向索引线程倾斜。因此，根据搜索需求，可以考虑设置刷新间隔为大于1秒的值；甚至可以考虑在某些时候，比如执行批量索引时，临时关闭索引库的刷新操作，执行结束后再手动打开。 更新设置API可以在批量索引时动态改变索引以便更加高效，然后再修改为更加实时的索引状态。在批量索引开始前，设置：

curl -XPUT 'localhost:9200/test/_settings' -d '{
   "index" : {
       "refresh_interval" : "-1"
   }
}'

如果要做一次较大的批量导入，可以考虑设置index.number_of_replicas: 0来禁止副本。当设置了副本后，整个文档会被发送到副本节点，并重复索引过程；这意味着每个副本都会执行分析、索引及可能的合并操作。反之，如果索引时设置0副本，完成后再打开副本支持，恢复过程实质上只是一个网络字节流传输的过程，这比重复索引过程要高效得多了。

curl -XPUT 'localhost:9200/my_index/_settings' -d ' {
   "index" : {
       "number_of_replicas" : 0
   }
}'

然后一旦批量索引完成，即可更新设置（比如恢复成默认设置）：

curl -XPUT 'localhost:9200/my_index/_settings' -d '{
   "index" : {
       "refresh_interval" : "1s"
   } 
}'

并且可以强制触发一次合并：

curl -XPOST 'localhost:9200/my_index/_forcemerge?max_num_segments=5'

刷新API支持显式地刷新一个或多个索引库，以便让上次刷新后的所有操作完成并可被搜索感知。实时或近实时能力取决于所使用的索引引擎。比如，内置引擎要求显式调用刷新，而默认地刷新是周期性执行的。

curl -XPOST 'localhost:9200/my_index/_refresh'

 2 段与合并 段合并是一个计算开销较大的操作，而且会消耗大量的磁盘I/O。由于合并操作比较耗时，尤其是较大的段，所以一般设定为后台执行；这也没什么太大问题，因为大段的合并相对还是比较少的。 但也有时候，合并速率会低于生产速率；一旦如此，Elasticsearch将会自动地限流索引请求到一个单一线程。这能阻止段爆发问题，否则在合并前可能会生成数百个段。 Elasticsearch在这里默认是比较保守的：不希望搜索性能受到后台合并操作的挤兑；但有时（尤其是使用SSD，或写日志的场景）节流限制会过低。 默认的20 MB/s对于传统机械磁盘是一个挺不错的设置；如果使用SSD，可能要考虑加大该设置到100–200 MB/s。

curl -XPUT 'localhost:9200/test/_settings' -d '{
   "index" : {
       "refresh_interval" : "-1"
   }
}'

如果正在做批量导入，且根本不介意搜索，就可以彻底关闭合并限流；这样索引操作就会根据磁盘的速率尽可能快地执行：

curl -XPUT 'localhost:9200/_cluster/settings' -d '{
   "transient" : {
       "indices.store.throttle.type" : "none" 
   }
}'

设置限流类型为none就可以完全关闭合并限流；等批量导入完成后再恢复该配置项为merge。

curl -XPUT 'localhost:9200/_cluster/settings' -d '{
   "transient" : {
       "indices.store.throttle.type" : "merge" 
   }
}'

注意：上面的设置只适用于Elasticsearch 1.X版本，Elasticsearch 2.X移除了索引级别的速率限制（indices.store.throttle.type、 indices.store.throttle.max_bytes_per_sec、index.store.throttle.type、 index.store.throttle.max_bytes_per_sec），下沉到Lucene的ConcurrentMergeScheduler，以自动管理限流。 合并调度器（ConcurrentMergeScheduler）在需要时会控制合并操作的执行。合并操作运行在独立的线程池中，一旦达到最大线程数，更多的合并请求将会阻塞等待，直到有可用的合并线程。 合并调度器支持下列动态设置：  index.merge.scheduler.max_thread_count 最大线程数默认为 Math.max(1,Math.min(4,Runtime.getRuntime().availableProcessors() / 2))，对于固态硬盘（SSD）工作得很好；如果使用传统机械硬盘，则降低到1。 机械介质在并发I/O方面有较大的时间开销，因此需要减少线程数，以便能按索引并发访问磁盘。该设置允许每次有max_thread_count + 2个线程操作磁盘，所以设置为1表示支持3个线程。 如果使用机械硬盘而不是SSD，就要在elasticsearch配置文件中加入以下配置：  index.merge.scheduler.max_thread_count: 1 当然也可以为单个索引库设置：

curl -XPUT 'localhost:9200/my_index/_settings' -d '{ 
   "index.merge.scheduler.max_thread_count" : 1
}'

为所有已创建的索引库设置：

curl -XPUT 'localhost:9200/_settings' -d '{ 
    "index.merge.scheduler.max_thread_count" : 1
}'

 3 事务日志的清理 在节点挂掉时事务日志可以防止数据丢失，设计初衷是帮助在flush时原本丢失的分片恢复运行。该日志每5秒，或者在每个索引、删除、更新或批量请求（不管先后顺序）完成时，会提交到磁盘一次。 对Lucene的变更仅会在一次Lucene提交后持久化到磁盘，Lucene提交是比较重量级的操作，索引不能再每个索引或删除操作后就执行。当进程退出或硬件故障时，一次提交后或另一次提交前的变更将会丢失。 为防止这些数据丢失，每个分片有一个事务日志，或者与之关联的预写日志。任何索引或删除操作，在内置的Lucene索引处理完成后都是写到事务日志中。崩溃发生后，就可以从事务日志回放最近的事务来恢复分片。 Elasticsearch的flush操作，本质上是执行了一次Lucene提交并启动了一个新的事务日志；这些都是在后台自动完成的，目的是确保事务日志不会变得过大，否则恢复数据期间的回放操作可能需要消耗相当长的时间。这个功能同样暴露了一个API供调用，虽然很少需要手动触发。 与刷新（refresh）一个索引分片相比，真正昂贵的操作是flush其事务日志（这涉及到Lucene提交）。Elasticsearch基于许多随时可变的定时器来执行flush。通过延迟flush或者彻底关闭flush可以提升索引吞吐量。不过并没有免费的午餐，延迟flush最终实际执行时显然会消耗更长的时间。 下列可动态更新的配置控制着内存缓存刷新到磁盘的频率： index.translog.flush_threshold_size - 一旦事务日志达到这个值，就会发生一次flush；默认值为512mb。 index.translog.flush_threshold_ops - 在多少操作后执行flush，默认无限制。 index.translog.flush_threshold_period - 触发一次flush前的等待时间，不管日志大小，默认值为30分钟。 index.translog.interval - 检查是否需要flush的时间间隔，随机在该时间到2倍之间取值，默认为5秒。 可以把index.translog.flush_threshold_size的值从默认值的512MB调大比如到1GB，这样在一次flush发生前就可以在日志中积累更大的段。通过构建更大的段，就可以减少flush的次数以及大段的合并次数。所有这些措施加起来就会减少磁盘I/O并获得更好的索引效率。 当然，这需要一定数量的可用堆内存，用于额外的缓存空间，所以调整此类配置时请注意这一点。  4 索引缓冲区的容量规划 索引缓冲区用于存储新的索引文档，如果满了，缓冲区的文档就会写到磁盘上的一个段。节点上所有分片的缓冲区都是独立的。 下列配置项是静态的，并且必须在集群的每个数据节点上都配置： indices.memory.index_buffer_size - 可设置为百分比或者字节数大小，默认是10%，表示总内存的10%分配给该节点，作为索引缓冲区大小，全局共享。 indices.memory.min_index_buffer_size - 如果index_buffer_size设置为百分比，那么这项配置用于指定一个绝对下限，默认是48MB。 indices.memory.max_index_buffer_size - 如果index_buffer_size设置为百分比，那么这项配置用于指定一个绝对上限，默认是无限制。 配置项indices.memory.index_buffer_size定义了可供索引操作使用的堆内存百分比（剩余堆内存将主要用于检索操作）。如果要索引很多数据，默认的10%可能会太小，有必要调大该值。 5 索引和批量操作的线程池大小 接下来试试在节点级别调大索引和批量操作的线程池大小，看看否带来性能提升。 index - 用于索引和删除操作。线程类型是固定大小的（fixed)，默认大小是可用处理器核数，队列大小queue_size是200，该线程池最大为1+可用处理器核数。 bulk - 用于批量操作。线程类型是固定大小的，默认大小是可用处理器核数，队列大小是50，线程池最大为1+可用处理器核数。 单个分片与独立的Lucene是一个层次，因此同时执行索引的并发线程数是有上限的，在Lucene中默认是8，而在ES中可以通过index.index_concurrency配置项来设置。 在为该参数设置默认值时应当多想一想，特别是对于往一个索引库索引数据时，一个节点只有一个分片的情况。 由于索引/批量线程池可以保护和控制并发，所以大部分时候都可以考虑调大默认值；尤其是对于节点上没有其他分片的情况（评估是否值得），可以考虑调大该值。 关于译者

杨振涛 vivo互联网搜索引擎团队负责人，开发经理。10年数据和软件领域经验，先后从事基因测序、电商、IM及厂商互联网领域的系统架构设计和实现。专注于实时分布式系统和大数据的存储、检索和可视化，尤其是搜索引擎及深度学习在NLP方向的应用。技术翻译爱好者，TED Translator，InfoQ中文社区编辑。

    未经授权，禁止转载。   英文原文地址：https://qbox.io/blog/maximize- ... art-2 

去年我们社区一起翻译了一本书《Elasticsearch权威指南》，并且已经在官方上线了，链接： https://www.elastic.co/guide/cn/index.html    撒花~ ???????????????????   我想给大家分享一些这本书后面的故事：   大家在浏览到前言章节里面有一节“鸣谢”，里面可以看到很多熟悉的名字：   薛杰，骆朗，彭秋源，魏喆，饶琛琳， 风虎，路小磊，michealzh，nodexy，sdlyjzh，落英流离， sunyonggang，Singham，烧碱，龙翔，陈思，陈华， 追风侃侃，Geolem，卷发，kfypmqqw，袁伟强，yichao， 小彬，leo，tangmisi，Alex，baifan，Evan，fanyer， wwb，瑞星，刘碧琴，walker，songgl， 吕兵，东，杜宁，秦东亮，biyuhao，刘刚， yumo，王秀文，zcola，gitqh，blackoon，David，韩炳辰， 韩陆，echolihao，Xargin，abel-sun，卞顺强， bsll，冬狼，王琦，Medcl。   是的，这些就是我们权威指南的核心的译者了，虽然只是列了一个名字，但是其实背后付出了很多，有一些同学是在此之前就已经做过部分翻译的同学，如：路小磊，有一些是早就出版了多本书的资深作家了，如：饶琛琳，还有很多是社区里面一直就非常活跃的同学，各种线上线下活动都能看到你们的身影，感谢你们。   记得去年刚刚开始这个翻译的计划的时候，短短几天时间就收到了很多同学的报名，一下子累积人数多达80人， 正所谓人多就是力量，不过任务的分配和管理也就成了一个问题，要知道权威指南纸质版有650多页， 很厚的一本书，内容也真是非常多。我记得项目应该是3月份启动，到了5月份还没什么大的进展，大家都在摸索怎么去翻译，大家都无从下手，我也着急啊??，这个时候要感谢社区的热心成员：龙翔，?，他把他老婆Claire拉到我们翻译计划里面来了，?，这个翻译的事情总算有了转机，Claire在翻译项目的管理这块很专业?，提出了很多建设性意见，✍️，我们成立了一个翻译小组委员会，?，然后形成了5个翻译小组，?，每个小组由一个小组长来负责（大家积极踊跃）： A组：薛杰； B组：骆朗； C组：彭秋源； D组：饶琛琳； E组：魏喆； 这样，几十个翻译志愿者分别分到了不同的翻译小组，然后以翻译小组为单位进行翻译计划的分配和认领，任务也比较具体，小组成员再内部进行协调，有问题大家一起讨论，小组内部内也可以讨论，然后翻译就开始顺利的进行了！?   所以在这里要特别感谢龙翔两口子和几位翻译小组的小组长，当然还有各组的小组成员，如果没有你们，翻译工作估计要到进行到猴年马月啦，?，大家官网上面现在也看不到这些中文的资料啦！?   顺便值得一提的是，同时期还有另外一个开源社区也在翻译权威指南（韩文），并且比我们早开始，然后我们在去年12月份的时候就完成了，赶在Elastic{ON}DevChina大会之前完成的，而现在我们的已经上线了，也不知道他们的完成了没有，?。   权威指南的原作者Clinton和Zachary听说了我们的翻译的事情，都很兴奋，本来打算要来中国参加Elastic{ON}DevChina大会的，不过很遗憾，因为种种原因都没能过来，不过他们很支持我们，帮忙解决了后面上线的很多技术细节。   相信很多人想了解具体是怎么做的，我再给大家具体介绍一下，任务的管理和分配，我们使用GoogleDocs来进行协助，大家都有修改权限，常见的术语和FAQ也都会放在里面。 链接：[url=https://docs.google.com/spreadsheets/d/1vzPqcYJfz6ouY053E6WUdvS9WR8XqcHPyB7_U-72b_Q/edit?pref=2&pli=1#gid=1600884528]https://docs.google.com/spread ... 84528[/url]   另外关于本书翻译的项目管理，我们直接使用的是GitHub（https://github.com/elasticsear ... guide ），以asciidoc源文件为最小提交单元，每翻译完成一个文件，提交一个PR，每个PR单独Review，每个PR正常需要两个同学Review确认，正常的GitHub操作流程，和提交代码一样（文档其实本来也是和代码一样），翻译完成一篇之后，提交一个PR，打上标签“to be review”，表示翻译完了可以被Review了，Reviewer如果认可了就留言"LGTM", 然后打上标签“To be merged”，如果有不同意见，可以在PR上面留言讨论，PR提交人可以结合意见探讨或者修改，有些PR可以要讨论和修改很多次，比如这个：[url=https://github.com/elasticsearch-cn/elasticsearch-definitive-guide/pull/4]https://github.com/elasticsear ... ull/4[/url]，真的是不厌其烦，截止目前为止，总共提交了470多个翻译相关的PR。   为什么要以Asciidoc源文件作为翻译的基础，而不是gitdoc、wiki、markdown等等呢，因为我们可以保证后续的样式和官网一致，翻译审核完成之后就能够直接的放到官网上面，以提供给更多的人去访问和学习，同时官方的docs工具链也很完善，也支持编译输出成各种格式，如PDF等。另外文档和英文格式保持一致且也是托管在GitHub上面，方便后续的更新和维护，现在权威指南英文版正在更新到最新，到时候我们可以很方便的检测变化然后同步更新，文档即源码，文档是开源重要的一部分，参与开源的方式其实也有很多种，贡献代码和贡献文档都是同等重要的啦。可持续性更新也很重要。   是不是权威指南翻译完了之后就结束了呢，答案是：NO！ 文档和代码一样，也有Bug，也要不断完善，虽然我们在提交翻译和Review的过程中有反复进行过修改和进行过多轮的Review，（先是小组内部进行第一轮Review，打上标签“To be final review”，然后再由另外一个组的同学进行Review，然后在打上“To be merge”），但是由于大家水平有限，难免会出现各种翻译不准确、格式、表达等问题，所有希望大家能够继续帮忙改进，可以继续提交PR来完善修改，如果说嫌麻烦，可以发Issue说明哪里有问题或者觉得可以再讨论的地方，提供建设性意见。   后续也会有新的翻译，也希望大家踊跃参加，为Elastic中文的社区贡献力量。   一直想写这篇文章，今天终于完成啦！ 最后来一张上次来参加Elastic{ON}DevChina的译者合影！  

 在几十位社区同学的共同努力下，《Elasticsearch 权威指南》的翻译工作接近尾声， 在线访问链接如下： http://es-guide-preview.elasticsearch.cn   晚点会放到 elastic.co 官网上，大家学习 Elasticsearch 又多了一份好的资料，大家在访问的过程，如果发现有问题（翻译的各种 bug，翻译有误，不合理，不通顺，标点，格式等等），欢迎前往  https://github.com/elasticsear ... guide 提交 Issue，同时也欢迎直接提交 pull request 来改进本书。   同时也希望更多的志愿者加入我们一起进行翻译，后续我们会继续翻译其他的手册，另外有很多同学自己已经在翻译部分内容，也欢迎加入我们一起，有兴趣的同学加入我们翻译的QQ群：109764489 ，一起为 Elastic 的中文资料贡献力量。 最后，再次感谢以下本书的志愿者： 薛杰，骆朗，彭秋源，魏喆，饶琛琳， 风虎，路小磊，michealzh，nodexy，sdlyjzh，落英流离， sunyonggang，Singham，烧碱，龙翔，陈思，陈华， 追风侃侃，Geolem，卷发，kfypmqqw，袁伟强，yichao， 小彬，leo，tangmisi，Alex，baifan，Evan，fanyer， wwb，瑞星，刘碧琴，walker，songgl， 吕兵，东，杜宁，秦东亮，biyuhao，刘刚， yumo，王秀文，zcola，gitqh，blackoon，David，韩炳辰， 韩陆，echolihao，Xargin，abel-sun，卞顺强， bsll，冬狼，王琦。  

Mountain View, Calif. and Amsterdam, The Netherlands – March 30, 2016，英文原文 Elastic 今天宣布发布一个新的用于 Elasticsearch 和 Kibana 的插件，通过它们您可以很方便的发现、理解和探索您现有数据之间的关系。通过结合速度与相关度的搜索与图分析，Graph 已开启一页新的篇章同时为 Elastic Stack 带来更多的使用场景。   “我们构建 Graph 来帮助您以更多的方式来分析您存储在 Elasticsearch 中的数据” -- Steve Kearns，Elastic 高级产品总监提到， “通过把相关度作为切入点来查看数据间的关系，以前需要涉及到多个系统、批量作业甚至机器学习才能做到的事情，现在变成容易解决的问题。” Graph 为 Elastic Stack 开启新的使用场景 当您往 Elasticsearch 存储数据时 -- 产品信息、用户资料、文档、日志 -- 这些数据通常会包含对象（实体、人员、角色或者机器等）之间的引用关系。最好的探索这些关系的方法就是以可视化的方式去查看，Graph 通过以 Kibana 插件的方式提供了这样的能力。和 Elastic 的所有产品一样，它的 UI 界面设计简单易用，API 接口丰富强大，借助于 Elastic 在相关性评分的丰富经验，挖掘出您数据中最有价值的关系信息。这种独特的图形探索方式，并且无需引入新的索引格式，允许用户直接查询现有的数据，为 Elastic Stack 打开了一个新的更广泛的使用场景。 Graph 让一些复杂问题和场景（如行为分析、反欺诈、网络安全、药物发现、个性化医疗，或者基于持续的实时数据构建个性化推荐）的处理变得简单。Graph 通过相关性评分计算分离噪音和有用信息，自动识别最重要的这些关系。由于构建于 Elasticsearch 之上，Graph 天然具备高可用和近实时的能力。 Graph 为关系性探索带来相关度 当数据添加到 Elasticsearch 后，索引进程会跟踪和记录该文档每个字段每个值，更新全局词频信息，并准备相关数据用于大的范围查询。这些统计信息还被用来计算搜索的相关度以及有效的用于 Aggregation 中。通过 Graph，Elastic Stack 将以一种新的方式来使用这些统计信息 -- 首先是识别文档间的关系，然后再为指定查询按最相关的关系进行优先级排序处理。 相比之下，传统的图分析技术仅基于给定关系的简单的频次统计。这种方法的缺点是关系连接最多的元素 -- 如《肖申克的救赎》的电影推荐指数或在星巴克的信用卡购买数据 -- 被认为是最重要的而返回但不一定最有价值。Elasticsearch 中的 Graph，相关度会根据与每个关系的重要程度来进行计算而不是简单的平均处理，返回的是重要的结果，避免出现频繁或平常的连接关系 “Graph 是一个极好的例子，让大家看到我们的产品所带来的无限可能性以及我们如何努力让我们的用户尽可能容易的得益于 Elastic Stack。” -- Shay Banon，Elastic CTO 与联合创始人说 -- “我很自豪地看到我们的公司在持续创新，然后也迫不及待的想要看到我们的客户采用 Graph 这种新方法来解决真正具有挑战性的问题和案例.” 了解更多： Graph 产品首页 观看 Graph 在线研讨会   关于 Elastic Elastic 是世界领先的软件提供商，致力于结构化和非结构化数据的实时可用性，用户场景包括搜索、日志和数据分析等领域。公司由 Elasticsearch、Kibana、Logstash 和 Beats 这些开源项目背后的开发人员于2012年创立，Elastic Stack、X-Pack 和 Elastic Cloud 这些产品迄今累计已超过5千万次下载。 Elastic 由 Benchmark Capital、Index Ventures 及 NEA 投资，总部位于阿姆斯特丹和加州山景城，公司员工及办事处遍布全球各地。欲了解更多，请访问 http://elastic.co。