愚者求师之过,智者从师之长。
vivo

vivo

【深圳ES Meetup】李猛:DB与ES结合,是业务系统实践值得探讨的事

活动nodexy 发表了文章 • 2 个评论 • 3926 次浏览 • 2019-11-09 17:41 • 来自相关话题

1月16日 Elastic 中文社区深圳 Meetup 上,李猛将带来关于ES 实践方面的主题分享。借此机会,我们邀请到他聊聊作为ES深度用户在探索ES过程中的心得以及对ES社区、活动、未来生态发展等方面的看法。   李猛 架构师/Elastic认证工程师 Elastic Stack产品深度用户,2012/2013年接触Elasticsearch,对Elastic Stack开发、架构、运维等方面有深入体验,实践过多种ES项目,最暴力的大数据分析应用,最复杂的业务系统应用等。   Q1、作为深度用户,当初是基于什么样的动机和考量选择使用 ES 产品并持续深入探索的? A:易用性与功能强大,个人平常比较爱好算法研究,选择任何数据产品本质上都是选择算法,算法的本质决定了产品的强大。 架构是个宏观问题,ES的设计是标准的分布式,架构的优秀设计带来的是易用性; 算法是个微观问题,ES集成了很多优秀的算法,这样在很多业务场景下都可满足,而不用更换不同的数据产品,这样也会带来产品运维方面的便利性,保障应用的技术栈不至于过多复杂。 Q2、在探索 DB 与 ES 的互通方面,有遇到什么难题吗?最后是如何解决的呢? A:数据一致性与实时性问题。应用架构思维变化,业务调整变化与技术方案变化。 Q3、结合您的实践经历,对 ES 目前的生态发展、应用以及未来有什么样的看法? A:ES目前主要应用是在单索引条件下查询,附带有简单的聚合分析能力。复杂的分析能力不具备,ES未来会增强复杂的分析能力,比如有条件的支持2个索引的关联分析。 Q4、您对本次技术沙龙活动的主题分享有什么期待? A:期望更多人参加探讨更多的业务应用场景,比如传统应用方面、大数据方面、机器学习方面;帮助大家以后项目实战有更多的案例参考。 Q5、您对 Elastic 中文社区发展有什么意见或建议呢? A:ES目前在国内的热度几乎超过任何数据库,几乎大大小小的公司,都在使用;从开始入门到成熟运用多多少少都会遇到很多问题,  希望社区活动更加多一点,业余的交流更多一点。比如可以办一些,走进某些企业的活动。 11月16日 Elastic 中文社区深圳 Meetup 火热报名中 分享主题:《DB到ES数据实时同步之路》 李猛  主题摘要:关系型数据库天然具备最严格的事务特性,有效的保证数据库一致性,但在高效查询方面显得很无力;Elasticsearch天然具备高效的查询算法,但在数据一致性方面却是先天缺陷;如何将DB与ES的优点结合,是任何一个企业公司业务系统实践都值得探讨的事。
b89578fa-29bc-49c3-a515-837cf1dcf7c3.png
 

深圳 ES Meetup 来啦! 11月16日 阿里中心

活动nodexy 发表了文章 • 1 个评论 • 1454 次浏览 • 2019-11-05 10:08 • 来自相关话题

shenzhen-es-201911_(1).png
    活动链接:   https://meetup.elasticsearch.c ... .html    议程   13:00-13:30  签到 13:30-13:40  活动介绍 13:40-14:20 分享主题:基于K8S的ES服务平台在头条的实践介绍 分享嘉宾:黄杨锋 @字节跳动 主题摘要:ES服务平台自上线以来,已经接入了头条、抖音等众多业务。本次分享将介绍ES服务平台从0到1的创建过程中所做的一些工作,包括K8S碰到的一些难点、ES功能的增强、跨机房容灾、全栈监控告警、自动化部署等功能。 14:20-15:00 分享主题:DB到ES数据实时同步之路 分享嘉宾:李猛 主题摘要:关系型数据库天然具备最严格的事务特性,有效的保证数据库一致性,但在高效查询方面显得很无力;Elasticsearch天然具备高效的查询算法,但在数据一致性方面却是先天缺陷; 如何将DB与ES的优点结合,是任何一个企业公司业务系统实践都值得探讨的事。 15:20-16:00 分享主题:Elasticsearch在腾讯的优化实践 分享嘉宾:陈曦 @腾讯云 主题摘要:Elasticsearch在腾讯得到了大规模应用,支撑了后台海量日志分析、腾讯云监控系统、腾讯文档搜索服务等。在服务公司内外部用户的过程中,腾讯ES团队碰到了很多痛点,对ES内核做了大量优化,使其在高性能、高可用性、低成本等方面有了大幅度的提升。本次分享将着重介绍腾讯ES团队对ES的优化实践。 16:00-16:40 分享主题:阿里云Elasticsearch内核优化与应用实践 分享嘉宾:欧阳楚才 @阿里巴巴 主题摘要: Elasticsearch在阿里云上服务了大量的客户,同时也面临着巨大的业务挑战。阿里云ES在内核引擎、中文分词、向量检索、容器化部署等方面做了一系列开发工作,应用于文档、日志、图像、视频的检索与分析。   16:40-17:20 分享主题:码云Gitee的Elasticsearch检索优化实战 分享嘉宾:陈鑫 @码云 主题摘要: 码云(Gitee.com)的Elasticsearch应用实战,以代码仓库搜索为例,讲解Elasticsearch在分词、信息检索模型、排序模型的自定义、重写和优化经验。   17:20-18:00 抽奖 & 交流  

