潮人地东莞seo博客小编下面跟大家分享关于seo优化技术：如何看待这种快照秒收方式-让Elasticsearch飞起来（性能优化实践干货）等问题，希望seo专员在做seo优化的过程中有所帮助，内容仅供参考。
让Elasticsearch飞起来-性能优化实践干货
0、题记
Elasticsearch性能优化的最终目的:用户体验酷。
关于酷的定义——著名产品人梁宁曾经说过：“当人们满意时，他们的状态被称为快乐。如果人们不满意，他们就会感到不舒服，并开始寻求。如果这个人能在寻找中立即得到满足，这种感觉就很酷了！”。
Elasticsearch的爽点是:快、准、全！
seo博客相关推荐阅读：seo技术博客分享：网站有那几种地方需要优化，如何做
阿里巴巴、腾讯、JD.COM、携程、滴滴、58等都对Elasticsearch的性能优化做了很多深入的实践总结，都是很好的参考。本文以Elasticsearch的酷点为基础，对性能优化进行了探讨。
1、集群规划优化实践1.1基于目标数据量规划集群
在业务初期，经常被问到的问题需要几个节点的集群，内存和CPU需要多少，SSD需要多少？
最重要的考虑因素是：您的目标存储数据量是多少？针对目标数据量可以反推多少节点。
1.2留出容量Buffer
注：Elasticsearch有三条警戒水位线，磁盘利用率达到85%、90%、95%。
不同的警戒水位线会有不同的应急策略。
在这一点上，应规划磁盘容量选择。控制在85%以下是合理的。
当然，也可以通过配置进行调整。
1.3ES集群各节点尽量不要与其他业务功能重用一台机器。
除非内存很大。
例如，ES安装在普通服务器上 Mysql redis，业务数据量大后，必然会出现内存不足等问题。
1.4磁盘尽量选择SSDD
考虑到成本原因，Elasticsearch的官方文件必须推荐SSD。需要结合业务场景，
如果业务对写入和检索速率有较高的速率要求，建议使用SSD磁盘。
在阿里的业务场景中，SSD磁盘的速率是机械硬盘的5倍。
但因商业场景而异。
1.5内存配置合理
官方建议：堆内存的大小是官方建议：Min(32GB，机器内存大小/2)。
Medcl和wood大叔都明确表示，不需要设置32/31GB那么大，建议:热数据设置:26GB，冷数据:31GB。
整体内存大小没有具体要求，但内容越大，检索性能越好。
经验值供参考：每天200GB 在增量数据的业务场景中，服务器至少需要64GB内存。
除JVM外，还要有足够的预留内存，否则OOM往往会出现。
1.6CPU核数不要太小
CPU核数与ESThreadpol有关。它与写入和检索性能有关。
建议：16核 。
1.7超大量业务场景，可考虑跨集群检索
除非业务量级很大，比如滴滴和携程的PB 业务场景，否则基本不需要跨集群检索。
1.8集群节点数不需要奇数
ES内部维护集群通信不是基于zookeeper的分发部署机制，所以不需要奇数。
但是discovery.zen.minimum_master_nodes的值应设置为：候选主节点的数量/2 1、能有效避免脑裂。
1.9节点类型优化分配
集群节点数：<=3，建议：所有节点的master：true，data：true。既是主节点也是路由节点。集群节点数：>3.根据业务场景的需要，建议Master节点和协调/路由节点逐步独立。
1.10建议冷热数据分离
物理上提高了热数据存储SSD和普通历史数据存储机械磁盘的检索效率。
2、索引优化实践
Mysql等关系数据库要分库、分表。Elasticserach也要充分考虑。
2.1设置多少个索引？
建议根据业务场景进行存储。
不同渠道类型的数据应分为索引存储。例如：知乎采集信息存储到知乎索引；APP采集信息存储到APP索引。
2.2设置多少分片？
建议根据数据量进行测量。
经验值：建议每片尺寸不超过30GB。
2.3分片数设置？
建议根据集群节点的数量规模，建议>=集群节点的数量。
5个节点的集群，5个分片比较合理。
注：除非reindex操作，否则不能修改分片数。
2.4副本数设置？
除非你对系统的健壮性有很高的要求，比如银行系统。可以考虑两份以上。
否则，一个副本就足够了。
注：可通过配置随时修改副本数。
2.5不要在一个索引下创建多个type
即便你是5.考虑到未来版本升级等后续可扩展性，X版本。
建议:一个索引对应一个type。
6.默认对应_xxdoc，5.x您直接对应type统一为doc。
2.6根据日期规划索引索引
随着业务量的增加，单一索引与数据量激增的矛盾突出。
按日期规划索引是必然选择。
好处1：历史数据可以在几秒钟内删除。非常适合历史索引delete。注：如果索引需要使用delete_by_query force_merge操作慢，删除不彻底。
好处2：便于冷热数据的单独管理，检索近几天的数据，直接物理指定相应日期的索引，速度快！
操作参考：模板使用 使用rolloverAPI。
2.7必须使用别名
与mysql不同，ES更改索引名称。使用别名是一个相对灵活的选择。
3、优化实践的数据模型3.1不要使用默认的Mapping
默认Mapping的字段类型由系统自动识别。其中，string类型默认分为两种类型：text和keyword。如果您的业务不需要单词分割和搜索，只需要准确匹配，只设置为keyword。
根据业务需要选择合适的类型，有利于节省空间，提高精度，如浮点型的选择。
3.2Mapping各字段的选择流程3.3选择合理的分词器
常见的开源中文分词器包括：ik分词器、ansj分词器、hanlp分词器、结巴分词器、海量分词器、“elasticsearch最全分词器比较及使用方法”搜索可查看比较效果。
如果选择ik，建议使用ik_max_word。因为粗粒度的分词结果基本上包括细粒度ik_smart的结果。
3.4date、long、还是keyword
根据业务需要，如果需要根据时间轴进行分析，则必须进行date类型；
如果只需要秒返回，建议使用常州网站seo优化推广优化keyword。
4、数据写入优化实践4.1要不要秒级响应？
Elasticsearch近实时的本质是：最快1s写入的数据可以查询。
如果refresh_interval设置为1s，必然会产生大量的segment，影响检索性能。
因此，可以将非实时场景调大，设置为30s甚至-1。
4.2减少副本，提高写入性能。
写入前，副本数设置为0，
写入后，将副本数设置为原始值。
4.3能量批量不单条写入
批量接口为bulk，批量尺寸应与队列尺寸相结合，而队列尺寸、线程池尺寸、机器cpu核数。
4.4禁用swap
在Linux系统中，通过运行以下命令暂时禁用交换：
sudoswapofff-a
5、实战检索聚合优化5.1禁用wildcard模糊匹配
达到TB的数据量级 甚至更高之后，wildcard在多字段组合的情况下很容易卡死，甚至导致集群节点崩溃停机。
后果不堪设想。
替代方案：
方案1:对于精度要求高的方案:两套分词器、standard和ik的组合，使用match_phrase进行检索。
方案二:对于精度要求低的替代方案:建议通过match_phrase和slop查询ik分词。
5.2使用match匹配极小概率的概率
显然，中文match匹配的结果是不准确的。短语匹配将用于大型商业场景。”match_phrase"。
match_phrase结合合理的分词词典和词库，会使搜索结果更加准确，避免噪音数据。
5.3结合业务场景，大量使用filter过滤器
filter缓存机制无疑会使检索更快，而不需要使用计算相关评分的场景。
例如：过滤邮编号。
5.4控制返回字段和结果
和mysql查询一样，在业务开发中，select*操作几乎是不必要的。
同理，在ES中，_sourc崇义seo网站优化e返回所有字段也是不必要的。
通过_source控制字段的返回，只返回与业务相关的字段。
网页文本content，网页快照html_content类似字段的批量返回，可能是业务设计缺陷。
显然，摘要字段应提前写入，而不是在截取处理之前查询content。
5.5分页深度查询和遍历
使用分页查询：from size;
遍历使用：scroll；
并行遍历使用：scroll slice。
考虑集合业务的选择和使用。
5.6合理设置聚合Size
聚合结果是不准确的。除非你把size设置为2的32次幂-1，否则聚合结果是取每个片段的topsize元素后综合排序的值。
实际业务场景需要注意准确的反馈结果。
尽量不要获得全聚合结果——从业务层面获得Topn聚合结果值是非常合理的。因为排名靠后的结果值意义不大。
合理实现5.7聚合分页
当显示聚合结果时，聚合后分页必然会面临问题，ES官员不支持聚合后分页，因为性能原因。
若需要聚合后分页，则需要自开发实现。包括但不限于:
方案一:每次取聚合结果，获取内存中分页返回。
方案二：scrolll结合scrollafter集合redis实现。
6、业务优化
让Elasticsearch做它擅长的事情，显然，它更擅长基于倒排索引进行搜索。
建议Elasticsearch更有效地检索：
1)要做好“前戏”
在写入ES之前的ETL阶段，将字段提取、倾向分析、分类/聚类、相关性判断放在ETL阶段；
2)“睡衣”产品经理
基于各种奇妙的业务场景，产品经理可能会提出各种不合理的需求。
作为一名技术人员，我们应该“通知理性”，向产品经理解释搜索引擎的原理，Elasticsearch的原理，什么可以做，什么真正的“妾不能做”。
7、小结
在实际的业务发展中，公司一般要求马不吃草，想马快跑。
Elasticsearch开发也是如此，硬件资源不足（cpu、几乎没有办法提高内存和磁盘的性能。
除了检索聚合，让Elasticsearch做N多相关和不相关的工作，然后得出结论，“Elastic太慢了，没有想象的那么快”。
类似的场景也出现在你的脑海里吗？
提供相对NB的硬件资源，做好各种前期准seo网站关键词优化乚品达备，让Elasticsearch轻装上阵，相信你的Elasticsearch也会飞起来！
以上是潮人地东莞seo博客跟大家分享关于seo优化技术：如何看待这种快照秒收方式-让Elasticsearch飞起来（性能优化实践干货）等问题，希望能对大家有所帮助，若有不足之处，请谅解，我们大家可以一起讨论关于网站seo优化排名的技巧，一起学习，以上内容仅供参考。
