培训网站建设方案说明,上海app开发平台,网站搭建规划模板,驻马店专业做网站公司一、集群规划优化实践
1、基于目标数据量规划集群
在业务初期#xff0c;经常被问到的问题#xff0c;要几个节点的集群#xff0c;内存、CPU要多大#xff0c;要不要SSD#xff1f;
最主要的考虑点是#xff1a;你的目标存储数据量是多大#xff1f;可以针对目标数据…一、集群规划优化实践
1、基于目标数据量规划集群
在业务初期经常被问到的问题要几个节点的集群内存、CPU要多大要不要SSD
最主要的考虑点是你的目标存储数据量是多大可以针对目标数据量反推节点多少。
2、要留出容量Buffer
注意Elasticsearch有三个警戒水位线磁盘使用率达到85%、90%、95%。
不同警戒水位线会有不同的应急处理策略。这点在磁盘容量选型中要规划在内。控制在85%之下是合理的。
当然也可以通过配置做调整。
3、ES集群各节点尽量不要和其他业务功能共用一台机器
除非内存非常大。举例普通服务器安装了ESMysqlredis业务数据量大了之后势必会出现内存不足等问题。
4、磁盘尽量选择SSD
Elasticsearch官方文档推荐SSD考虑到成本的原因需要结合业务场景。
如果业务对写入、检索速率有较高的速率要求建议使用SSD磁盘。
阿里的业务场景SSD磁盘比机械硬盘的速率提升了5倍。
5、内存配置要合理
对内存的大小官方建议是Min32GB机器内存大小/2。
Medcl和wood大叔都有明确说过不必要设置32/31GB那么大建议热数据设置26GB冷数据31GB。
总体内存大小没有具体要求但肯定是内容越大检索性能越好。
经验值供参考每天200GB增量数据的业务场景服务器至少要64GB内存。除了JVM之外的预留内存要充足否则也会经常OOMOutOfMemoryError。
6、CPU核数不要太小
CPU核数是和ES Thread pool关联的。和写入、检索性能都有关联。
建议16核
7、超大量级的业务场景可以考虑跨集群检索
除非业务量级非常大例如滴滴、携程的PB的业务场景否则基本不太需要跨集群检索。
8、集群节点个数无需奇数
ES内部维护集群通信不是基于zookeeper的分发部署机制所以无需奇数。
但是discovery.zen.minimum_master_nodes的值要设置为候选主节点的个数/21才能有效避免脑裂。
9、节点类型优化分配
集群节点数3建议所有节点的mastertrue datatrue。既是主节点也是路由节点。
集群节点数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_queryforce_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、分页深度查询和遍历
分页查询使用fromsize;
遍历使用scroll
并行遍历使用scrollslice。
斟酌集合业务选型使用。
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性能调优 - 搜索客搜索人自己的社区
社区如何解决ES的性能问题 - 搜索客搜索人自己的社区
社区Day 16 - Elasticsearch性能调优 - 搜索客搜索人自己的社区
