资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/Elasticsearch 最佳实践

Elasticsearch 最佳实践

IT那活儿 / 2504人阅读
Elasticsearch 最佳实践

点击上方“IT那活儿”，关注后了解更多内容，不管IT什么活儿，干就完了！！！

Elasticsearch是一个基于Apache Lucene的开源搜索引擎。无论在开源还是专有领域，Lucene可以被认为是迄今为止最先进、性能最好的、功能最全的搜索引擎库。
它有如下特点：
  • 分布式的实时文件存储，每个字段都被索引并可被搜索；
  • 分布式的实时分析搜索引擎--做不规则查询；
  • 可以扩展到上百台服务器，处理PB级结构化或非结构化数据。
生产环境的elasticsearch安装是一个多节点的集群模式，一个节点(node)就是一个Elasticsearch实例，而一个集群(cluster)由一个或多个节点组成，它们具有相同的cluster.name，它们协同工作，分享数据和负载。
本文将自底向上的逐步推荐所谓的“最佳实践”配置，毕竟抛开业务场景数据量等因素谈所谓的“最佳实践”其实都是耍流氓。但如果你对elasticsearch集群所需承载的业务或数据规模不是很清楚的时候，按本文比较常用的设置来安装集群，是可以满足绝大多数的应用场景的，本文所谓的“最佳实践”也是基于此。



1. 节点数量
elasticsearch一般是用于构建业务的搜索需求，而且是垂直领域的搜索，在数据量横跨几千万到数十亿的级别的场景下，一般3-6台的节点规模是安全的节点数量。
当用于大规模数据的实时OLAP（统计处理分析），比如elk stack和BI等，数据规模可能会达到千亿甚至更多，此时我们elasticsearch的集群数量可能就会需要几十上百台的规模才能满足了。
综上，同时考虑我们elasticsearch集群拥有足够优秀的横向扩展能力，所以我们在安装elasticsearch集群时，可以使用5节点集群，当业务扩展性能瓶颈时，我们可以对集群进行扩容，增加节点数量。



2. 服务器硬件
CPU: 大多数的ES集群对cpu的要求并不高，一般当前时期服务器市场上中等甚至中等偏低的CPU都能满足。
内存：ES对内存要求较高，主要不是吃JVM内存，而是OS cache，ES会将频繁访问的一些数据缓存在操作系统内存中，以达到较高的访问效率，推荐机器内存64G+。
磁盘：推荐使用SSD或者使用本地SAS盘或SATA盘存储，转速越高越好，磁盘选型可以在性能和成本因素中综合考量，如对性能要求不十分苛刻的情况下，推荐使用廉价经济的SATA盘，容量可以依据数据规划来存储（规划方法见本条下方），如无规划，推荐使用2T-4T的SATA盘。
切记不要给ES使用NAS盘。
综上，我们建议使用同时期的主流中等配置的机器，不建议使用过于强劲的硬件配置，不建议在一台服务器上运行多个节点，因为一旦一台服务器产生故障，会对集群产生比较大的影响，恢复的速度也会更慢。
（数据规划方法：常用的经验计算法为磁盘容量大小=原始数据大小*3.38。也即假设一条文档数据1k，预计数据量有10亿条，那么会有100G的原始数据大小，磁盘占用预计是300G）。



3. 网络
推荐单个集群不要跨数据中心进行部署（不要使用WAN），节点之间的hops越少越好。
如果有多块网卡，最好将transport和 http绑定到不同的网卡，并设置不同的防火墙Rules，按需为Coordinating Node 或 Ingest Node配置负载均衡。



4. 集群角色规划
一个节点node可以充当一个或多个角色，默认配置是三个角色（master节点、协调节点、数据节点）都有。
协调节点即凡是接收客户端请求处理的默认就是协调节点，如果集群的负载较重时，可以将协调节点多带带抽取出来作为独立角色部署。
一般我们将10节点作为小规模和中等规模分界点，一般小规模集群（小于10节点），我们无需严格进行区分，混合部署就可以了。中大规模集群（超过10节点甚至更多），则应该考虑多带带的角色，一般一台服务器只部署一个node，当并发查询量过大时，考虑增加独立的协调节点。角色分开的好处是分工分开，互不影响。



