关于ElasticSearch,你应该知道的

这篇具有很好参考价值的文章主要介绍了关于ElasticSearch,你应该知道的。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、集群规划优化实践
1、基于目标数据量规划集群

在业务初期,经常被问到的问题,要几个节点的集群,内存、CPU要多大,要不要SSD?

最主要的考虑点是:你的目标存储数据量是多大?可以针对目标数据量反推节点多少。

2、要留出容量Buffer

注意:Elasticsearch有三个警戒水位线,磁盘使用率达到85%、90%、95%。

不同警戒水位线会有不同的应急处理策略。这点在磁盘容量选型中要规划在内。控制在85%之下是合理的。

当然,也可以通过配置做调整。

3、ES集群各节点尽量不要和其他业务功能共用一台机器

除非内存非常大。举例:普通服务器,安装了ES+Mysql+redis,业务数据量大了之后,势必会出现内存不足等问题。

4、磁盘尽量选择SSD

Elasticsearch官方文档推荐SSD,考虑到成本的原因,需要结合业务场景。

如果业务对写入、检索速率有较高的速率要求,建议使用SSD磁盘。

阿里的业务场景,SSD磁盘比机械硬盘的速率提升了5倍。

5、内存配置要合理

对内存的大小,官方建议是:Min(32GB,机器内存大小/2)。

Medcl和wood大叔都有明确说过,不必要设置32/31GB那么大,建议:热数据设置:26GB,冷数据:31GB。

总体内存大小没有具体要求,但肯定是内容越大,检索性能越好。

经验值供参考:每天200GB+增量数据的业务场景,服务器至少要64GB内存。除了JVM之外的预留内存要充足,否则也会经常OOM(OutOfMemoryError)。

6、CPU核数不要太小

CPU核数是和ES Thread pool关联的。和写入、检索性能都有关联。

建议:16核+

7、超大量级的业务场景,可以考虑跨集群检索

除非业务量级非常大,例如:滴滴、携程的PB+的业务场景,否则基本不太需要跨集群检索。

8、集群节点个数无需奇数

ES内部维护集群通信,不是基于zookeeper的分发部署机制,所以,无需奇数。

但是discovery.zen.minimum_master_nodes的值要设置为:候选主节点的个数/2+1,才能有效避免脑裂。

9、节点类型优化分配

集群节点数:<=3,建议:所有节点的master:true, data:true。既是主节点也是路由节点。

集群节点数:>3, 根据业务场景需要,建议:逐步独立出Master节点和协调/路由节点。

10、建议冷热数据分离

热数据存储SSD,普通历史数据存储机械磁盘,物理上提高检索效率。

 

二、建议冷热数据分离

Mysql等关系型数据库要分库、分表。Elasticserach的话也要做好充分的考虑。

1、设置多少个索引?

建议根据业务场景进行存储。

不同通道类型的数据要分索引存储。举例:知乎采集信息存储到知乎索引;APP采集信息存储到APP索引。

2、设置多少分片?

建议根据数据量衡量。

经验值:建议每个分片大小不要超过30GB。

3、分片数设置?

建议根据集群节点的个数规模,分片个数建议>=集群节点的个数。

5节点的集群,5个分片就比较合理。

注意:除非reindex操作,分片数是不可以修改的。

4、副本数设置?

除非你对系统的健壮性有异常高的要求,比如:银行系统。可以考虑2个副本以上。否则,1个副本足够。

注意:副本数是可以通过配置随时修改的。

5、不要再在一个索引下创建多个type

一个索引对应一个type

6、按照日期规划索引

随着业务量的增加,单一索引和数据量激增带来的矛盾凸显。按照日期规划索引是必然选择。

好处1:可以实现历史数据秒删。对历史索引delete即可。注意:一个索引的话需要借助delete_by_query+force_merge操作,慢且删除不彻底。

好处2:便于冷热数据分开管理,检索最近几天的数据,直接物理上指定对应日期的索引,速度快的一逼!

操作参考:模板使用+rollover API使用。

7、务必使用别名

ES不像mysql能够方便的更改索引名称,使用别名是一个相对灵活的选择。

 

三、数据模型优化实践
1、不要使用默认的Mapping

默认Mapping的字段类型是系统自动识别的。其中:string类型默认分成:text和keyword两种类型。如果你的业务中不需要分词、检索,仅需要精确匹配,仅设置为keyword即可。

根据业务需要选择合适的类型,有利于节省空间和提升精度,如:浮点型的选择。

 

2、Mapping各字段的选型流程
3、选择合理的分词器

常见的开源中文分词器包括:ik分词器、ansj分词器、hanlp分词器、结巴分词器、海量分词器、“ElasticSearch最全分词器比较及使用方法” 搜索可查看对比效果。

如果选择ik,建议使用ik_max_word。因为:粗粒度的分词结果基本包含细粒度ik_smart的结果。

4、date、long、还是keyword

根据业务需要,如果需要基于时间轴做分析,必须date类型;

