精华内容
下载资源
问答
  • 六、海量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 队列大小
    
    展开全文
  • 相关链接 官方文档—es性能调优文档 ES索引写入性能优化_Jimmy的专栏-CSDN博客_es写入优化 阿里云elasticsearch实践(最大限度提高写入速度)
    展开全文
  • 导语:在腾讯金融科技数据应用部的全民 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:写入文件
    38675bad4355a764f3718cd744d76782.png

    ▲ translog 作用

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

    • 定期进行 flush,对 Lucene 进行 commit
    • 定期对 translog 进行滚动(生成新文件),更新 check point 文件
    • 定期执行 merge 操作,合并 Lucene 分段,这是一个比较消耗资源的操作,但默认情况下都是配置了一个线程。

    优化第一步 — 参数调优

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

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

    f47b6675ec741418f250b63bf92beae8.png

    ▲ 写入过程中分段的变化

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

    ff96daca44b61efb2a3a388599a57431.png

    ▲ 小分段的产生

    2a87eb2dafa0846d1e4ee9c592eeca4f.png

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

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

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

    优化继续 — 线程分析

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

    94d8d426f41fe4de4f92b6b62998bfdb.png

    ▲ 被堵塞的线程

    发现很多线程都停在了获取锁的等待上,而 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,所以我很自然地想到了把写日志和刷盘异步化。

    7c03b2bfe08668459641b499a733e5cf.png

    ▲ 初版提交社区的方案

    一开始的方案则想引入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 之外),先执行一次刷盘操作。

    11c6549d26a3ce87397dd5ea8cfcfd3d.png

    ▲ 代码修改

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

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

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

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

    提交社区

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

    总结和待续

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

    ed63b64bcd894cf613aa2cd9c9228ee7.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,进而触发限流机制

    参考文档

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

    原文:https://mp.weixin.qq.com/s/KvFv_zrD_rnbfisUFo31tg

    作者:开源中国

    来源:我信公众号,开源中国

    免费分享java技术资料,需要的朋友可以在关注后私信我

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

    2020-02-29 17:48:52
    Elasticsearch优化——写入优化 1. translog flush间隔调整 2. 索引刷新间隔refresh_interval 3. 段合并优化 4. indexing buffer 5. 使用bulk请求 5.1 bulk线程池和队列 5.2 并发执行bulk请求 6. 磁盘间的任务均衡 7...
  • 乐观并发控制(使用的version版本号) 回忆时光 许多年前,一个刚结婚的名叫 Shay Banon 的失业开发者,跟着他的妻子去了伦敦,他的妻子在那里学习厨师。 在寻找一个赚钱的工作的时候,为了给他的妻子做一个食谱搜索...
  • 多线程并发写入ES时,连接断开,反馈的报错是error while performing request。修改DEFAULT_CONNECTION_REQUEST_TIMEOUT_MILLIS=-1后,报错Request cannot be executed;I/O reactor status :STOPPED. 2.原因分析
  • 通过ES对百亿级hbase数据构建索引,在读取Hbase至写入hbase过程中,发现有写入缓慢及数据丢失的现象,经过本人排查、调优后的一些经验总结如下,方便遇到相关问题的同学参考: ... 2、减少并发打开ES连接的线程...
  • 方案背景Hbase的索引方案有很多,越来越多的人开始选择ES+Hbase的方案,其实该方案并没有想象中那么完美,ES并发低,同时查询速度相对Hbase也慢很多,那为什么会选择他呢,它的写入比较快,如果一个宽表需要建20个...
  • 【1】深入ES

    2017-12-30 19:46:44
    curl 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 插入数...
  • 当前线程去判断当前数据的版本号,与当前es中数据的版本号 是否相同 如果版本号不同 说明数据已经被 其他人修改过 此时 该线程不会去更新es数据 而是去读取es中最新的数据版本 执行业务计算流程 然后在进行写入 ...
  • 用logstash收集日志并发送到redis,然后通过logstash取redis数据写入es集群,最近kibana显示日志总是中断,日志收集不过来,客户端重启发现报错: Failed to send event to Redis CommandError: OOM command ...
  • ES+Hbase对接方案概述

    2016-03-11 22:48:00
    Hbase的索引方案有很多,越来越多的人开始选择ES+Hbase的方案,其实该方案并没有想象中那么完美,ES并发低,同时查询速度相对Hbase也慢很多,那为什么会选择他呢,它的写入比较快,如果一个宽表需要建20个索引,在...
  • 副本就是对分片的 Copy,每个主分片都有一个或多个副本分片,当主分片异常时,副本可以提供数据的查询等操作。...ES 为了提高写入的能力这个过程是并发写的,同时为了解决并发写的过程中数据冲突的问题,ES ...
  • 多线程并发写入,可以减少每次底层磁盘fsync的次数和开销,从而提高es集群写入的吞吐量。 2.更改refresh参数 在es里面,refresh参数代表着它的刷新频率,刷新频率就是意味着数据在多长的时间里面会刷新,适当的增加...
  • 解耦智能客服系统中,企业注册完成后,需要完成一系列初始化操作,如创建es的索引,创建默认的一些数据发短信1.2.异步减少耗时,异步下单操作,接收到参数之后写入mq,通过多个节点去下单,然后websocket推送结果...
  • Shard(分片):索引数据可以拆分为较小的分片,每个分片放到不同的服务器上,提高并发能力。 Lucene 中的 Lucene index 相当于 ES 的一个 shard。 Segments(段): 分片由多个segments组成,每个segments都是一个...
  • 问题:org.elasticsearch.hadoop....适当减少并发,或添加参数 val conf = new SparkConf(); conf.set("es.nodes", elasticsearch_nodes); conf.set(&
  • 解决方法使用bulk API,调整 bulk 线程池和队列每个请求大小建议在5-15MB,逐步增大测试,当接收到EsRejectedExecutionException,就说明已经到达节点的瓶颈了,就需要减少并发或者升级硬件增加节点当写入数据时,...
  • 一个field的设置是不能被修改的,如果要修改一个Field,那么应该重新按照新的mapping,建立一个index,然后将数据批量查询出来,重新用bulk api写入index中 批量查询的时候,建议采用scroll api,并且采用多线程并发...
  • ES写入流程为先写入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主多从,主片挂了从片会自动顶上 满足...
  • 此情况产生的原因复杂,默认情况下,写入数据时,会先写入主分片,主分片成功后,再并发写入副本分片,当所有副本分片成功后,才会返回成功。所以要找出数据不一致的原因并解决,这种情况我没遇到过。 2.我遇到的是...
  • 1.NRT, 近实时,从写入数据到数据尅一被检索到有1秒的delay,基于es的查询可以达到毫秒级 2.Es的删除不是物理删除,只是标记成delelted 物理上没删除,当数据越来越多的时候才会删除,貌似和HbASE一样。 3.es通过...

空空如也

空空如也

1 2 3
收藏数 44
精华内容 17
关键字:

并发写入es