实战中经常遇到的问题:
问题 1:请问下大家是如何评估集群的规模?比如数据量达到百万,千万,亿万,分别需要什么级别的集群,这要怎么评估?
ps:自己搭建的测试环境很难达到这一级别。
问题 2:
问题 3:我看了很多文章关于 es 集群规划的文章,总感觉乱七八糟的,没有一个统一的规划思路。如何根据硬件条件和数据量来规划集群,设置多少节点,每个节点规划多少分片和副本?
Elasticsearch 集群规模和容量规划:是进行 Elasticsearch 集群部署前对所需资源类型和数量的规划。
通过本文,您将了解:
角色 | 描述 | 存储 | 内存 | 计算 | 网络 |
---|---|---|---|---|---|
数据节点 | 存储和检索数据 | 极高 | 高 | 高 | 中 |
主节点 | 管理集群状态 | 低 | 低 | 低 | 低 |
Ingest 节点 | 转换输入数据 | 低 | 中 | 高 | 中 |
机器学习节点 | 机器学习 | 低 | 极高 | 极高 | 中 |
协调节点 | 请求转发和合并检索结果 | 低 | 中 | 中 | 中 |
划重点:对资源利用率拿不准的,多结合业务实际看看这个表格。
4 个基本的计算资源 存储、内存、计算、网络
注意:RAID0 可以提高性能。RAID 是可选的,因为 Elastic 默认为 N + 1 分片复制策略。
为了追求硬件级别的高可用性,可以接受标准性能的 RAID 配置(例如 RAID 1/10/50 等)。
存储有关集群索引、分片、段和 fielddata 数据。
建议:可用 RAM 的 50%,最多最大 30GB RAM,以避免垃圾回收。
官方文档最大指 32 GB:
https://www.elastic.co/guide/en/elasticsearch/guide/master/heap-sizing.html
Elasticsearch 将使用剩余的可用内存来缓存数据(Lucene 使用), 通过避免在全文检索、文档聚合和排序环节的磁盘读取,极大地提高了性能。
Elasticsearch 如何使用计算资源?
Elasticsearch 处理数据的方式多种多样,但计算成本较高。
可用的计算资源:线程池、线程队列。
CPU 内核的数量和性能:决定着计算平均速度和峰值吞吐量。
Elasticsearch 如何使用网络?小带宽是限制 Elasticsearch 的资源。
针对大规模集群,ingest、搜索和副本复制相关的数据传输可能会导致网络饱和。
在这些情况下,网络连接可以考虑升级到更高的速度,或者 Elastic 部署可以分为两个或多个集群,然后使用跨集群(CCS)作为单个逻辑单元进行搜索。
增、删、改、查是 Elasticsearch 中的四个基本数据操作。
每个操作都有其自己的资源需求。每个业务用例都利用其中一个操作,实际业务往往会侧重其中一个或多个操作。
如图所示,增/索引数据大致的处理流程如下:
如果所示,删除数据大致处理流程如下:
文档在 Elasticsearch 中是不可变的。当 Elasticsearch 更新文档时,它将删除原始文档并为新的待更新的文档建立索引。
这两步操作在每个 Lucene 分片是原子操作,操作会带来删除和索引(索引不调用任何 ingest pipeline 操作)操作的开销。
Update = Delete + (Index - Ingest Pipeline)
“搜索”是信息检索的通用术语。Elasticsearch 具有多种检索功能,包括但不限于全文搜索、范围搜索、脚本搜索和聚合。
搜索速度和吞吐量受许多因素影响,包括集群的配置、索引、查询和硬件。
实际的容量规划取决于应用上述优化配置后的大量测试实践结果。
Elasticsearch 检索可以细化分为:scatter(分散)、 search(检索)、gather(收集)、merge(合并)四个阶段。
Elasticsearch 有一些常规的使用模式。大致可分类如下:
以下过程适用于 ingest 节点处理数据流程。
结构化或非结构化数据转换成 json 格式,可通过_source 控制是否展示。
第一:数据结构 Elasticsearch 索引各种数据结构中的值。每种数据类型 有自己的存储特性。
第二:多种索引方法 某些值可以通过多种方式索引。字符串值通常是索引两次(借助 fields 实现)。
Elasticsearch 可以使用两种不同的压缩算法之一来压缩数据:LZ4(默认)和 DEFLATE。
与 LZ4 相比,DEFLATE 节省了多达 15%的额外空间,但以增加的计算时间为代价。
通常,Elasticsearch 可以将数据压缩 20 – 30%。
第一:存储 Elasticsearch 可以在数据节点之间复制分片一次或多次,以提高容错能力和搜索吞吐量。
每个副本分片都是其主分片的完整副本。
第二:索引和搜索吞吐量
容量规划——预估集群中每个节点的分片数、内存及存储资源。
吞吐量规划——以预期的延迟和吞吐量估算处理预期操作所需的内存,计算和网络资源。
第一,问自己几个问题:
第二,预留存储以备错误。(Elastic 官方推荐经验值)
第三,容量预估计算方法如下:
Tips:腾讯云 在 2019 4 月的 meetup 分享中建议:磁盘容量大小 = 原始数据大小 * 3.38。
第一,问自己几个问题:
第二,经验值(Elastic 官方推荐)
Tips:
第三,分片预估方法如下:
搜索用例场景除了考虑搜索容量外,还要考虑如下目标:
这些目标可能需要更多的内存和计算资源。
第一:问自己几个问题
第二:方法论 与其确定资源将如何影响搜索速度,不如通过在计划的固定硬件上进行测量
,可以将搜索速度作为一个常数,
然后确定集群中要处理峰值搜索吞吐量需要多少个核。
最终目标是防止线程池排队的增长速度超过了 CPU 的处理能力。
如果计算资源不足,搜索请求可能会被拒绝掉。
第三:吞吐量预估方法
Elasticsearch 可以使用分片分配感知(shard allocation awareness)在特定硬件上分配分片。
索引密集型业务场景通常使用它在热节点、暖节点和冷(Frozen)节点上存储索引,
然后根据业务需要进行数据迁移(热节点->暖节点->冷节点),以完成数据的删除和存档需要。
这是优化集群性能的最经济方法之一,在容量规划期间,先确定每一类节点的数据规模,然后进行组合。
冷热集群架构推荐:
节点类型 | 存储目标 | 建议磁盘类型 | 内存/磁盘比率 |
---|---|---|---|
热节点 | 搜索优化 | SSD DAS / SAN(> 200Gb / s) | 1:30 |
暖节点 | 存储优化 | HDD DAS / SAN(〜100Gb / s) | 1:160 |
冷节点 | 归档优化 | 最便宜的 DAS / SAN(<100Gb / s) | 1:1000+ |
Elasticsearch 节点执行一个或多个角色。通常,当集群规模大时,每个节点分配一个具体角色很有意义。
您可以针对每个角色优化硬件,并防止节点争夺资源。
同 2.2 章节。不再赘述。
集群规模和容量规划的底层逻辑涉及到:
评估所需资源需要执行以下步骤:
步骤1:确定集群的节点类型;
步骤2:对于不同节点类型(热,暖,冷),确定以下规模的最大值:
步骤3:合并每一类型节点所需资源大小 注意:在任何专用节点上做出决策-主节点、协调节点、机器学习节点、路由节点。
注:这是 Elastic 官方 2019 年 11 月份的视频 内容的详细梳理。
推荐过一遍视频:
https://www.elastic.co/cn/webinars/elasticsearch-sizing-and-capacity-planning
本文分享自 铭毅天下Elasticsearch 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!