如果仅需要秒级返回,建议使用keyword。

 

四、数据写入优化实践
1、要不要秒级响应?

Elasticsearch近实时的本质是:最快1s写入的数据可以被查询到。

如果refresh_interval设置为1s,势必会产生大量的segment,检索性能会受到影响。

所以,非实时的场景可以调大,设置为30s,甚至-1。

2、减少副本,提升写入性能

写入前,副本数设置为0,

写入后,副本数设置为原来值。

3、能批量就不单条写入

批量接口为bulk,批量的大小要结合队列的大小,而队列大小和线程池大小、机器的cpu核数相关

4、禁用swap

在Linux系统上,通过运行以下命令临时禁用交换:

sudo swapoff -a

 

五、检索聚合优化实践
1、禁用 wildcard模糊匹配

数据量级达到TB+甚至更高之后,wildcard在多字段组合的情况下很容易出现卡死,甚至导致集群节点崩溃宕机的情况。后果不堪设想。

替代方案:

方案一:针对精确度要求高的方案:两套分词器结合,standard和ik结合,使用match_phrase检索。

方案二:针对精确度要求不高的替代方案:建议ik分词,通过match_phrase和slop结合查询。

2、极小的概率使用match匹配

中文match匹配显然结果是不准确的。很大的业务场景会使用短语匹配“match_phrase"。

match_phrase结合合理的分词词典、词库,会使得搜索结果精确度更高,避免噪音数据。

3、结合业务场景,大量使用filter过滤器

对于不需要使用计算相关度评分的场景,无疑filter缓存机制会使得检索更快。

举例:过滤某邮编号码。

4、控制返回字段和结果

和mysql查询一样,业务开发中,select * 操作几乎是不必须的。同理ES中,_source 返回全部字段也是非必须的。

要通过_source 控制字段的返回,只返回业务相关的字段。

网页正文content,网页快照html_content类似字段的批量返回,可能就是业务上的设计缺陷。

显然,摘要字段应该提前写入,而不是查询content后再截取处理。

5、分页深度查询和遍历

分页查询使用:from+size;

遍历使用:scroll;

并行遍历使用:scroll+slice。

斟酌集合业务选型使用。

6、聚合Size的合理设置

聚合结果是不精确的。除非你设置size为2的32次幂-1,否则聚合的结果是取每个分片的Top size元素后综合排序后的值。

实际业务场景要求精确反馈结果的要注意。

尽量不要获取全量聚合结果——从业务层面取TopN聚合结果值是非常合理的。因为的确排序靠后的结果值意义不大。

7、聚合分页合理实现

聚合结果展示时,势必面临聚合后分页的问题,而ES官方基于性能原因不支持聚合后分页。

如果需要聚合后分页,需要自行开发实现。包含但不限于:

方案一:每次取聚合结果,拿到内存中分页返回。

方案二:scroll结合scroll after集合redis实现。

 

六、业务优化

让Elasticsearch做它擅长的事情,很显然,它更擅长基于倒排索引进行搜索。

业务层面,用户想最快速度看到自己想要的结果,中间的“字段处理、格式化、标准化”等一堆操作,用户是不关注的。

为了让Elasticsearch更高效的检索,建议:

1、要做足“前戏”

字段抽取、倾向性分析、分类/聚类、相关性判定放在写入ES之前的ETL阶段;

2、“睡服”产品经理

产品经理基于各种奇葩业务场景可能会提各种无理需求。

作为技术人员,要“通知以情晓之以理”,给产品经理讲解明白搜索引擎的原理、Elasticsearch的原理,哪些能做,哪些真的“臣妾做不到”。

3、总结

实际业务开发中,公司一般要求又想马儿不吃草,又想马儿飞快跑。

对于Elasticsearch开发也是,硬件资源不足(cpu、内存、磁盘都爆满)几乎没有办法提升性能的。

除了检索聚合,让Elasticsearch做N多相关、不相干的工作,然后得出结论“Elastic也就那样慢,没有想像的快”。

你脑海中是否也有类似的场景浮现呢?

提供相对NB的硬件资源、做好前期的各种准备工作、让Elasticsearch轻装上阵,相信你的Elasticsearch也会飞起来!

 

七、推荐阅读:

阿里:Day 4 - PB级规模数据的Elasticsearch分库分表实践 - 搜索客,搜索人自己的社区

滴滴:滴滴Elasticsearch多集群架构实践

腾讯:陈曦:性能与稳定并存 Elasticsearch调优实践

携程:Day 17 - 关于日志型数据管理策略的思考 - 搜索客,搜索人自己的社区

社区:Day 16 - Elasticsearch性能调优 - 搜索客,搜索人自己的社区文章来源地址https://www.toymoban.com/news/detail-817575.html

社区:如何解决ES的性能问题 - 搜索客,搜索人自己的社区

社区:Day 16 - Elasticsearch性能调优 - 搜索客,搜索人自己的社区

