精华内容
下载资源
问答
  • 导语:在腾讯金融科技数据应用部的全民BI项目里,我们每天面对超过10亿级的数据写入,提高es写入性能迫在眉睫,在最近的一次优化中,有幸参与到了elasticsearch开源社区中。 背景 为了更便捷地分析数据,腾讯金融...

    导语:在腾讯金融科技数据应用部的全民BI项目里,我们每天面对超过10亿级的数据写入,提高es写入性能迫在眉睫,在最近的一次优化中,有幸参与到了elasticsearch开源社区中。

    背景
    为了更便捷地分析数据,腾讯金融科技数据应用部去年推出了全民BI的系统。这个系统通过elasticsearch进行基础的统计,超过10亿级的数据量需要尽可能快速地导入到es系统中。即使经过多次的参数优化,我们依然需要几个小时才能完成导入,这是系统此前存在的一大瓶颈。
    在这样的背景下,我们开始决定进一步深入es,寻找优化点。

    优化前的准备
    我们准备了1000万的数据,并在原程序(spark程序写入)上进行了几轮单机压测,得到了一些基本的性能数据。
    机器配置:CPU 24核,内存 64G
    ES基本配置:
    · 堆内存31G
    · 其他参数调整包括lock memory,translog.durability调整成async等(更详细的策略可以参见https://github.com/elastic/elasticsearch/issues/45371)
    文档数:1000万,字段400个(没有text字段)
    写入耗时:26分钟
    CPU:80%+

    寻找理论值
    在往下进入深水区之前,我们需要先回顾一下es本身,es本身是基于lucene基础上设计的分布式搜索系统,在写入方面主要提供了:
    · 事务日志和成组提交的机制提高写入性能并保证可靠性
    · 提供schema的字段定义(映射到lucene的字段类型)
    要进行优化,首先得验证一个问题:lucene的极限速率能到达多少,所以我在我的本机上构建了这样的一个测试。
    Macbook pro 15,6核12线程
    数据量1000万,每个document 400个字段,10个线程并发(考虑mac cpu Turbo 4.5G ,服务器2.4G(24核),所以只采用10线程并发)
    验证写入耗时549s(约10分钟)。
    26分钟 —> 10分钟,意味着理论上是可行的。那剩下的就看如何接近这个极限。因为那说明一定是es本身的一些默认特性导致了写入速率无法提升。
    下面的介绍忽略了一些相对简单的参数调优,比如关闭docvalues,这个对于非text字段,es默认开启,对于不需要groupby的场景,是不必要的,这个可以减少不少性能。
    经过初步的参数优化写入耗时降低到了18分钟,这是后面继续往下优化的基础。

    理解es写入的机制
    es的写入流程(主分片节点)主要有下面的几步
    · 根据文档id获取文档版本信息,判断进行add或update操作
    · 写lucene:这里只写内存,会定期进行成组提交到磁盘生成新分段
    · 写translog:写入文件

    在这里插入图片描述
    [ translog作用 ]
    除了上面的直接流程,还有三个相关的异步流程
    · 定期进行flush,对lucene进行commit
    · 定期对translog进行滚动(生成新文件),更新check point文件
    · 定期执行merge操作,合并lucene分段,这是一个比较消耗资源的操作,但默认情况下都是配置了一个线程。

    优化第一步-参数调优
    写lucene前面已经优化过,那么第一步的文档查找其实是在所有分段中进行查找,因为只提供了一个线程进行merge,如果merge不及时,导致分段过的,必然影响文档版本这一块的耗时。
    所以我们观察了写入过程中分段数的变化:
    在这里插入图片描述
    [ 写入过程中分段的变化 ]

    观察发现,分段的增长速度比预期的快很多。按照默认配置,index_buffer=10%,堆内存31G的情况,按lucene的写分段机制,平均到每个线程,也有125M,分段产生的速度不应该那么快。
    而这个问题的根源就是flush_threshold_size默认值只有512M ,这个参数表示在当未提交的translog日志达到该阈值的时候进行一次刷盘操作。

    在这里插入图片描述
    [ 小分段的产生 ]
    在这里插入图片描述
    [ 调整后比较缓和的分段增长 ]

    测试结果一看:18分钟!基本没有效果!
    理论上可行的方案,为什么却没有效果,带着这个疑问继续潜入深水区。

    优化继续-线程分析
    这时候就需要进行堆栈分析了,多次取样后,发现了下面的一个频繁出现的现象:
    在这里插入图片描述
    [ 被堵塞的线程 ]

    发现很多线程都停在了获取锁的等待上,而writeLock被rollGeneration占用了。
    写线程需要获取readLock
    rollGeneration拿走了writeLock,会阻塞readLock
    而在高flush_threshold_size的配置下,rollGeneration发生了300+次,每次平均耗时560ms,浪费了超过168s,而这个时间里写入线程都只能等待,小分段的优化被这个抵消了。
    这里有很多的关联关系,lush操作和rollGeneration操作是互斥的,因为flush耗时较长(5~10秒左右),在默认flush_threshold_size配置下,rollGeneration并没有这么频繁在100次左右,提高flush_threshold放大了这个问题。

    初步优化方案提交

    因为我们在写入过程中使用的translog持久化策略是async,所以我很自然的想到了把写日志和刷盘异步化。
    在这里插入图片描述
    [ 初版提交社区的方案 ]

    一开始的方案则想引入disruptor,消除写线程之间的竞争问题,后面因为es的第三方组件检查禁止使用sun.misc.Unsafe (disruptor无锁机制基于Unsafe实现)而放弃。
    基于这个方案,测试结果终于出现了跨越:13分钟。
    初版的方案问题比较多,但是它有两个特点:
    · 足够激进:在配置为async策略时,将底层都异步化了
    · 凸显了原方案的问题:让大家看到了Translog写入的影响

    Elastic创始人加入讨论
    没想到的是,在社区提交几次优化后,竟然吸引了大佬Simon Willnauer的加入。
    Simon Willnauer
    · elastic公司创始人之一和技术Leader
    · Lucene Core Commiter and PMC Member
    Simon的加入让我们重新复盘的整个问题。
    通过对关键的地方增加统计信息,我最终明确了关键的问题点在于FileChannel.force方法,这个操作是最耗时的一步。
    sync操作会调用FileChannel.force,但没有在writer的对象锁范围中,所以影响较小。但是因为rollGeneration在writeLock中执行,所以阻塞的影响范围就变大了
    跟社区讨论后,Simon最后建议了一个折中的小技巧,就是在关闭原translog文件之前(writeLock之外),先执行一次刷盘操作。
    在这里插入图片描述
    [ 代码修改 ]

    这个调整的效果可以让每次rollGeneration操作的耗时从平均570ms降低到280ms,在我的基准测试中(配置flush_threhold_size=30G,该参数仅用于单索引压测设计,不能在生产环境使用),耗时会从18分钟下降到15分钟。
    事实上,这并不是一个非常令人满意的解决方案,这里选择这个方案主要出于两点考虑:
    1.未来新的版本将考虑不使用Translog进行副分片的recovery,translog的滚动策略会进行调整(具体方案elasitc未透露)
    2.这个修改非常的风险非常小

    提交社区
    最后根据讨论的最终结论,我们重新提交了PR,提交了这个改动,并合并到了主干中。

    总结和待续
    下面是es写入中的影响关系和调用关系图,从图中可以看到各个因素直接的相互影响。

    在这里插入图片描述
    [ InternalEngine中的影响关系 ]

    最近提交的优化实时上只优化了rollGeneration,而实际上这里还有一些优化空间trimUnreferenceReader,这个也在跟社区沟通中,并需要足够的测试数据证明调整的效果,这个调整还在测试中。
    而在我们目前实际应用场景中,我们通过调整下面两个参数提高性能:
    · index.translog.flush_threshold_size 默认512M,可以适当调大,但不能超过indexBufferSize*1.5倍/(可能并发写的大索引数量),否则会触发限流,并导致JVM内存不释放!
    · index.translog.generation_threshold_size(默认64M,系统支持,但官方文档没有的参数,超过该阈值会产生新的translog文件),要小于index.translog.flush_threshold_size,否则会影响flush,进而触发限流机制

    参考文档
    1.张超《Elasticsearch源码解析与优化实战》

    展开全文
  • 在腾讯金融科技数据应用部的全民BI项目里,我们每天面对超过10亿级的数据写入,提高es写入性能迫在眉睫,在最近的一次优化中,有幸参与到了Elasticsearch开源社区中。 背景 为了更便捷地分析数据,腾讯金融...

    640?wx_fmt=gif

    640?wx_fmt=jpeg

    作者 | 腾讯开源团队

    责编 | 伍杏玲

    在腾讯金融科技数据应用部的全民BI项目里,我们每天面对超过10亿级的数据写入,提高es写入性能迫在眉睫,在最近的一次优化中,有幸参与到了Elasticsearch开源社区中。

     

    640?wx_fmt=png

    背景

     

    为了更便捷地分析数据,腾讯金融科技数据应用部去年推出了全民BI的系统。这个系统通过Elasticsearch进行基础的统计,超过10亿级的数据量需要尽可能快速地导入到es系统中。即使经过多次的参数优化,我们依然需要几个小时才能完成导入,这是系统此前存在的一大瓶颈。

    在这样的背景下,我们开始决定进一步深入es,寻找优化点。

     

    640?wx_fmt=png

    优化前的准备

     

    我们准备了1000万的数据,并在原程序(Spark程序写入)上进行了几轮单机压测,得到了一些基本的性能数据。

    机器配置:CPU 24核,内存 64G

    ES基本配置:

    • 堆内存31G

    • 其他参数调整包括lock memory,translog.durability调整成async等(更详细的策略可以参见https://github.com/elastic/elasticsearch/issues/45371)

    文档数:1000万,字段400个(没有text字段)

    写入耗时:26分钟CPU:80%+

     

    640?wx_fmt=png

    寻找理论值

     

    在往下进入深水区之前,我们需要先回顾一下es本身,es本身是基于Lucene基础上设计的分布式搜索系统,在写入方面主要提供了:

    • 事务日志和成组提交的机制提高写入性能并保证可靠性

    • 提供Schema的字段定义(映射到Lucene的字段类型)

    要进行优化,首先得验证一个问题:Lucene的极限速率能到达多少,所以我在我的本机上构建了这样的一个测试。

    Macbook pro 15,6核12线程数据量1000万,每个document 400个字段,10个线程并发(考虑Mac CPU Turbo 4.5G ,服务器2.4G(24核),所以只采用10线程并发)验证写入耗时549s(约10分钟)。

    26分钟 —> 10分钟,意味着理论上是可行的。那剩下的就看如何接近这个极限。因为那说明一定是es本身的一些默认特性导致了写入速率无法提升。

    下面的介绍忽略了一些相对简单的参数调优,比如关闭docvalues,这个对于非text字段,es默认开启,对于不需要groupby的场景,是不必要的,这个可以减少不少性能。经过初步的参数优化写入耗时降低到了18分钟,这是后面继续往下优化的基础。

     

    640?wx_fmt=png

    理解es写入的机制

     

    es的写入流程(主分片节点)主要有下面的几步

    • 根据文档ID获取文档版本信息,判断进行add或update操作

    • 写Lucene:这里只写内存,会定期进行成组提交到磁盘生成新分段

    • 写translog:写入文件

    640?wx_fmt=jpeg

    [ translog作用 ]

    除了上面的直接流程,还有三个相关的异步流程

    • 定期进行flush,对lucene进行commit

    • 定期对translog进行滚动(生成新文件),更新check point文件

    • 定期执行merge操作,合并lucene分段,这是一个比较消耗资源的操作,但默认情况下都是配置了一个线程。

     

    640?wx_fmt=png

    优化第一步:参数调优

     

    写Lucene前面已经优化过,那么第一步的文档查找其实是在所有分段中进行查找,因为只提供了一个线程进行merge,如果merge不及时,导致分段过的,必然影响文档版本这一块的耗时。

    所以我们观察了写入过程中分段数的变化:

    640?wx_fmt=png

    [ 写入过程中分段的变化 ]

    观察发现,分段的增长速度比预期的快很多。按照默认配置,index_buffer=10%,堆内存31G的情况,按lucene的写分段机制,平均到每个线程,也有125M,分段产生的速度不应该那么快。而这个问题的根源就是flush_threshold_size默认值只有512M ,这个参数表示在当未提交的translog日志达到该阈值的时候进行一次刷盘操作。

    640?wx_fmt=png

    [ 小分段的产生 ]

    640?wx_fmt=png

    [ 调整后比较缓和的分段增长 ]

    测试结果一看:18分钟!基本没有效果!

    理论上可行的方案,为什么却没有效果,带着这个疑问继续潜入深水区。

     

    640?wx_fmt=png

    优化继续:线程分析

     

    这时候就需要进行堆栈分析了,多次取样后,发现了下面的一个频繁出现的现象:

    640?wx_fmt=png

    [ 被堵塞的线程 ]

    发现很多线程都停在了获取锁的等待上,而writeLock被rollGeneration占用了。

    写线程需要获取readLockrollGeneration拿走了writeLock,会阻塞readLock。

    而在高flush_threshold_size的配置下,rollGeneration发生了300+次,每次平均耗时560ms,浪费了超过168s,而这个时间里写入线程都只能等待,小分段的优化被这个抵消了。

    这里有很多的关联关系,lush操作和rollGeneration操作是互斥的,因为flush耗时较长(5~10秒左右),在默认flush_threshold_size配置下,rollGeneration并没有这么频繁在100次左右,提高flush_threshold放大了这个问题。

     

    640?wx_fmt=png

    初步优化方案提交

     

    因为我们在写入过程中使用的translog持久化策略是async,所以我很自然的想到了把写日志和刷盘异步化。 

    640?wx_fmt=png

    [ 初版提交社区的方案 ]

    一开始的方案则想引入disruptor,消除写线程之间的竞争问题,后面因为es的第三方组件检查禁止使用sun.misc.Unsafe (disruptor无锁机制基于Unsafe实现)而放弃。基于这个方案,测试结果终于出现了跨越:13分钟。

    初版的方案问题比较多,但是它有两个特点:

    • 足够激进:在配置为async策略时,将底层都异步化了

    • 凸显了原方案的问题:让大家看到了Translog写入的影响

     

    640?wx_fmt=png

    Elastic创始人加入讨论

     

    没想到的是,在社区提交几次优化后,竟然吸引了大佬Simon Willnauer的加入。

    Simon Willnauer

    • elastic公司创始人之一和技术Leader

    • Lucene Core Commiter and PMC Member

    Simon的加入让我们重新复盘的整个问题。通过对关键的地方增加统计信息,我最终明确了关键的问题点在于FileChannel.force方法,这个操作是最耗时的一步。

    sync操作会调用FileChannel.force,但没有在writer的对象锁范围中,所以影响较小。但是因为rollGeneration在writeLock中执行,所以阻塞的影响范围就变大了

    跟社区讨论后,Simon最后建议了一个折中的小技巧,就是在关闭原translog文件之前(writeLock之外),先执行一次刷盘操作。

    640?wx_fmt=png

    [ 代码修改 ]

    这个调整的效果可以让每次rollGeneration操作的耗时从平均570ms降低到280ms,在我的基准测试中(配置flush_threhold_size=30G,该参数仅用于单索引压测设计,不能在生产环境使用),耗时会从18分钟下降到15分钟。

    事实上,这并不是一个非常令人满意的解决方案,这里选择这个方案主要出于两点考虑:

    1. 未来新的版本将考虑不使用Translog进行副分片的recovery,translog的滚动策略会进行调整(具体方案elasitc未透露)

    2. 这个修改非常的风险非常小

    提交社区

    最后根据讨论的最终结论,我们重新提交了PR,提交了这个改动,并合并到了主干中。

     

    640?wx_fmt=png

    总结和待续

     

    下面是es写入中的影响关系和调用关系图,从图中可以看到各个因素直接的相互影响。

    640?wx_fmt=png

    [ InternalEngine中的影响关系 ]

    最近提交的优化实时上只优化了rollGeneration,而实际上这里还有一些优化空间trimUnreferenceReader,这个也在跟社区沟通中,并需要足够的测试数据证明调整的效果,这个调整还在测试中。

    而在我们目前实际应用场景中,我们通过调整下面两个参数提高性能:

    • index.translog.flush_threshold_size 默认512M,可以适当调大,但不能超过indexBufferSize*1.5倍/(可能并发写的大索引数量),否则会触发限流,并导致JVM内存不释放!

    • index.translog.generation_threshold_size(默认64M,系统支持,但官方文档没有的参数,超过该阈值会产生新的translog文件),要小于index.translog.flush_threshold_size,否则会影响flush,进而触发限流机制。

    参考文档

    1. 张超《Elasticsearch源码解析与优化实战》

     

    【END】

    学Python想要达到大牛水准,你得这么学!

    https://edu.csdn.net/topic/python115?utm_source=csdn_bw

    640?wx_fmt=jpeg

     热 文 推 荐 

     

    ☞华为有意向西方公司出售 5G 技术;iOS 13 被爆漏洞;GNOME 3.34 正式发布| 极客头条

    不识 Pandas,纵是老手也枉然?

    为什么我在实时编码时失败了?

    2亿日活,日均千万级视频上传,快手推荐系统如何应对技术挑战?

    Docker容器化部署Python应用

    ☞给面试官讲明白:一致性Hash的原理和实践

    预警,CSW的50万枚尘封BTC即将重返市场?

    ☞她说:行!没事别嫁程序员!

    640?wx_fmt=gif点击阅读原文,输入关键词,即可搜索您想要的 CSDN 文章。

    640?wx_fmt=png

    你点的每个“在看”,我都认真当成了喜欢

    展开全文
  • Logstash写入Elasticsearch并发问题

    千次阅读 2017-03-14 22:51:09
    Logstash写入Elasticsearch并发问题  公司项目是通过Logstash采集日志存入Elasticsearch集群中,Logstash通过配置文件启动的时候报如下错误:   [2017-03-11T10:08:11,390][ERROR][Logstash.outputs.elastic...

    Logstash写入Elasticsearch并发问题

                  公司项目是通过Logstash采集日志存入Elasticsearch集群中,Logstash通过配置文件启动的时候报如下错误:

       

    [2017-03-11T10:08:11,390][ERROR][Logstash.outputs.elasticsearch] Action
    [2017-03-11T10:08:11,391][ERROR][Logstash.outputs.elasticsearch] Action
    [2017-03-11T10:08:11,393][INFO][logstash.outputs.elasticsearch]retrying failed 
    action with response code:429 ({"type" => "es_rejected_execution_exception", "reason" => "rejected" execute of org.elasticsearch.transport.TransportService$6@1046foc on EsThreadPoolExecutor [bulk.queue.capacity=50, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@e2e35f2 [Runing, pool size = 32, active threads = 32 queue.capacity=50, completed tasks=1041050369"]}

          以为是资源不够,通过停了所有Logstash进程再重新启动,同样报这个错误。确认不是集群资源问题。通过设置elasticsearch.yml设置纯种池也无法解决问题:

        

    1. threadpool.index.type: fixed  
    2. threadpool.index.size: 100  
    3. threadpool.index.queue_size: 500 

     

    线程处理不过来。queue加大到1000也无法解决这个问题。

     

           通过RestAPIs:http://localhost:9002/_cat/thread_pool?pretty查看其拒绝服务的那台机器,正好是分片数量最多的节点。也就是分片没有打散,当前集中有3个分片,导致请求压力都在当前节点上。通过设置模版和索引的index.routing.allocation.total_shards_per_node属性解决这个问题。设置成功后分片会打散至其他节点上。 

            需要特别注意这个属性,如果设置值为1,也就是说每个节点最多保存一个分片,当你分片的总数(包括复本数)大于节点数,会一值报分片的异常。



       

     

       

     

     

     

    展开全文
  • flink实战--数据写入ESElasticSearch

    万次阅读 热门讨论 2019-02-15 15:21:10
    Flink内置了Elasticsearch Connector用于对ES进行数据的操作,里面主要的类是ElasticsearchSink,使用时我们需要实现里面的抽象方法,自定义自己的逻辑。 版本说明: ES版本:6.3.2 flink 1.6.1 需要添加的...

    扫一扫加入大数据公众号和技术交流群,了解更多大数据技术,还有免费资料等你哦

    简介

            Flink内置了Elasticsearch Connector用于对ES进行数据的操作,里面主要的类是ElasticsearchSink,使用时我们需要实现里面的抽象方法,自定义自己的逻辑。

    版本说明:

    ES版本:6.3.2    flink 1.6.1 

    需要添加的依赖 

    <dependency>
         <groupId>org.apache.flink</groupId>
         <artifactId>flink-connector-elasticsearch6_2.11</artifactId>
         <version>1.6.1</version>
    </dependency>

    展开全文
  • 并发控制的必要性 并发案例.png 两个 Web 程序同时更新某个文档,如果缺乏有效的并发,会导致更改的数据丢失;...悲观并发控制 ...假定有同时写共享变量的可能,会对资源加锁,例如数据库行锁;...ES 采用...
  • ES 的乐观并发控制3. demo 1. 并发控制的必要性 两个 Web 程序同时更新某个文档,如果缺乏有效的并发,会导致更改的数据丢失 悲观并发控制 假设有变更冲突的可能,会对资源加锁,防止冲突。例如数据库行锁 乐观...
  • Flink写入Elasticsearch问题汇总 1、报错信息: org.apache.flink.client.program.ProgramInvocationException: The main method caused an error: mapping source must be pairs of fieldnames and properties ...
  • 一、写入ES的映射 add jar hdfs://****/user/hive/jar/elasticsearch-hadoop-6.6.1.jar; --注意jar包版本,不同elastic集群指定相应的版本jar包 --关闭Hive推测执行 SET hive.mapred.reduce.tasks.speculative....
  • Elasticsearch写入过程

    2020-12-15 15:35:09
    带着好奇心,让我们深入了解 Elasticsearch写入过程。 整体流程 我们知道每个索引 会被分成多个分片, 分片 又被分为主分片(primary shard)、副分片(replica shard)。增删改的操作都必先经过经过主分片,再...
  • scals Filek读取kafka 写入elasticsearch 简单实现引入pom依赖es的Mapping读取kafka 写入es 代码实现scala 构建kafka生产者scala 构建kafka消费者 引入pom依赖 <dependency> <groupId>org.apache....
  • 文章目录背景translog flush间隔调整索引刷新间隔refresh_interval段合并优化indexing ...在ES的默认设置下,是综合考虑数据可靠性、搜索实时性、写入速度等因素的。有时候,业务上对数据可靠性和搜索实时性要求并
  • 互联网应用架构:专注编程教学,架构...在很多同学的了解中,高并发更多局限在高并发读取里面,概念中并没有遇到高并发写入的问题,当遇到高并发问题的时候,集群,负载,读写分离,分库分表,但其实不然,面对不同类..
  • 初识elasticsearch解决并发问题

    千次阅读 2018-08-15 19:09:54
    一、乐观锁和悲观锁 ①悲观锁:  顾名思义,就是很悲观,每次去拿数据的时候都认为被人会修改,所以每次拿数据的时候都会加锁,以防别人修改,直到操作完成后... 悲观锁的缺点:并发能力低,同一时间只能有一个...
  • Flink实时消费kafka数据,数据经过处理,富化、清洗等操作,写入ES。在流式计算中,此场景十分常见。 本文采用ES的批量操作BulkProcessor方式,此方式使用的是TransportClient,基于Tcp协议;而rest方式采用的是...
  • ElasticSearch 并发操作问题

    千次阅读 2019-03-19 09:16:39
    解决并发问题 ...问题的原因是 Elasticsearch 不支持 ACID 事务。 对单个文件的变更是 ACIDic 的,但包含多个文档的变更不支持。 如果你的主要数据存储是关系数据库,并且 Elasticsearch 仅仅作...
  • 3.1.1 参数检查3.1.2 处理pipeline请求3.1.3 自动创建索引3.1.4 对请求的预先处理3.1.5 检测集群状态3.1.6 内容路由,构建基于shard的请求3.2 主分片写入流程3.2.1 预处理:3.2.1.1 检查请求3.2.1.2 是否延迟执行3.2...
  • 现有a表和b表,两张mysql数据库的表,需要把两张表的数据取共同字段,合并并导入es中,其中a表共有数据1000条,b表共有数据1200条,a表和b表的主键id都是从1开始递增的,结果导入的时候显示成功导入2200条数据,而...
  • 追求极致的写入速度时,很多是以牺牲可靠性和搜索实时性为代价的。有时候,业务上对数据可靠性和搜索实时性要求并不高,反而对写入速度要求很高,此时可以调整一些策略,最大化写入速度 如果是集群首次批量导入...
  • 背景说明线上业务反应使用 Flink 消费上游 kafka topic 里的轨迹数据出现 backpressure,数据积压严重。单次 bulk 的写入量为:3000/5...
  • 死磕elasticsearch(六)写入速度优化

    千次阅读 2019-06-24 21:44:20
    减少字段数量,对于不需要建立索引的字段,不写入ES。 将不需要建立索引的字段index属性设置为not_analyzed或no。 对字段不分词,或者不索引,可以减少很多运算操作,降低CPU占用。 尤其是binary类型,默认情况下...
  • Elasticsearch写入性能和查询性能测试

    千次阅读 2019-12-06 15:24:53
    单台部署3个ES(其实没必要集群) 2.写入性能测试 数据格式: cph:苏E5BF58(车牌号随机生成) zdkwz:尊占鸀(随机生成3个汉字) intime:1,575,522,767,992(随机生成时间戳) outtime:1,575,522,751,003(随机...
  • ElasticSearch(十二)——无文档ID的Json文件批量导入(Java/Python) 但是,之前 client = new PreBuiltTransportClient(settings).addTransportAddress(new InetSocketTransportAddress(InetAddress....
  • 配置良好的Kafka集群甚至可以做到每秒几十万、上百万的超高并发写入。 那么 Kafka 到底是如何做到这么高的吞吐量和性能的呢? 页缓存技术和磁盘顺序读写 首先 Kafka 每次接收到数据都会往磁盘上去写,如下图所示: ...
  • (Elasticsearch)ES写入性能优化方案

    万次阅读 2020-06-11 15:03:34
    ES的默认设置下,是综合考虑数据的可靠性,搜索实时性,写入速度等因素的。当离开默认设置,追求极致写入速度时,很多是以牺牲可靠性和搜索实时性为代价的。有时候,业务上对数据可靠性和搜索实时性要求不高,反而...
  • Elasticsearch 是当前主流的搜索引擎,其具有扩展性好,查询速度快,查询结果近实时等优点,本文将对Elasticsearch的写操作进行分析。 1. lucene的写操作及其问题 Elasticsearch底层使用Lucene来实现doc的读写操作,...
  • 1. 详解并发冲突 在电商场景下,工作流程为: 读取商品信息,包括库存数量 用户下单购买 更新商品信息,将库存数减一 如果是多线程操作,就可能有多个线程并发的去执行上述的3步骤流程,假如此时有两个人都来读取...
  • kafka消息中间件如何实现每秒几十万的高并发写入? 1、页缓存技术 + 磁盘顺序写 首先Kafka每次接收到数据都会往磁盘上去写,如下图所示。 那么在这里我们不禁有一个疑问了,如果把数据基于磁盘来存储,频繁的往磁盘...
  • 你可以使用多种策略来增加批处理作业和/或在线交易的 Elasticsearch 写容量。在过去的几年中,在写入容量方面,我遇到了瓶颈,并在不同的 ES 群集上犯了许多错误。 尤其是其中一项要求是写入具有严格 SLA 的实时索引...
  • 如果英文文档阅读有困难,参考:Elasticsearch: 权威指南,但是中文文档有滞后性,比如目前es已经到6.X版本,而中文文档以2.X版本为基础,因此对于新版本的话会有部分不适用。 参考博客:铭毅天下 关于使用阿里...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 16,455
精华内容 6,582
关键字:

并发写入es