---
title: "Easysearch 容量规划建议"
date: 2023-10-26
lastmod: 2023-10-26
description: "本文介绍了基于容量和搜索吞吐量的集群规模估算方法，包括总数据量、存储需求、节点数量计算，并结合 Hot、Warm、Frozen 不同存储层的需求进行规划，确保性能与成本的平衡。"
tags: ["Easysearch", "监控系统"]
summary: "基于容量估算 #  主要问题： #   每天将索引多少原始数据（GB）？保留数据多少天？ 原始数据膨胀率 您将强制执行多少个副本分片？ 您将为每个数据节点分配多少内存？ 您的内存:数据比例是多少？  原则 #   保留 +15% 以保持在磁盘水位以下。 保留 +5% 用于误差和后台活动的余量。 保留相当于一个数据节点的资源来处理故障。  公式： #  总数据量 GB = 原始数据 GB/天 * 保留天数 * 膨胀率 * (副本数 + 1)
总存储 GB = 总数据 GB * 1.15（包括磁盘 watermark threshold 和误差范围）
总数据节点数 = ROUNDUP(总存储 GB / (每个数据节点的内存 * 内存/数据比例)) + 1（用于故障转移）
举例： #  假设 需要存储的源数据 50TB 大小
膨胀率 10% 副本数 1"
---


## 基于容量估算

### 主要问题：

- 每天将索引多少原始数据（GB）？保留数据多少天？
- 原始数据膨胀率
- 您将强制执行多少个副本分片？
- 您将为每个数据节点分配多少内存？
- 您的内存:数据比例是多少？

### 原则

- 保留 +15% 以保持在磁盘水位以下。
- 保留 +5% 用于误差和后台活动的余量。
- 保留相当于一个数据节点的资源来处理故障。

### 公式：

总数据量 GB = 原始数据 GB/天 \* 保留天数 \* 膨胀率 \* (副本数 + 1)

总存储 GB = 总数据 GB \* 1.15（包括磁盘 watermark threshold 和误差范围）

总数据节点数 = ROUNDUP(总存储 GB / (每个数据节点的内存 \* 内存/数据比例)) + 1（用于故障转移）

## 举例：

假设 需要存储的源数据 50TB 大小

膨胀率 10% 副本数 1

每个节点 256G 内存

计算出：

### 总数据量 TB

= 50TB \* (1 + 0.10) \* (1 + 1)

= 110TB

### 总存储 TB

= 110TB \* 1.15（考虑磁盘 watermark threshold 和误差范围）

= 126.5TB

如果有 256GB 的物理内存，128GB 会用于 JVM 堆，剩下的 128GB 将用于操作系统、文件缓存和其他系统进程。

按照常见的 1:30 的 RAM 到磁盘比例来计算，那么每个节点能处理的数据存储大约是：

256GB 内存 \* 30 = 7680GB，大约等于 7.68TB

### 总数据节点数

= ROUNDUP(126.5TB / 7.68TB) + 1（用于故障转移）

= ROUNDUP(16.47) + 1

= 18

## 基于搜索吞吐量估算

在存储容量层面之外，还要考虑搜索响应时间和搜索吞吐量的目标，这些目标可能需要更多的内存和计算资源。

搜索响应时间受太多变量的影响，无法预测任何给定容量计划会如何影响它。但通过经验性测试搜索响应时间并估计预期的搜索吞吐量，我们可以估算出满足这些需求所需的集群资源。

### 主要问题：

- 你每秒的最高搜索次数是多少？
- 你的平均搜索响应时间（毫秒）是多少？
- 你的数据节点上有多少个核心和每个核心有多少个线程

### 经验方法：

与其确定资源将如何影响搜索速度，不如将搜索速度视为一个常数，通过在计划的硬件上进行测量来处理。然后确定集群需要多少个核心来处理预期的搜索吞吐量峰值。最终目标是防止线程池队列增长速度超过它们被消耗的速度。如果计算资源不足，搜索请求有被丢弃的风险。

### 公式：

峰值线程数 = 向上取整（每秒的峰值搜索次数 \* 平均搜索响应时间（毫秒） / 1000 毫秒）

线程池大小 = 向上取整（（每个节点的物理核心数 \* 每个核心的线程数 \* 3 / 2） + 1）

总数据节点数 = 向上取整（峰值线程数 / 线程池大小）

### 举例：

假设每秒 2 万搜索请求，平均响应时间 50 毫秒，每个节点有 16 个线程数，计算需要多少节点

峰值线程数 = 20000 \* 50 /1000 = 1000

线程池大小 = (16 \* 1 \* 3/2) + 1 = 25

总数据节点数 = 1000 / 25 = 40

大概需要 40 个数据节点来处理每秒 2 万的搜索请求，平均响应时间为 50 毫秒，每个节点有 16 个线程。这是一个粗略的估计，实际需求可能会因多种因素而有所不同。建议进行实际测试以确认这些数字。

## Hot, Warm, Frozen

根据索引使用情况不同，通常分为种存储。
这是一种经济高效的方法，用于存储大量数据，同时优化了对较新数据的性能。在容量规划期间，每个层次必须独立进行规模确定，然后进行合并。

| 层面   | 目标     | 示例存储                    | 示例内存：存储比 |
| ------ | -------- | --------------------------- | ---------------- |
| Hot    | 搜索为主 | SSD DAS/SAN (>200Gb/s)      | 1:30             |
| Warm   | 存储为主 | HDD DAS/SAN (~100Gb/s)      | 1:100            |
| Frozen | 存档为主 | Cheapest DAS/SAN (<100Gb/s) | 1:500            |

实际情况要把搜索吞吐量估算和容量估算结合考虑。