ES 查询及写入优化

这篇具有很好参考价值的文章主要介绍了ES 查询及写入优化。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、ES调优手段

1.1 设计阶段调优

ES数据区分热、温、冷三个阶段
ES索引按月滚动生成
mapping设置合理的数据类型是否需要分词
使用别名管理索引???

 1.2 数据写入优化

1> 单条写入改为多条数据写入
2> 自动生成ID
3> 索引刷盘时间,index.refresh_interval: 30s; 默认1s改为30s,减少刷盘频次
4> 大批量数据导入时,可以把副本分片设置为0
5> 设置segment段大小,参数如下:
        indices.memory.index_buffer_size: 20% (最大堆内存百分比)
        indices.memory.min_index_buffer_size: 96mb (最小缓存大小)

6> 设置节点之间的故障检测配置,例如以下elasticsearch.yml配置:
discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 6
discovery.zen.fd.ping_interval: 30s

1.3 查询优化

1.3.1 分片数合理评估

1> 集群总分片数建议控制在5w以内,单个索引的规模控制在 1TB 以内,单个分片大小控制在30 ~ 50GB ,docs数控制在10亿内,如果超过建议滚动;(预估就就是分片数最好小于20)
2> 分片的数量通常建议小于或等于ES 的数据节点数量,最大不超过总节点数的2倍,通过增加分片数可以提升并发;
3> 分片数越多长尾效应越明显,并不是越多越好,在搜索场景合理控制分片数也可以提升性能。

 1.3.2 mapping设计

1> 合理设置 index:false(是否可索引),store:false(是否存储),doc_values:false (是否倒排)
2> 长字段增加序列化和高亮开销,但字段长度不能高于65536(short?),超长配置: ignore_above 忽略超长的数据。
3> 合理设置keyword类型,使用倒排索引。
4> 合理使用fields属性,对于text字段设置子字段为keyword,支持text和keyword两种功能。
"city": {"type":"text","fields":{"raw":{"type":"keyword"}}}
"sort": {"city.raw": "asc"}
5> 字段爆炸:

         1) 父层级设置 enabled:false 防止子字段mapping,能被行存查出来

        2) dynamic=runtime 入新字段也会更新 mapping,但是新加入的字段不会被索引,dynamic=strict 不允许新增一个不在 mapping中的字段,dynamic=false  (新字段不会被索引,不能作为查询条件,但是能被行存查询出来)。

3、查询 Routing 路由优化?
4、查询裁剪

        1>索引裁剪:如果已经滚动产生了很多索引,这个时候每次通过别名查询全量索引时,一样会有大量空转查询,可以通过索引名特征或时间范围,指定具体的索引名 进行查询

5、fetch性能优化