访谈:2亿+ vivo 手机背后搜索服务平台的故事

Podcastmedcl 发表了文章 • 0 个评论 • 1500 次浏览 • 2018-12-24 19:09 • 来自相关话题

欢迎来到 Elastic 社区电台的第九期节目,我们本期节目的嘉宾是来自于 vivo 互联网负责搜索业务研发的杨振涛,vivo 从 Elasticsearch 2.1.1 版本开始,如今使用 100 多个 Elasticsearch 集群来支撑全球 2 亿多台手机每天的各种搜索请求,如 vivo 的应用商店、游戏、音乐、主题、壁纸、铃声等各种手机服务背后的搜索服务,也包括产品配件、售后、FAQ 等企业门户官网的搜索请求。今天让我们一起走进 vivo,看看 vivo 具体是如何使用 Elasticsearch 来解决这些搜索问题的。

可以点击下面的任意链接来收听(时长约 50 分钟):

嘉宾

podcast_vivo_banner720x420.jpg

杨振涛,vivo 互联网搜索引擎架构师,专注于数据的存储、检索与可视化,以及 DevOps 与软件过程改进。Elastic 中文社区深圳地区负责人,发起并组织 Elasticsearch、Redis、Jenkins 等主题的技术沙龙,并参与多个开源项目的文档翻译和中文化工作。 技术翻译爱好者,InfoQ 中文社区编辑,TED Translator。

主持人

Elastic 技术布道师,曾勇(Medcl)。

关于 vivo

vivo为一个专注于智能手机领域的手机品牌,vivo和追求乐趣、充满活力、年轻时尚的群体一起打造拥有卓越外观、专业级音质、极致影像、愉悦体验的智能产品,并将敢于追求极致、持续创造惊喜作为vivo的坚定追求。

关于 Elastic 社区电台

Elastic 开源社区举办的一款播客类节目, 邀请来自开源社区的用户,一起聊聊 Elastic 开源产品的使用案例、经验分享、架构变迁等等。

相关链接

【翻译】Elasticsearch索引性能优化(2)

Elasticsearchnodexy 发表了文章 • 0 个评论 • 5849 次浏览 • 2017-10-15 13:41 • 来自相关话题

本文翻译自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 

【深圳ES Meetup】李猛:DB与ES结合,是业务系统实践值得探讨的事

活动nodexy 发表了文章 • 2 个评论 • 3926 次浏览 • 2019-11-09 17:41 • 来自相关话题

