暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / Elasticsearch 最佳实践

Elasticsearch 最佳实践

IT那活儿 2022-04-18
2113

点击上方“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那活儿（上海新炬王翦团队）

​​​
数据库elasticsearch
文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论