5. 堆内存设置及优化建议
5.1 堆内存设置
不要超过 32 GB，如果服务器内存充足，可以设置为32G。
堆对于Elasticsearch绝对重要，它被许多内存数据结构用来提供快速操作。
但还有另外一个非常重要的内存使用者：Lucene。
Lucene旨在利用底层操作系统来缓存内存中的数据结构。Lucene段(segment)存储在单个文件中。因为段是一成不变的，所以这些文件永远不会改变。这使得它们非常容易缓存，并且底层操作系统将愉快地将热段（hot segments）保留在内存中以便更快地访问。这些段包括倒排索引（用于全文搜索）和文档值（用于聚合）。
Lucene的性能依赖于与操作系统的这种交互。但是如果你把所有可用的内存都给了Elasticsearch的堆，那么Lucene就不会有任何剩余的内存。这会严重影响性能。
标准建议是将可用内存的50％提供给Elasticsearch堆，而将其他50％空闲。它不会被闲置; Lucene会高兴地吞噬掉剩下的东西。
JVM设定:
从ES 6开始，只支持64位的JVM，配置config/jvm.options，将内存Xms和Xmx设置成一样，避免heap resize时引发停顿。
5.2 堆内存优化建议
1）最好的办法是在系统上完全禁用交换。
可以暂时用如下命令完成：
若要永久禁用它，需要在/etc/fstab中设置。
2）控制操作系统尝试交换内存的积极性。
如果完全禁用交换不是一种选择，可以尝试降低swappiness。该值控制操作系统尝试交换内存的积极性。这可以防止在正常情况下交换，但仍然允许操作系统在紧急内存情况下进行交换。
对于大多数Linux系统，这是使用sysctl值配置的：
vm.swappiness = 1
注意：1的swappiness优于0，因为在某些内核版本上，swappiness为0可以调用OOM杀手。
3）mlockall允许JVM锁定其内存并防止其被操作系统交换。
最后，如果两种方法都不可行，则应启用mlockall文件。这允许JVM锁定其内存并防止其被操作系统交换。在elasticsearch.yml中，设置这个：



6. 数据目录设置
数据目录可以在配置中本地指定多个“path.data”，以支持使用多块磁盘，如
path.data：/data01/es,/data02/es,/data03/es,/data04/es,/data05/es,/data06/es
因ES本身提供了很好的HA机制，所以我们无需对数据盘使用任何的RAID 1/5/10等冗余措施。
我们可以在Warm节点上使用Spinning Disk，但是需要关闭Concurrent Merges Index.merge.scheduler.max_thread_count: 1。



7. 索引设计
业务的索引设计至关重要一般要根据业务的场景来决定核心是要避免单个TB级甚至PB级的索引，大索引一般要进行拆分到GB级别，比如海量的日志场景可以采用Template+rollover+curator滚动创建索引，动态使用后的效果如下：
具体操作就是在索引模板的设计阶段，定义一个全局变量名：用途是全局检索，比如test_sms，每次更新到新的索引后，新索引指向一个用于实时新数据写入的别名test_sms_2022.03.05，同时将旧索引的别名test_sms_2022.03.01移除。然后再通过curator按照日期定期删除，归档历史数据。



8. 分片及副本设置
合理的建议：每个分片数据大小：30GB-50GB
分片是 Elasticsearch 在集群内分发数据的单位。集群发生故障再恢复平衡的速度取决于分片的大小、分片数量、网络以及磁盘性能。
在 Elasticsearch 中，每个查询在每个分片的单个线程中执行。但是，可以并行处理多个分片。针对同一分片的多个查询和聚合也可以并行处理。
这意味着在不涉及缓存的情况下，最小查询延迟将取决于数据、查询类型以及分片的大小三个因素。
8.1 查询很多小分片vs查询少量大分片
查询很多小分片，导致每个分片能做到快速响应，但是由于需要按顺序排队和处理结果汇集。因此不一定比查询少量的大分片快。
如果存在多个并发查询，那么拥有大量小分片也会降低查询吞吐量。
8.2 分片数设定
选择正确数量的分片是一个复杂问题，因为在集群规划阶段以及在数据写入开始之前，一般不能确切知道文档数。
对于集群而言，分片数多了以后，索引和分片管理可能会使主节点超载，并可能会导致集群无响应，甚至导致集群宕机。
建议：为主节点（Master 节点）分配足够的资源以应对分片数过多可能导致的问题。
必须强调的是：主分片数是在索引创建时定义的，不支持借助 update API 实现类副本数更新的动态修改。创建索引后，更改主分片数的唯一方法是重新创建索引，然后将原来索引数据 reindex 到新索引。
所以官方给出的合理的建议：每个分片数据大小：30GB-50GB
8.3 副本设置
Elasticsearch 通过副本实现集群的高可用性，数据在数据节点之间复制，以实现主分片数据的备份，因此即便部分节点因异常下线也不会导致数据丢失。
默认情况下，副本数为 1，但可以根据产品高可用要求将其增加。副本越多，数据的容灾性越高。
副本多的另一个优点是，每个节点都拥有一个副本分片，有助于提升查询性能。
建议：根据业务实际综合考虑设置副本数。普通业务场景（非精准高可用）副本设置为 1 足够了。
修改索引副本数：
PUT index/_settings
{
   "number_of_replicas": 1
}
查看索引分片：
GET index/_settings