1、字段设置40个,stored,docvalues,source 三种数据性能相同
        1) 当字段数很少时,低于 40 时,使用 doc_value Fields 拉取,性能最优。
            分析:如果我们只需要返回其中包含的一小部分字段时,读取并解压这个巨大的_source字段可能会开销很高。
        2) 当字段超较多时,达到 40 以上时,使用 _source 变为最优。
            分析:当我们需要非常多或者几乎全部字段时,此时使用 doc_value Fields 可能会有非常多的随机IO。这个时候,读取 _source 一个字段就能够处理全部业务字段。
        ES 查询及写入优化

         设置示例:"properties" : {"_source":{"enabled":false//是否启用source}"field":{"type":"keyword","store":true,//是否存储原始值在storefields中"doc_values"true//是否存储原始值在docvalues中}"excludes":["meta.description","meta.other.*"]}
    2、内部结构
        Stored fields 在磁盘上以行的方式放置: 每个文档对应一个行,这个行包含该文档所有的stored fields。
        Doc values    以列的方式存储. 不同文档的相同字段被连续地存储在一起. 这种存储方式,可以直接访问一个特定的文档的特定字段。
        Source 与Stored fields方式差不多额外增加了_source字段存储全量json。

7、Force merge优化
        减少小的segment
8、ES缓存设计
9、聚合优化
     Metric 聚合 - 计算字段值的求和平均值,Geo-hash,采样等
     Bucket 聚合 - 将字段值、范围、或者其它条件分组到Bucket中
     Pipeline 聚合 - 从已聚合数据中进行聚合查询
10、分页查询
    1、from + size
    2、滚动翻页(Search Scroll)
    3、流式翻页(Search After)

详见:ES深度分页查询详解_es分页查询_斗者_2013的博客-CSDN博客文章来源地址https://www.toymoban.com/news/detail-481714.html

到了这里,关于ES 查询及写入优化的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 结合案例详细说明Spark的部分调优手段

    当谈到优化 Apache Spark 应用程序时,有一些更加详细和具体的优化策略和技术,可以帮助提高性能并最大化集群资源利用。以下是更详细的 Spark 调优方法: 资源配置与管理 : 内存调优 :合理设置 Executor 和 Driver 的内存分配,通过 spark.executor.memory 和 spark.driver.memory 参数调整

    2024年02月02日
    浏览(48)
  • flink常用的几种调优手段的优缺点

    不管是基于减少反压还是基于减少端到端的延迟的目的,我们有时候都需要对flink进行调优,本文就整理下几种常见的调优手段以及他们的优缺点 1.使用事件时间EventTime模式时,可以设置水位线发送的时间间隔,比如从200毫秒缩小到100毫秒,缩短两倍 正作用:减少事件端到端处

    2024年02月06日
    浏览(39)
  • 配置数据写入es的时间

    1、设置es的pipeline 2、检查pipeline是否设置成功 3、在索引的setting里设置默认pipeline 这样,在数据写es时候,就会生成字段date,数据写入时间

    2024年02月22日
    浏览(39)
  • python读取、写入以及删除es数据

    最近这段时间被es所困扰,庆幸最终学会了python操作es,怕以后忘记了,把代码放出来: 1.python读取es数据 2.python删除es数据: 3.python读取txt文档,再写入数据:

    2024年02月12日
    浏览(45)
  • Es无法写入数据的原因分析

    原因一: ElasticSearch入“只读”模式,只允许删除。当ES数据所在目录磁盘空间使用率超过90%后,ES将修改为只读状态,所以初步判断是磁盘空间不足导致es自动关闭了索引的写功能,只能进行读取或者删除。 解决: 手动将 index.blocks.read_only_allow_delete 改成false 查看index.blocks.

    2024年02月07日
    浏览(48)
  • ElasticSearch第十五讲 ES数据写入过程和写入原理以及数据如何保证一致性

    ES 数据并发冲突控制是基于的乐观锁和版本号的机制 一个document第一次创建的时候,它的_version内部版本号就是1;以后,每次对这个document执行修改或者删除操作,都会对这个_version版本号自动加1;哪怕是删除,也会对这条数据的版本号加1(假删除)。 对于更新操作 客户端对

    2024年02月12日
    浏览(45)
  • “更新查询超时时间“——优化ES索引更新性能的方法

    “更新查询超时时间”——优化ES索引更新性能的方法 在实际运用中,Elasticsearch (ES) 索引上的数据不可避免的需要进行更新操作。而update_by_query API 是一个十分强大的ES 更新功能工具,可以应对各种复杂的更新需求。然而,在进行高负载的大数据量操作时,update_by_query 会产生

    2024年02月03日
    浏览(47)
  • 得物社区亿级ES数据搜索性能调优实践

    2020年以来内容标注结果搜索就是社区中后台业务的核心高频使用场景之一,为了支撑复杂的后台搜索,我们将社区内容的关键信息额外存了一份到Elasticsearch中作为二级索引使用。随着标注业务的细分、迭代和时间的推移,这个索引的文档数和搜索的RT开始逐步上升。 下面是

    2024年02月05日
    浏览(51)
  • MySQL调优系列(二)——数据类型优化

    1、更小的数据类型更好 应该尽量使用可以正确存储数据的最小数据类型,更小的数据类型通常更快,因为它们占用更少的磁盘、内存和CPU缓存,并且处理时需要的CPU周期更少,但是要确保没有低估需要存储的值的范围,如果无法确认哪个数据类型,就选择你认为不会超过范

    2024年02月03日
    浏览(48)
  • 【Hive_06】企业调优2(数据倾斜优化、HQL优化等)

    数据倾斜问题,通常是指参与计算的数据分布不均,即某个key或者某些key的数据量远超其他key,导致在shuffle阶段,大量相同key的数据被发往同一个Reduce,进而导致该Reduce所需的时间远超其他Reduce,成为整个任务的瓶颈。 比如对于一张表的province_id字段,其中99%的值都为1,则

    2024年01月16日
    浏览(41)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包