1月16日 Elastic 中文社区深圳 Meetup 上,李猛将带来关于ES 实践方面的主题分享。借此机会,我们邀请到他聊聊作为ES深度用户在探索ES过程中的心得以及对ES社区、活动、未来生态发展等方面的看法。   李猛 架构师/Elastic认证工程师 Elastic Stack产品深度用户,2012/2013年接触Elasticsearch,对Elastic Stack开发、架构、运维等方面有深入体验,实践过多种ES项目,最暴力的大数据分析应用,最复杂的业务系统应用等。   Q1、作为深度用户,当初是基于什么样的动机和考量选择使用 ES 产品并持续深入探索的? A:易用性与功能强大,个人平常比较爱好算法研究,选择任何数据产品本质上都是选择算法,算法的本质决定了产品的强大。 架构是个宏观问题,ES的设计是标准的分布式,架构的优秀设计带来的是易用性; 算法是个微观问题,ES集成了很多优秀的算法,这样在很多业务场景下都可满足,而不用更换不同的数据产品,这样也会带来产品运维方面的便利性,保障应用的技术栈不至于过多复杂。 Q2、在探索 DB 与 ES 的互通方面,有遇到什么难题吗?最后是如何解决的呢? A:数据一致性与实时性问题。应用架构思维变化,业务调整变化与技术方案变化。 Q3、结合您的实践经历,对 ES 目前的生态发展、应用以及未来有什么样的看法? A:ES目前主要应用是在单索引条件下查询,附带有简单的聚合分析能力。复杂的分析能力不具备,ES未来会增强复杂的分析能力,比如有条件的支持2个索引的关联分析。 Q4、您对本次技术沙龙活动的主题分享有什么期待? A:期望更多人参加探讨更多的业务应用场景,比如传统应用方面、大数据方面、机器学习方面;帮助大家以后项目实战有更多的案例参考。 Q5、您对 Elastic 中文社区发展有什么意见或建议呢? A:ES目前在国内的热度几乎超过任何数据库,几乎大大小小的公司,都在使用;从开始入门到成熟运用多多少少都会遇到很多问题,  希望社区活动更加多一点,业余的交流更多一点。比如可以办一些,走进某些企业的活动。 11月16日 Elastic 中文社区深圳 Meetup 火热报名中 分享主题:《DB到ES数据实时同步之路》 李猛  主题摘要:关系型数据库天然具备最严格的事务特性,有效的保证数据库一致性,但在高效查询方面显得很无力;Elasticsearch天然具备高效的查询算法,但在数据一致性方面却是先天缺陷;如何将DB与ES的优点结合,是任何一个企业公司业务系统实践都值得探讨的事。
b89578fa-29bc-49c3-a515-837cf1dcf7c3.png
 

【深圳ES Meetup】李猛:DB与ES结合,是业务系统实践值得探讨的事

活动nodexy 发表了文章 • 2 个评论 • 3926 次浏览 • 2019-11-09 17:41 • 来自相关话题

1月16日 Elastic 中文社区深圳 Meetup 上,李猛将带来关于ES 实践方面的主题分享。借此机会,我们邀请到他聊聊作为ES深度用户在探索ES过程中的心得以及对ES社区、活动、未来生态发展等方面的看法。   李猛 架构师/Elastic认证工程师 Elastic Stack产品深度用户,2012/2013年接触Elasticsearch,对Elastic Stack开发、架构、运维等方面有深入体验,实践过多种ES项目,最暴力的大数据分析应用,最复杂的业务系统应用等。   Q1、作为深度用户,当初是基于什么样的动机和考量选择使用 ES 产品并持续深入探索的? A:易用性与功能强大,个人平常比较爱好算法研究,选择任何数据产品本质上都是选择算法,算法的本质决定了产品的强大。 架构是个宏观问题,ES的设计是标准的分布式,架构的优秀设计带来的是易用性; 算法是个微观问题,ES集成了很多优秀的算法,这样在很多业务场景下都可满足,而不用更换不同的数据产品,这样也会带来产品运维方面的便利性,保障应用的技术栈不至于过多复杂。 Q2、在探索 DB 与 ES 的互通方面,有遇到什么难题吗?最后是如何解决的呢? A:数据一致性与实时性问题。应用架构思维变化,业务调整变化与技术方案变化。 Q3、结合您的实践经历,对 ES 目前的生态发展、应用以及未来有什么样的看法? A:ES目前主要应用是在单索引条件下查询,附带有简单的聚合分析能力。复杂的分析能力不具备,ES未来会增强复杂的分析能力,比如有条件的支持2个索引的关联分析。 Q4、您对本次技术沙龙活动的主题分享有什么期待? A:期望更多人参加探讨更多的业务应用场景,比如传统应用方面、大数据方面、机器学习方面;帮助大家以后项目实战有更多的案例参考。 Q5、您对 Elastic 中文社区发展有什么意见或建议呢? A:ES目前在国内的热度几乎超过任何数据库,几乎大大小小的公司,都在使用;从开始入门到成熟运用多多少少都会遇到很多问题,  希望社区活动更加多一点,业余的交流更多一点。比如可以办一些,走进某些企业的活动。 11月16日 Elastic 中文社区深圳 Meetup 火热报名中 分享主题:《DB到ES数据实时同步之路》 李猛  主题摘要:关系型数据库天然具备最严格的事务特性,有效的保证数据库一致性,但在高效查询方面显得很无力;Elasticsearch天然具备高效的查询算法,但在数据一致性方面却是先天缺陷;如何将DB与ES的优点结合,是任何一个企业公司业务系统实践都值得探讨的事。
b89578fa-29bc-49c3-a515-837cf1dcf7c3.png
 

深圳 ES Meetup 来啦! 11月16日 阿里中心

活动nodexy 发表了文章 • 1 个评论 • 1454 次浏览 • 2019-11-05 10:08 • 来自相关话题

