elasticsearch 百亿级数据检索案例与原理

这篇具有很好参考价值的文章主要介绍了elasticsearch 百亿级数据检索案例与原理。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

版权说明: 本文章版权归本人及博客园共同所有,转载请标明原文出处( elasticsearch 百亿级数据检索案例与原理 - mikevictor - 博客园 ),以下内容为个人理解,仅供参考。

一、前言

    数据平台已迭代三个版本,从头开始遇到很多常见的难题,终于有片段时间整理一些已完善的文档,在此分享以供所需朋友的

实现参考,少走些弯路,在此篇幅中偏重于ES的优化,关于HBase,Hadoop的设计优化估计有很多文章可以参考,不再赘述。

【目前生产已存储百亿数据,性能良好(但未使用分词功能)】

二、需求说明

项目背景:

     在一业务系统中,部分表每天的数据量过亿,已按天分表,但业务上受限于按天查询,并且DB中只能保留3个月的数据(硬件高配),分库代价较高。

改进版本目标:

    1. 数据能跨月查询,并且支持1年以上的历史数据查询与导出。

    2. 按条件的数据查询秒级返回。

三、elasticsearch检索原理

    3.1 关于ES和Lucene基础结构

    谈到优化必须能了解组件的基本原理,才容易找到瓶颈所在,以免走多种弯路,先从ES的基础结构说起(如下图):

es百亿级数据查询,elasticsearch,lucene,全文检索

    一些基本概念:

        Cluster          包含多个Node的集群
        Node             集群服务单元
        Index             一个ES索引包含一个或多个物理分片,它只是这些分片的逻辑命名空间
        Type              一个index的不同分类,6.x后只能配置一个type,以后将移除
        Document    最基础的可被索引的数据单元,如一个JSON串
        Shards          一个分片是一个底层的工作单元,它仅保存全部数据中的一部分,它是一个Lucence实例 (一个lucene索引最大包含2,147,483,519 (= Integer.MAX_VALUE - 128)个文档数量)
        Replicas       分片备份,用于保障数据安全与分担检索压力

       ES依赖一个重要的组件Lucene,关于数据结构的优化通常来说是对Lucene的优化,它是集群的一个存储于检索工作单元,结构如下图:

es百亿级数据查询,elasticsearch,lucene,全文检索

    在Lucene中,分为索引(录入)与检索(查询)两部分,索引部分包含 分词器、过滤器、字符映射器 等,检索部分包含 查询解析器 等。

一个Lucene索引包含多个segments,一个segment包含多个文档,每个文档包含多个字段,每个字段经过分词后形成一个或多个term。

     

    通过Luke工具查看ES的lucene文件如下,主要增加了_id和_source字段:

es百亿级数据查询,elasticsearch,lucene,全文检索

    3.2 Lucene索引实现

    Lucene 索引文件结构主要的分为:词典、倒排表、正向文件、DocValues等,如下图:

    

es百亿级数据查询,elasticsearch,lucene,全文检索

    

es百亿级数据查询,elasticsearch,lucene,全文检索

   注:整理来源于lucene官方:  http://lucene.apache.org/core/7_2_1/core/org/apache/lucene/codecs/lucene70/package-summary.html#package.description   

    Lucene 随机三次磁盘读取比较耗时。其中.fdt文件保存数据值损耗空间大,.tim和.doc则需要SSD存储提高随机读写性能。
另外一个比较消耗性能的是打分流程,不需要则可屏蔽。

        关于DocValues:

        倒排索引解决从词快速检索到相应文档ID, 但如果需要对结果进行排序、分组、聚合等操作的时候则需要根据文档ID快速找到对应的值。