到了这里,关于关于ElasticSearch,你应该知道的的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

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

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

相关文章

  • 搜索引擎(大数据检索)论述[elasticsearch原理相关]

    首先需要大致知道搜索引擎有大致几类:1.全文搜索引擎 2.垂直搜索引擎 3.类目搜索引擎等。 1.全文搜索引擎:是全文本覆盖的,百度,google等都是全文本搜索,就是我搜一个词项“方圆”,那么这个词项可以是数字平方的概念,可以是一个人名,可以是一首歌等,所有的相

    2023年04月08日
    浏览(52)
  • 基于Elasticsearch与Hbase组合框架的大数据搜索引擎

    本项目为学校大数据工程实训项目,共开发4周,答辩成绩不错。代码仓库放文章尾,写的不好,代码仅供参考。 对于结构化数据 ,因为它们具有特定的结构,所以我们一般都是可以通过关系型数据库(MySQL,Oracle 等)的二维表(Table)的方式存储和搜索,也可以建立索引。

    2024年02月09日
    浏览(63)
  • Elasticsearch (ES) 搜索引擎: 数据类型、动态映射、多类型(子字段)

    原文链接:https://xiets.blog.csdn.net/article/details/132348634 版权声明:原创文章禁止转载 专栏目录:Elasticsearch 专栏(总目录) ES 映射字段的 数据类型 ,官网文档参考:Field data types。 下面是 ES 常用的一些基本数据类型。 字符串 类型: keyword :类型。 text :文本类型。

    2024年03月23日
    浏览(63)
  • 【C++】关于多线程,你应该知道这些

    thread类的简单介绍 在 C++11 之前,涉及到多线程问题,都是和平台相关的,比如 Windows 和 Linux 下各有自己的接口,这使得代码的可移植性比较差。C++11 中最重要的特性就是对线程进行支持了,使得 C++ 在并行编程时不需要依赖第三方库,而且在原子操作中还引入了原子类的概

    2023年04月15日
    浏览(48)
  • 【算法】关于排序你应该知道的一切(下)

    和光同尘_我的个人主页 单程孤舟,出云入霞,如歌如吟。 --门孔 啊还是国庆快乐!上节介绍了较为简单的插入排序、选择排序,今天我们上强度,学习交换排序、归并排序还有计数排序,开冲😎 2.1.1. 基本思想 关于冒泡排序我们在C语言的学习中就有涉及 依次比较序列中相

    2024年02月07日
    浏览(43)
  • 【算法】关于排序你应该知道的一切(上)

    和光同尘_我的个人主页 单程孤舟,出云入霞,如歌如吟。 --门孔 国庆快乐!!本来想把排序都做到一起的,才写了一半就八千多字了,那就分开发吧,一如既往的详细哦⌨️ 排序 :所谓排序,就是使一串记录,按照其中的某个或某些的大小,递增或递减的排列起来

    2024年02月06日
    浏览(35)
  • elasticsearch(ES)分布式搜索引擎04——(数据聚合,自动补全,数据同步,ES集群)

    **聚合(aggregations)**可以让我们极其方便的实现对数据的统计、分析、运算。例如: 什么品牌的手机最受欢迎? 这些手机的平均价格、最高价格、最低价格? 这些手机每月的销售情况如何? 实现这些统计功能的比数据库的sql要方便的多,而且查询速度非常快,可以实现近

    2024年02月08日
    浏览(47)
  • 微服务04 分布式搜索引擎 elasticsearch DSL数据聚合 自动补全 数据同步 集群 Sentinel

    聚合(aggregations)可以让我们极其 方便的实现对数据的统计、分析、运算 。例如: 什么品牌的手机最受欢迎? 这些手机的平均价格、最高价格、最低价格? 这些手机每月的销售情况如何? 实现这些 统计功能的比数据库的sql要方便的多,而且查询速度非常快 ,可以实现近

    2024年02月11日
    浏览(49)
  • 《Spring Boot 实战派》--13.集成NoSQL数据库,实现Elasticsearch和Solr搜索引擎

             关于搜索引擎 我们很难实现 Elasticseach 和 Solr两大搜索框架的效果;所以本章针对两大搜索框架,非常详细地讲解 它们的原理和具体使用方法, 首先 介绍什么是搜索引擎 、如何用 MySQL实现简单的搜索引擎,以及Elasticseach 的 概念和接口类; 然后介绍Elasticseach

    2023年04月09日
    浏览(88)
  • 微服务04 分布式搜索引擎 elasticsearch DSL数据聚合 自动补全 数据同步 集群 微服务保护 Sentinel

    聚合(aggregations)可以让我们极其 方便的实现对数据的统计、分析、运算 。例如: 什么品牌的手机最受欢迎? 这些手机的平均价格、最高价格、最低价格? 这些手机每月的销售情况如何? 实现这些 统计功能的比数据库的sql要方便的多,而且查询速度非常快 ,可以实现近

    2024年02月15日
    浏览(53)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包