-
六、海量hive数据写入es优化
2019-08-16 11:21:40场景: 业务部门将客户画像结果表通过hive映射到es表...hive端优化: hive的取数据的速度大于写入到es的速度,es会由于集群规模问题或者资源问题无法同时接收hive过多的并发数。 由此hive端主要优化是减小map数 set...场景:
业务部门将客户画像结果表通过hive映射到es表,其中结果表600W条数据,但每条数据接近2W个标签,数据入到es后主要场景是多字段组合过滤查询后聚合求和。
优化思路
es默认最大字段数是1000,需要增大字段数
hive端优化: hive的取数据的速度大于写入到es的速度,es会由于集群规模问题或者资源问题无法同时接收hive过多的并发数。 由此hive端主要优化是减小map数- set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat 将多个小文件打包作为一个整体的inputsplit,减少map任务数
- set mapred.max.split.size=256000000;
set mapred.min.split.size.per.node=256000000
set Mapred.min.split.size.per.rack=256000000
增大map输入split的大小
es端优化:主要分为索引设计层面和数据写入层面
#创建es索引 curl -u ${ESUser}:${ESPasswd} -X PUT -H "Content-Type: application/json" "http://${ESIP}:${ESPort}/${ESIndex}/" -d '{"settings":{"number_of_shards":10,"number_of_replicas": 0},"mappings":{'"cmfe_coscp_tag_cust_base"':{"_all":{"enabled":false}}}}'
#修改es设置curl -u ${ESUser}:${ESPasswd} -X PUT -H "Content-Type: application/json" "http://${ESIP}:${ESPort}/${ESIndex}/_settings" -d'{"index.mapping.total_fields.limit":"5000","refresh_interval":"60s","index.translog.durability":"async"}'
'es.batch.size.entries' = '100', 'es.batch.size.bytes' = '1mb', 'es.batch.write.retry.count' = '10', 'es.batch.write.retry.wait' = '60s',
优化参数详解
精细设置全文域:string类型字段默认会分词,不仅会额外占用资源,而且会影响创建索引的速度。所以,把不需要分词的字段设置为not_analyzed 禁用_all字段 副本数量设置为0:全量数据保存在hadoop es副本数量是可以随时修改的,区别分片数量 使用es自动生成id:es对于自动生成的id有优化,避免了版本查找。因为其生成的id是唯一的 设置index.refresh_interval:索引刷新间隔,默认为1s。因为不需要如此高的实时性,我们修改为30s 设置段合并的线程数量: "index.merge.scheduler.max_thread_count" : 1 设置异步刷盘事务日志文件:"index.translog.durability": "async","index.translog.sync_interval": "30s"
集群层面参数设置
indices.memory.index_buffer_size: 20%,indices.memory.min_index_buffer_size: 96mb
已经索引好的文档会先存放在内存缓存中,等待被写到到段(segment)中。缓存满的时候会触发段刷盘(吃i/o和cpu的操作)。默认最小缓存大小为48m,不太够,最大为堆内存的10%。对于大量写入的场景也显得有点小。
设置index、merge、bulk、search的线程数和队列数。例如以下elasticsearch.yml设置:
# Search pool thread_pool.search.size: 5 thread_pool.search.queue_size: 100 # 这个参数慎用!强制修改cpu核数,以突破写线程数限制 # processors: 16 # Bulk pool thread_pool.bulk.size: 16 thread_pool.bulk.queue_size: 300 # Index pool thread_pool.index.size: 16 thread_pool.index.queue_size: 300
``
大数量写入的场景,会占用大量的网络带宽,很可能使节点之间的心跳超时。并且默认的心跳间隔也相对过于频繁(1s检测一次)此项配置将大大缓解节点间的超时问题discovery.zen.fd.ping_timeout: 120s discovery.zen.fd.ping_retries: 6 discovery.zen.fd.ping_interval: 30s
补充 :常用线程池参数设置
threadpool.index.type: fixed 写索引线程池类型 threadpool.index.size: 64 线程池大小(建议2~3倍cpu数) threadpool.index.queue_size: 1000 队列大小 threadpool.search.size: 64 搜索线程池大小 threadpool.search.type: fixed 搜索线程池类型 threadpool.search.queue_size: 1000 队列大小 threadpool.get.type: fixed 取数据线程池类型 threadpool.get.size: 32 取数据线程池大小 threadpool.get.queue_size: 1000 队列大小threadpool.bulk.type: fixed 批量请求线程池类型 threadpool.bulk.size: 32 批量请求线程池大小 threadpool.bulk.queue_size: 1000 队列大小threadpool.flush.type: fixed 刷磁盘线程池类型 threadpool.flush.size: 32 刷磁盘线程池大小 threadpool.flush.queue_size: 1000 队列大小
-
ELK--- Elasticsearc 并发写入优化相关
2021-01-02 17:30:14相关链接 官方文档—es性能调优文档 ES索引写入性能优化_Jimmy的专栏-CSDN博客_es写入优化 阿里云elasticsearch实践(最大限度提高写入速度)展开全文 -
vc6 往mdb写入信息_Elasticsearch高并发写入优化的开源协同经历
2020-11-30 01:39:54导语:在腾讯金融科技数据应用部的全民 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,进而触发限流机制
参考文档
张超《Elasticsearch源码解析与优化实战》
原文:https://mp.weixin.qq.com/s/KvFv_zrD_rnbfisUFo31tg
作者:开源中国
来源:我信公众号,开源中国
免费分享java技术资料,需要的朋友可以在关注后私信我
-
Elasticsearch高并发写入优化的开源协同经历
2019-09-12 17:18:13导语:在腾讯金融科技数据应用部的全民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源码解析与优化实战》 -
vc6 往mdb写入信息_Elasticsearch 高并发写入优化的开源协同经历 | 技术头条
2020-11-21 05:06:07作者 | 腾讯开源团队责编 | 伍杏玲在腾讯金融科技数据应用部的全民BI项目里,我们每天面对超过10亿级的数据写入,提高es写入性能迫在眉睫,在最近的一次优化中,有幸参与到了Elasticsearch开源社区中。背景为了更... -
我如何吸引Elastic创始人一起对高并发写入进行优化?
2019-09-14 00:06:43导语:在腾讯金融科技数据应用部的全民 BI 项目里,我们每天面对超过 10亿级的数据写入,提高 ES 写入性能迫在眉睫,在最近的一次优化中,有幸参与到了 Elastic... -
Elasticsearch 高并发写入优化的开源协同经历 | 技术头条
2019-09-15 01:02:26在腾讯金融科技数据应用部的全民BI项目里,我们每天面对超过10亿级的数据写入,提高es写入性能迫在眉睫,在最近的一次优化中,有幸参与到了Elasticsearch开源社区中。 背景 为了更便捷地分析数据,腾讯金融... -
elastic java client 关闭耗时过长如何解决?_我如何吸引Elastic创始人一起对高并发写入进行优化?...
2020-12-28 04:27:14导语:在腾讯金融科技数据应用部的全民 BI 项目里,我们每天面对超过 10亿级的数据写入,提高 ES 写入性能迫在眉睫,在最近的一次优化中,有幸参与到了 Elasticsearch 开源社区中。背景为了更便捷地分析数据,腾讯... -
es的写入优化
2020-02-29 17:48:52Elasticsearch优化——写入优化 1. translog flush间隔调整 2. 索引刷新间隔refresh_interval 3. 段合并优化 4. indexing buffer 5. 使用bulk请求 5.1 bulk线程池和队列 5.2 并发执行bulk请求 6. 磁盘间的任务均衡 7... -
ES学习笔记之-ES写入,读取,更新和分布式锁了解。
2020-06-22 17:17:40乐观并发控制(使用的version版本号) 回忆时光 许多年前,一个刚结婚的名叫 Shay Banon 的失业开发者,跟着他的妻子去了伦敦,他的妻子在那里学习厨师。 在寻找一个赚钱的工作的时候,为了给他的妻子做一个食谱搜索... -
【Elasticsearch】Request cannot be executed;I/O reactor status :STOPPED.
2021-02-23 18:38:16多线程并发写入ES时,连接断开,反馈的报错是error while performing request。修改DEFAULT_CONNECTION_REQUEST_TIMEOUT_MILLIS=-1后,报错Request cannot be executed;I/O reactor status :STOPPED. 2.原因分析 -
hbase写ES丢数据参数调优总结
2020-04-03 11:15:43通过ES对百亿级hbase数据构建索引,在读取Hbase至写入hbase过程中,发现有写入缓慢及数据丢失的现象,经过本人排查、调优后的一些经验总结如下,方便遇到相关问题的同学参考: ... 2、减少并发打开ES连接的线程... -
hbase 导入到es_ES+Hbase对接方案概述
2020-12-22 05:58:41方案背景Hbase的索引方案有很多,越来越多的人开始选择ES+Hbase的方案,其实该方案并没有想象中那么完美,ES并发低,同时查询速度相对Hbase也慢很多,那为什么会选择他呢,它的写入比较快,如果一个宽表需要建20个... -
【1】深入ES
2017-12-30 19:46:44curl ES_IP:ES_PORT/INDEX_NAME/_segment1、ES数据写入流程大体是下面这三个点让es比原生的lucene吞吐量下降了不少:1、为了数据完整性 ES额外添加了WAL(tanslog)2、为了能够并发修改 添加了版本机制3、对外提供服务... -
ES 重建索引
2018-09-14 10:33:31重新用bulk api写入index中批量查询的时候,建议采用scroll api,并且采用多线程并发的方式来reindex数据,每次scoll就查询指定 日期的一段数据,交个一个线程即可 1. 一开始,依靠dynamic mapping 插入数... -
乐观锁、悲观锁并发方案
2020-12-26 09:42:24当前线程去判断当前数据的版本号,与当前es中数据的版本号 是否相同 如果版本号不同 说明数据已经被 其他人修改过 此时 该线程不会去更新es数据 而是去读取es中最新的数据版本 执行业务计算流程 然后在进行写入 ... -
es redis logstash 日志收集系统排错
2019-09-26 16:31:23用logstash收集日志并发送到redis,然后通过logstash取redis数据写入到es集群,最近kibana显示日志总是中断,日志收集不过来,客户端重启发现报错: Failed to send event to Redis CommandError: OOM command ... -
ES+Hbase对接方案概述
2016-03-11 22:48:00Hbase的索引方案有很多,越来越多的人开始选择ES+Hbase的方案,其实该方案并没有想象中那么完美,ES并发低,同时查询速度相对Hbase也慢很多,那为什么会选择他呢,它的写入比较快,如果一个宽表需要建20个索引,在... -
08、es 进一步了解___b_ES 核心概念__3)副本(Replicas)
2019-11-14 11:46:13副本就是对分片的 Copy,每个主分片都有一个或多个副本分片,当主分片异常时,副本可以提供数据的查询等操作。...ES 为了提高写入的能力这个过程是并发写的,同时为了解决并发写的过程中数据冲突的问题,ES ... -
已经使用了bluk批量插入数据的时候怎么继续提高es插入数据的效率的几个方案
2020-08-19 18:10:48多线程并发写入,可以减少每次底层磁盘fsync的次数和开销,从而提高es集群写入的吞吐量。 2.更改refresh参数 在es里面,refresh参数代表着它的刷新频率,刷新频率就是意味着数据在多长的时间里面会刷新,适当的增加... -
http消息无法写入_面试篇之消息队列
2020-12-27 08:03:11解耦智能客服系统中,企业注册完成后,需要完成一系列初始化操作,如创建es的索引,创建默认的一些数据发短信1.2.异步减少耗时,异步下单操作,接收到参数之后写入mq,通过多个节点去下单,然后websocket推送结果... -
Elasticsearch写入原理(1)--数据底层
2021-03-06 00:47:27Shard(分片):索引数据可以拆分为较小的分片,每个分片放到不同的服务器上,提高并发能力。 Lucene 中的 Lucene index 相当于 ES 的一个 shard。 Segments(段): 分片由多个segments组成,每个segments都是一个... -
Spark写入elasticsearch报错Could not write all entries for bulk operation以及Connection error
2019-02-12 15:23:36问题:org.elasticsearch.hadoop....适当减少并发,或添加参数 val conf = new SparkConf(); conf.set("es.nodes", elasticsearch_nodes); conf.set(& -
es 插入很慢_[Elasticsearch] 如何提高索引速度
2021-01-26 23:00:29解决方法使用bulk API,调整 bulk 线程池和队列每个请求大小建议在5-15MB,逐步增大测试,当接收到EsRejectedExecutionException,就说明已经到达节点的瓶颈了,就需要减少并发或者升级硬件增加节点当写入数据时,... -
ES:基于scoll+bulk+索引别名实现零停机重建索引
2018-11-05 11:41:25一个field的设置是不能被修改的,如果要修改一个Field,那么应该重新按照新的mapping,建立一个index,然后将数据批量查询出来,重新用bulk api写入index中 批量查询的时候,建议采用scroll api,并且采用多线程并发... -
ElasticSearch学习笔记(四)—ElasticSearch分布式一致性原理
2019-09-10 17:14:36ES写入流程为先写入Primary,再并发写入Replica,最后应答客户端 检查Active的Shard数 写入Primary 并发的向所有Replicate发起写入请求 等所有Replicate返回或者失败后,返回给Client 早期的ES版本中允许主从副本... -
大数据开源框架特点大总结
2016-12-06 19:00:09实测es单机分配10g内存单实例,写入能力1200qps,60g内存、12核CPU起3个实例预计可达到6000qps。 同机房单条数据写入平均3ms(比mysql慢,mg不清楚) 容错能力比mg强。比如1主多从,主片挂了从片会自动顶上 满足... -
elasticsearch 每次查询结果不一样
2021-03-03 13:59:48此情况产生的原因复杂,默认情况下,写入数据时,会先写入主分片,主分片成功后,再并发写入副本分片,当所有副本分片成功后,才会返回成功。所以要找出数据不一致的原因并解决,这种情况我没遇到过。 2.我遇到的是... -
elasticsearch(2)一些注意点和一些关键词
2018-10-11 10:22:221.NRT, 近实时,从写入数据到数据尅一被检索到有1秒的delay,基于es的查询可以达到毫秒级 2.Es的删除不是物理删除,只是标记成delelted 物理上没删除,当数据越来越多的时候才会删除,貌似和HbASE一样。 3.es通过...