shenzhen-es-201911_(1).png
    活动链接:   https://meetup.elasticsearch.c ... .html    议程   13:00-13:30  签到 13:30-13:40  活动介绍 13:40-14:20 分享主题:基于K8S的ES服务平台在头条的实践介绍 分享嘉宾:黄杨锋 @字节跳动 主题摘要:ES服务平台自上线以来,已经接入了头条、抖音等众多业务。本次分享将介绍ES服务平台从0到1的创建过程中所做的一些工作,包括K8S碰到的一些难点、ES功能的增强、跨机房容灾、全栈监控告警、自动化部署等功能。 14:20-15:00 分享主题:DB到ES数据实时同步之路 分享嘉宾:李猛 主题摘要:关系型数据库天然具备最严格的事务特性,有效的保证数据库一致性,但在高效查询方面显得很无力;Elasticsearch天然具备高效的查询算法,但在数据一致性方面却是先天缺陷; 如何将DB与ES的优点结合,是任何一个企业公司业务系统实践都值得探讨的事。 15:20-16:00 分享主题:Elasticsearch在腾讯的优化实践 分享嘉宾:陈曦 @腾讯云 主题摘要:Elasticsearch在腾讯得到了大规模应用,支撑了后台海量日志分析、腾讯云监控系统、腾讯文档搜索服务等。在服务公司内外部用户的过程中,腾讯ES团队碰到了很多痛点,对ES内核做了大量优化,使其在高性能、高可用性、低成本等方面有了大幅度的提升。本次分享将着重介绍腾讯ES团队对ES的优化实践。 16:00-16:40 分享主题:阿里云Elasticsearch内核优化与应用实践 分享嘉宾:欧阳楚才 @阿里巴巴 主题摘要: Elasticsearch在阿里云上服务了大量的客户,同时也面临着巨大的业务挑战。阿里云ES在内核引擎、中文分词、向量检索、容器化部署等方面做了一系列开发工作,应用于文档、日志、图像、视频的检索与分析。   16:40-17:20 分享主题:码云Gitee的Elasticsearch检索优化实战 分享嘉宾:陈鑫 @码云 主题摘要: 码云(Gitee.com)的Elasticsearch应用实战,以代码仓库搜索为例,讲解Elasticsearch在分词、信息检索模型、排序模型的自定义、重写和优化经验。   17:20-18:00 抽奖 & 交流  

访谈:2亿+ vivo 手机背后搜索服务平台的故事

Podcastmedcl 发表了文章 • 0 个评论 • 1500 次浏览 • 2018-12-24 19:09 • 来自相关话题

欢迎来到 Elastic 社区电台的第九期节目,我们本期节目的嘉宾是来自于 vivo 互联网负责搜索业务研发的杨振涛,vivo 从 Elasticsearch 2.1.1 版本开始,如今使用 100 多个 Elasticsearch 集群来支撑全球 2 亿多台手机每天的各种搜索请求,如 vivo 的应用商店、游戏、音乐、主题、壁纸、铃声等各种手机服务背后的搜索服务,也包括产品配件、售后、FAQ 等企业门户官网的搜索请求。今天让我们一起走进 vivo,看看 vivo 具体是如何使用 Elasticsearch 来解决这些搜索问题的。

可以点击下面的任意链接来收听(时长约 50 分钟):

嘉宾

podcast_vivo_banner720x420.jpg

杨振涛,vivo 互联网搜索引擎架构师,专注于数据的存储、检索与可视化,以及 DevOps 与软件过程改进。Elastic 中文社区深圳地区负责人,发起并组织 Elasticsearch、Redis、Jenkins 等主题的技术沙龙,并参与多个开源项目的文档翻译和中文化工作。 技术翻译爱好者,InfoQ 中文社区编辑,TED Translator。

主持人

Elastic 技术布道师,曾勇(Medcl)。

关于 vivo

vivo为一个专注于智能手机领域的手机品牌,vivo和追求乐趣、充满活力、年轻时尚的群体一起打造拥有卓越外观、专业级音质、极致影像、愉悦体验的智能产品,并将敢于追求极致、持续创造惊喜作为vivo的坚定追求。

关于 Elastic 社区电台

Elastic 开源社区举办的一款播客类节目, 邀请来自开源社区的用户,一起聊聊 Elastic 开源产品的使用案例、经验分享、架构变迁等等。

相关链接

【翻译】Elasticsearch索引性能优化(2)

Elasticsearchnodexy 发表了文章 • 0 个评论 • 5849 次浏览 • 2017-10-15 13:41 • 来自相关话题

本文翻译自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