这篇文章主要为大家展示了“怎么提高ElasticSearch 索引速度”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“怎么提高ElasticSearch 索引速度”这篇文章吧。我Google了下，大致给出的答案如下：使用bulk API初次索引的时候，把 replica 设置为 0增大 threadpool.index.queue_size增大 indices.memory.index_buffer_size增大 index.translog.flush_threshold_ops增大 index.translog.sync_interval增大 index.engine.robin.refresh_interval这篇文章会讲述上面几个参数的原理，以及一些其他的思路。这些参数大体上是朝着两个方向优化的：减少磁盘写入增大构建索引处理资源一般而言，通过第二种方式的需要慎用，会对集群查询功能造成比较大的影响。这里还有两种形态的解决方案：关闭一些特定场景并不需要的功能，比如Translog或者Version等将部分计算挪到其他并行计算框架上，比如数据的分片计算等，都可以放到Spark上事先算好上面的参数都和什么有关其中 5,6 属于 TransLog 相关。4 则和Lucene相关3 则因为ES里大量采用线程池，构建索引的时候，是有单独的线程池做处理的7 的话个人认为影响不大2 的话，能够使用上的场景有限。个人认为Replica这块可以使用Kafka的ISR机制。所有数据还是都从Primary写和读。Replica尽量只作为备份数据。Translog为什么要有Translog? 因为Translog顺序写日志比构建索引更高效。我们不可能每加一条记录就Commit一次，这样会有大量的文件和磁盘IO产生。但是我们又想避免程序挂掉或者硬件故障而出现数据丢失，所以有了Translog，通常这种日志我们叫做Write Ahead Log。为了保证数据的完整性，ES默认是每次request结束后都会进行一次sync操作。具体可以查看如下方法：该方法会调用IndexShard.sync 方法进行文件落地。你也可以通过设置index.translog.durability=async 来完成异步落地。这里的异步其实可能会有一点点误导。前面是每次request结束后都会进行sync,这里的sync仅仅是将Translog落地。而无论你是否设置了async,都会执行如下操作：根据条件，主要是每隔sync_interval(5s) ，如果flush_threshold_ops(Integer.MAX_VALUE)，flush_threshold_size(512m),flush_threshold_period(30m) 满足对应的条件，则进行flush操作，这里除了对Translog进行Commit以外，也对索引进行了Commit。所以如果你是海量的日志，可以容忍发生故障时丢失一定的数据，那么完全可以设置，index.translog.durability=async，并且将前面提到的flush*相关的参数调大。而极端情况，你还可以有两个选择：设置index.translog.durability=async，接着设置index.translog.disable_flush=true进行禁用定时flush。然后你可以通过应用程序自己手动来控制flush。通过改写ES 去掉Translog日志相关的功能。当然，如果去掉Translog日志有两个风险点：Get***数据会有点问题。因为根据ID Get***数据是从Translog里拿的。我们知道ES通过Shard Replication 保证Node节点出现故障时出现数据的完整性。在Relocating的时候，Replica 从Primary 进行Recover时，Primary会先Snapshot Lucene，然后拷贝数据到Replica,***通过回放Translog 保证数据的一致性。VersionVersion可以让ES实现并发修改，但是带来的性能影响也是极大的,这里主要有两块：需要访问索引里的版本号，触发磁盘读写锁机制目前而言，似乎没有办法直接关闭Version机制。你可以使用自增长ID并且在构建索引时，index 类型设置为create。这样可以跳过版本检查。这个场景主要应用于不可变日志导入，随着ES被越来越多的用来做日志分析，日志没有主键ID,所以使用自增ID是合适的，并且不会进行更新，使用一个固定的版本号也是合适的。而不可变日志往往是追求吞吐量。当然，如果有必要，我们也可以通过改写ES相关代码，禁用版本管理。分发代理ES是对索引进行了分片(Shard)，然后数据被分发到不同的Shard。这样 查询和构建索引其实都存在一个问题：如果是构建索引，则需要对数据分拣，然后根据Shard分布分发到不同的Node节点上。如果是 香港云主机查询，则对外提供的Node需要收集各个Shard的数据做Merge这都会对对外提供的节点造成较大的压力，从而影响整个bulk/query 的速度。一个可行的方案是，直接面向客户提供构建索引和查询API的Node节点都采用client模式，不存储数据，可以达到一定的优化效果。另外一个较为麻烦但似乎会更优的解决方案是，如果你使用类似Spark Streaming这种流式处理程序，在***往ES输出的时候，可以做如下几件事情：获取所有primary shard的信息，并且给所有shard带上一个顺序的数字序号，得到partition(顺序序号) -> shardId的映射关系对数据进行repartition,分区后每个partition对应一个shard的数据遍历这些partions,写入ES。方法为直接通过RPC 方式，类似transportService.sendRequest 将数据批量发送到对应包含有对应ShardId的Node节点上。这样有三点好处：所有的数据都被直接分到各个Node上直接处理。避免所有的数据先集中到一台服务器避免二次分发，减少一次网络IO防止***处理数据的Node压力太大而导致木桶短板效应场景因为我正好要做日志分析类的应用，追求高吞吐量，这样上面的三个优化其实都可以做了。一个典型只增不更新的日志入库操作，可以采用如下方案：对接Spark Streaming,在Spark里对数据做好分片，直接推送到ES的各个节点禁止自动flush操作，每个batch 结束后手动flush。避免使用Version我们可以预期ES会产生多少个新的Segment文件，通过控制batch的周期和大小，预判出ES Segment索引文件的生成大小和Merge情况。***可能减少ES的一些额外消耗以上是“怎么提高ElasticSearch 索引速度”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注开发云行业资讯频道！
小编给大家分享一下HDFS产生背景是什么，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！HDFS产生背景随着数据量越来越大，在一个操作系统存不下所有的数据，那么就分配到更多的操作系统管…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