通过倒排索引代价缺很高:需迭代索引里的每个词项并收集文档的列里面 token。这很慢而且难以扩展:随着词项和文档的数量增加,执行时间也会增加。Solr docs对此的解释如下:

    For other features that we now commonly associate with search, such as sorting, faceting, and highlighting, this approach is not very efficient. The faceting engine, for example, must look up each term that appears in each document that will make up the result set and pull the document IDs in order to build the facet list. In Solr, this is maintained in memory, and can be slow to load (depending on the number of documents, terms, etc.)

        在lucene 4.0版本前通过FieldCache,原理是通过按列逆转倒排表将(field value ->doc)映射变成(doc -> field value)映射,问题为逐步构建时间长并且消耗大量内存,容易造成OOM。

        DocValues是一种列存储结构,能快速通过文档ID找到相关需要排序的字段。在ES中,默认开启所有(除了标记需analyzed的字符串字段)字段的doc values,如果不需要对此字段做任何排序等工作,则可关闭以减少资源消耗
      

    3.3 关于ES索引与检索分片

    ES中一个索引由一个或多个lucene索引构成,一个lucene索引由一个或多个segment构成,其中segment是最小的检索域。

    数据具体被存储到哪个分片上: shard = hash(routing) % number_of_primary_shards

    默认情况下 routing参数是文档ID (murmurhash3),可通过 URL中的 _routing 参数指定数据分布在同一个分片中,index和search的时候都需要一致才能找到数据,如果能明确根据_routing进行数据分区,则可减少分片的检索工作,以提高性能

四、优化案例

    在我们的案例中,查询字段都是固定的,不提供全文检索功能,这也是几十亿数据能秒级返回的一个大前提:

    1、ES仅提供字段的检索,仅存储HBase的Rowkey不存储实际数据。

    2、实际数据存储在HBase中,通过Rowkey查询,如下图。

    3、提高索引与检索的性能建议,可参考官方文档(如 https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html)。

     一些细节优化项官方与其他的一些文章都有描述,在此文章中仅提出一些本案例的重点优化项。

  