9. 冷热集群架构配置
根据产品业务数据特定和需求，我们可以将数据分为热数据和冷数据，这是冷热集群架构的前提。
访问频率更高的索引可以分配更多更高配（如：SSD）的数据节点，而访问频率较低的索引可以分配低配（如：机械磁盘）数据节点。
冷热集群架构对于存储诸如应用程序日志或互联网实时采集数据（基于时间序列数据）特别有用。
数据迁移策略：通过运行定时任务来实现定期将索引移动到不同类型的节点。具体实现为使用curator工具或借助ILM 索引生命周期管理。



10. 集群安全设定
为Elasticsearch和 Kibana 配置安全功能，打开Authentication & Authorization，实现索引和和字段级的安全控制，节点间通信加密，Enable HTTPS，Audit logs。



11. 慢日志
慢日志的目的是捕获那些超过指定时间阈值的查询和索引请求。这个日志用来追踪由用户产生的很慢的请求很有用。
默认情况，慢日志是不开启的。要开启它，需要定义具体动作（query，fetch 还是 index），期望的事件记录等级（ WARN 、 DEBUG 等），以及时间阈值。这是一个索引级别的设置，也就是说可以独立应用给单个索引：
也可以在 elasticsearch.yml 文件里定义这些阈值。没有阈值设置的索引会自动继承在静态配置文件里配置的参数。一旦阈值设置过了，你可以和其他日志器一样切换日志记录等级：


本文作者：何  青

本文来源：IT那活儿（上海新炬王翦团队）

​​​
GPU云服务器 云服务器 最佳实践 webrtc最佳实践 cdn最佳实践 vpc最佳实践

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/129558.html

相关文章

  • FastD 最佳实践五: 构建ELK日志分析

    摘要：点击前往中文地址先决条件简单安装下载地址下载或者其他都可以。版本处理方案新建格式日志文件。配置日志会随着配置进行生成，结果如下忽略上述日志内容，程序看得懂即可配置推送到需要根据业务场景进行配置，现在显示最简单的配置。 过去咱们开发中，对日志这个环节其实并不太重视，直到有一天，应用出现异常，这个时候才想起来日志，但很可惜，为时已晚。 咱们做运维和开发，除了救火，还需要防火，因此一些防范的...

    djfml 评论0 收藏0

  • mysql到elasticsearch数据迁移踩坑实践-Ali0th

    摘要：配置文件其中有两个关键的配置和。启动如上即为正常运行。因为我在启动后一直报错，，各种尝试最后报错依然存在，只好换用部署了。安装部署安装和插件获取驱动下载配置配置使用时自行把下面注释去掉。Author : Ali0th Date : 20190514 最近用go语言写了个爬虫，爬了几百万条数据，存在 mysql 里，数据量较大，一个表就一两G的程度(mysql表一般不要超过2G)。 sho...

    littlelightss 评论0 收藏0

  • FastD 最佳实践四: 构建系统可视化监控

    摘要：的展示非常炫酷，绝对是运维提升逼格的一大利器。另外的可视化功能比强得多，而且以上版本将集成报警功能。它由写成，着力于高性能地查询与存储时序型数据。被广泛应用于存储系统的监控数据，行业的实时数据等场景。 原有监控系统 showImg(https://segmentfault.com/img/remote/1460000011082384); 整个系统以 Graphite (carbon ...

    khlbat 评论0 收藏0

  • JHipster技术简介

    摘要：本文简单介绍是什么，为什么用，怎么用。技术栈是什么是一个开发平台，用于生成，开发，部署和。实现需定制化源码。 本文简单介绍Jhipster是什么，为什么用Jhipster，怎么用Jhipster。 WHAT - 技术栈 JHipster是什么 JHipster是一个开发平台，用于生成，开发，部署Spring Boot + Angular/React Web Application和Sp...

    hightopo 评论0 收藏0

发表评论

登陆后可评论

0条评论

IT那活儿

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<