es百亿级数据查询,elasticsearch,lucene,全文检索

    4.1  优化索引性能

       1、批量写入,看每条数据量的大小,一般都是几百到几千。

       2、多线程写入,写入线程数一般和机器数相当,可以配多种情况,在测试环境通过Kibana观察性能曲线。

       3、增加segments的刷新时间,通过上面的原理知道,segment作为一个最小的检索单元,比如segment有50个,目的需要查10条数据,但需要从50个segment

            分别查询10条,共500条记录,再进行排序或者分数比较后,截取最前面的10条,丢弃490条。在我们的案例中将此 "refresh_interval": "-1" ,程序批量写入完成后

            进行手工刷新(调用相应的API即可)。

       4、内存分配方面,很多文章已经提到,给系统50%的内存给Lucene做文件缓存,它任务很繁重,所以ES节点的内存需要比较多(比如每个节点能配置64G以上最好)

       5、磁盘方面配置SSD,机械盘做阵列RAID5 RAID10虽然看上去很快,但是随机IO还是SSD好。

       6、 使用自动生成的ID,在我们的案例中使用自定义的KEY,也就是与HBase的ROW KEY,是为了能根据rowkey删除和更新数据,性能下降不是很明显。

       7、关于段合并,合并在后台定期执行,比较大的segment需要很长时间才能完成,为了减少对其他操作的影响(如检索),elasticsearch进行阈值限制,默认是20MB/s,

           可配置的参数:"indices.store.throttle.max_bytes_per_sec" : "200mb"  (根据磁盘性能调整)

          合并线程数默认是:Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2)),如果是机械磁盘,可以考虑设置为1:index.merge.scheduler.max_thread_count: 1,

          在我们的案例中使用SSD,配置了6个合并线程。

        

      4.2 优化检索性能

          1、关闭不需要字段的doc values。

          2、尽量使用keyword替代一些long或者int之类,term查询总比range查询好 (参考lucene说明 http://lucene.apache.org/core/7_4_0/core/org/apache/lucene/index/PointValues.html)。

          3、关闭不需要查询字段的_source功能,不将此存储仅ES中,以节省磁盘空间。

          4、评分消耗资源,如果不需要可使用filter过滤来达到关闭评分功能,score则为0,如果使用constantScoreQuery则score为1。

          5、关于分页:

               (1)from + size:  

                每分片检索结果数最大为 from + size,假设from = 20, size = 20,则每个分片需要获取20 * 20 = 400条数据,多个分片的结果在协调节点合并(假设请求的分配数为5,则结果数最大为 400*5 = 2000条) 再在内存中排序后然后20条给用户。这种机制导致越往后分页获取的代价越高,达到50000条将面临沉重的代价,默认from + size默认如下:

                index.max_result_window : 10000

                (2)  search_after:  使用前一个分页记录的最后一条来检索下一个分页记录,在我们的案例中,首先使用from+size,检索出结果后再使用search_after,在页面上我们限制了用户只能跳5页,不能跳到最后一页。

                (3)  scroll 用于大结果集查询,缺陷是需要维护scroll_id

          6、关于排序:我们增加一个long字段,它用于存储时间和ID的组合(通过移位即可),正排与倒排性能相差不明显。

          7、关于CPU消耗,检索时如果需要做排序则需要字段对比,消耗CPU比较大,如果有可能尽量分配16cores以上的CPU,具体看业务压力。

          8、关于合并被标记删除的记录,我们设置为0表示在合并的时候一定删除被标记的记录,默认应该是大于10%才删除: "merge.policy.expunge_deletes_allowed": "0"。

es百亿级数据查询,elasticsearch,lucene,全文检索

{
    "mappings": {
        "data": {
            "dynamic": "false",
            "_source": {
                "includes": ["XXX"]  -- 仅将查询结果所需的数据存储仅_source中
            },
            "properties": {
                "state": {
                    "type": "keyword",   -- 虽然state为int值,但如果不需要做范围查询,尽量使用keyword,因为int需要比keyword增加额外的消耗。
                    "doc_values": false  -- 关闭不需要字段的doc values功能,仅对需要排序,汇聚功能的字段开启。
                },
                "b": {
                    "type": "long"    -- 使用了范围查询字段,则需要用long或者int之类 (构建类似KD-trees结构)
                }
            }
        }
    },
   "settings": {......}
}

es百亿级数据查询,elasticsearch,lucene,全文检索

五、性能测试

    优化效果评估基于基准测试,如果没有基准测试无法了解是否有性能提升,在这所有的变动前做一次测试会比较好。在我们的案例中:

     1、单节点5千万到一亿的数据量测试,检查单点承受能力。

     2、集群测试1亿-30亿的数量,磁盘IO/内存/CPU/网络IO消耗如何。

     3、随机不同组合条件的检索,在各个数据量情况下表现如何。

     4、另外SSD与机械盘在测试中性能差距如何。

    性能的测试组合有很多,通常也很花时间,不过作为评测标准时间上的投入有必要,否则生产出现性能问题很难定位或不好改善。对于ES的性能研究花了不少时间,最多的关注点就是lucene的优化,能深入了解lucene原理对优化有很大的帮助。

六、生产效果

    目前平台稳定运行,百亿的数据查询100条都在3秒内返回,前后翻页很快,如果后续有性能瓶颈,可通过扩展节点分担数据压力。文章来源地址https://www.toymoban.com/news/detail-626420.html

到了这里,关于elasticsearch 百亿级数据检索案例与原理的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

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

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

相关文章

  • Elasticsearch(二)kibana数据检索

    有了数据学习使用kibana调用api检索数据,熟练kibana操作后再进一步使用spring data。 term 用于keyword类型数据 精准查询 ,类似mysql match 用于text类型数据 分词查询 ,倒排索引 首先针对keyword文本类型查询学习,类似于Mysql对字段的查询。 文档内容格式参考 结构化搜索 是指对结构

    2024年02月03日
    浏览(43)
  • Java操作Elasticsearch进行数据检索

    1.安装依赖 (注意版本要和自己安装的es版本对应)          打开发现部分依赖和我们es版本不一致,是因为springboot指定了版本,我们需要更换为自己对应版本。 1.1、改为自己es对应版本  2.编写配置类 3.配置类添加请求选项 4、测试 4.1、存储数据到es  4.2、检索数据  

    2024年02月16日
    浏览(42)
  • Langchain 与 Elasticsearch:创新数据检索的融合实战

    在信息爆炸的时代,有效地检索和处理数据变得至关重要。Langchain 和 Elasticsearch 的结合,为我们提供了一个强大的工具,以更智能的方式进行数据检索和分析。 作为一名拥有多年 Elasticsearch 实战经验的技术博主,我将在本文中详细介绍这两种技术的整合应用。 Langchain是一个

    2024年01月19日
    浏览(41)
  • 用Elasticsearch做大规模数据的多字段、多类型索引检索

    本文同时发布在我的个人博客 之前尝试了用mysql做大规模数据的检索优化,可以看到单字段检索的情况下,是可以通过各种手段做到各种类型索引快速检索的,那是一种相对简单的场景。 但是实际应用往往会复杂一些 —— 各类索引(匹配、全文检索、时间范围)混合使

    2024年04月10日
    浏览(53)
  • Smartbi助力航天百亿级遥测数据实现秒级查询

    “Smartbi全程参与了火星探测任务、中国载人空间站建设任务,为航天任务参战单位提供专业、易用、高性能的实时数据查询分析监控平台,实现航天器飞行状态监测和预警,让咱们的科研人员专注聚焦科研工作,保障航天任务顺利进行。Smartbi能为国家、能为中国的航天做一

    2024年02月07日
    浏览(39)
  • 信息检索与数据挖掘 | 【实验】排名检索模型

    在Experiment1的基础上实现最基本的Ranked retrieval model Input :a query (like Ron Weasley birthday) Output : Return the top K (e.g., K = 100) relevant tweets. Use SMART notation: lnc.ltn Document: logarithmic tf (l as first character), no idf and cosine normalization Query: logarithmic tf (l in leftmost column), idf (t in second column), no norma

    2024年02月08日
    浏览(39)
  • MySQL检索数据和排序数据

    目录 一、select语句 1.检索单个列(SELECT 列名 FROM 表名;) 2.检索多个列(SELECT 列名1,列名2,列名3  FROM 表名;)  3.检索所有的列(SELECT * FROM 表名;) 4.检索不同的行(SELECT 列名 FROM 表名;) 5.限制结果(SELECT 列名 FROM 表名 LIMIT 行数;) 6.使用完全限定的表名(SELECT 表名.列名 F

    2024年02月15日
    浏览(40)
  • AI数据技术02:RAG数据检索

            在人工智能的动态环境中,检索增强生成(RAG)已成为游戏规则的改变者,彻底改变了我们生成文本和与文本交互的方式。RAG 使用大型语言模型 (LLM) 等工具将信息检索的强大功能与自然语言生成无缝结合,为内容创建提供了一种变革性的方法。         在

    2024年02月03日
    浏览(40)
  • 【pandas基础】--数据检索

    pandas 的数据检索功能是其最基础也是最重要的功能之一。 pandas 中最常用的几种数据过滤方式如下: 行列过滤:选取指定的行或者列 条件过滤:对列的数据设置过滤条件 函数过滤:通过函数设置更加复杂的过滤条件 本篇所有示例所使用的测试数据如下: pandas 中最常用的按

    2024年02月03日
    浏览(44)
  • 深入学习MYSQL-数据检索

    前言 由于大部分基础知识都已经学过了,这里只把觉得应该记录一下的知识点做个笔记。然后以下笔记和sql均来自书籍(MYSQL必会知识),会根据看的其它书记继续调整和优化笔记。 LIMIT 注:这个平时的SQL查询没有什么区别,我主要展示一下在命令行里面怎么展示结果。 总共8条

    2024年02月05日
    浏览(35)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包