计算方法说明Methodology

1. 输入Inputs

工具的输入是未压缩的业务数据量（GB/TB/PB）和基础设施类型。所有路径都从这两个值出发推导节点数与每节点规格。

The inputs are the uncompressed business data size (GB/TB/PB) and the infrastructure type. Every path derives node counts and per-node specs from these two values.

2. 通用规则Common rules

压缩比Compression

列式存储 + 压缩后，落盘数据 ≈ 业务数据 ÷ 压缩比（默认 2，可在高级选项调整）。存算分离（容器）路径按源规范不启用压缩。

With columnar storage + compression, on-disk data ≈ business data ÷ compression ratio (default 2, adjustable in advanced options). The container path applies no compression, per its source spec.

onDiskTB = dataTB ÷ compressionRatio

计算资源约束Compute constraint (8c32G / TB)

基线：每 1 TB 落盘数据配一个 8 逻辑核（vCPU）+ 32 GB 内存的 segment，可支撑最高约 80 并发——满足大多数数据仓库场景。依据内存管理最佳实践：每 segment 内存最低 8GB、推荐 32GB；单查询内存 statement_mem = gp_vmem_protect_limit × 0.9 ÷ 预期并发数，32G × 0.9 ÷ 80 ≈ 368MB/查询，属健康区间。并发要求更高时，按该公式线性放大每 segment 资源（高级选项）：≤120 并发 ×1.5，≤160 并发 ×2。

Baseline: one segment of 8 logical cores (vCPU) + 32 GB per TB of on-disk data supports up to ~80 concurrent queries — enough for most data-warehouse workloads. Grounding, from MPP memory-management best practice: 8GB minimum and 32GB recommended per segment; per-query memory statement_mem = gp_vmem_protect_limit × 0.9 ÷ expected_concurrency, and 32G × 0.9 ÷ 80 ≈ 368MB per query is a healthy value. For higher concurrency the per-segment resources scale linearly (advanced options): ≤120 concurrent ×1.5, ≤160 ×2.

perNodeTB    = min( vCPU ÷ (8 × f),  memGB ÷ (32 × f) )     # f = 并发系数：≤80→1（默认）/ ≤120→1.5 / ≤160→2
computeNodes = CEIL( onDiskTB ÷ perNodeTB )

「并发」的定义：指资源组排队后同时活跃的语句数（混合 BI/报表负载，每查询约 300–400MB 内存）。如果负载以重型分析查询为主（大表 join、每查询需要 GB 级内存），应按每 segment 5–10 并发评估——同样的 8 逻辑核 + 32G 配额，此时每查询可分到 32G × 0.9 ÷ 5 ≈ 5.7GB。CPU 本身没有"每核 X 并发"的硬公式：查询靠分时与排队弹性共享 CPU，内存才是并发数的硬约束。

perNodeTB    = min( vCPU ÷ (8 × f),  memGB ÷ (32 × f) )     # f = concurrency factor: ≤80→1 (default) / ≤120→1.5 / ≤160→2
computeNodes = CEIL( onDiskTB ÷ perNodeTB )

What "concurrency" means here: the number of simultaneously active statements after resource-group queueing (mixed BI/reporting workloads, ~300–400MB per query). If the workload is dominated by heavyweight analytical queries (large joins needing GBs per query), plan for 5–10 concurrent per segment instead — the same 8-logical-core + 32G quota then gives each query 32G × 0.9 ÷ 5 ≈ 5.7GB. There is no hard "X concurrent per core" formula for CPU: queries share CPU elastically via time-slicing and queueing; memory is the hard constraint on concurrency.

单 Segment 资源配额表（经验值）Per-segment resource quota (field experience)

一个 primary segment 的完整资源画像。前两行随并发系数缩放；网络与盘 IO 是单段满载峰值参考，用于校验主机聚合带宽与阵列吞吐（分析型负载的峰值很少全段同时对齐，不做硬性乘法）：

The complete resource profile of one primary segment. The first two rows scale with the concurrency factor; network and disk I/O are per-segment full-load peak references for sanity-checking host aggregate bandwidth and array throughput (analytical bursts rarely align across all segments, so do not multiply them rigidly):

适用并发：混合 BI 负载 ≤80 活跃语句（f=1）；重型分析负载按 5–10 并发/段评估。Coordinator 不套此表，按各路径给出的固定规格配置。

Applicable concurrency: ≤80 active statements of mixed BI at f=1; plan 5–10 per segment for heavyweight analytics. Coordinators do not follow this table — use the fixed specs given per path.

存储资源约束（统一公式）Storage constraint (unified formula)

所有 MPP 路径使用同一个单节点可用容量公式，每个折扣项只出现一次：×0.9 操作系统与文件系统开销、×0.8 预留 20% 空闲、÷(副本数 + 1/3 工作空间)。副本数取 2（segment 自带 mirror）或 1（冗余由存储层提供——云盘多副本、vSAN 等分布式存储，此时无需 mirror，可用容量近乎翻倍）。注意：当前开源 Cloudberry 尚不支持 mirrorless 部署——选用无 mirror 方案需联系 Cloudberry 商业支持厂商适配，或自行适配相关平台能力（平台能力清单见第 8 节）。物理机代入 RAID 后阵列容量，虚拟机/云主机代入数据盘标称容量：

Every MPP path uses one per-node usable-capacity formula, each discount applied exactly once: ×0.9 OS/filesystem overhead, ×0.8 to keep 20% free, ÷(copies + 1/3 workspace). Copies is 2 with segment mirroring, or 1 when the storage layer provides redundancy (replicated cloud disks, vSAN-style distributed storage — no mirrors needed, usable capacity nearly doubles). Note: open-source Cloudberry does not support mirrorless deployment out of the box — mirrorless schemes require adaptation by a commercial Cloudberry support vendor, or adapting the platform capability yourself (see section 8 for the platform capability checklist). Physical passes post-RAID array capacity; VM/cloud pass nominal data-disk capacity:

usableTB     = nominalTB × 0.9 × 0.8 ÷ (copies + 1/3)   # 有 mirror ≈ ×0.31 / 无 mirror ≈ ×0.54
storageNodes = max( 2, CEIL( onDiskTB ÷ usableTB ) )

usableTB     = nominalTB × 0.9 × 0.8 ÷ (copies + 1/3)   # mirrored ≈ ×0.31 / mirrorless ≈ ×0.54
storageNodes = max( 2, CEIL( onDiskTB ÷ usableTB ) )

最终节点数Final node count

存储与计算两个维度分别算出所需节点数，取较大者；带 mirror 的部署再向上取偶数（便于 primary/mirror 对称分布），无 mirror 的部署不取偶。结果页的徽标会标明是存储受限还是计算受限。

Storage-driven and compute-driven node counts are derived independently; the larger wins. Mirrored deployments then round up to an even number (for symmetric primary/mirror placement); mirrorless deployments do not. The result badge shows which constraint binds.

nodes = roundUpToEven( max( storageNodes, computeNodes ) )

3. 物理机Physical · Cloudberry MPP

存储节点数用统一公式，nominalTB 代入 RAID 后阵列容量 arrayTB。方法源自金融行业生产集群实践（2023），统一公式在其基础上补了工作空间项，因此比该实践略保守（例：160TB/压缩比 2 时高吞吐款为 14 台而非原实践的 12 台）。

Storage nodes use the unified formula with nominalTB = post-RAID array capacity. The method derives from a financial-industry production practice (2023); the unified formula adds the workspace term on top, so it is slightly more conservative (e.g. 14 instead of 12 high-throughput nodes at 160TB / cr 2).

三档硬件预设（arrayTB 取 RAID5 后可用盘数 × 单盘容量）：

Three hardware presets (arrayTB = usable disks after RAID5 × disk size):

NVMe 的 RAID 说明：主流 2U 机型支持 12–24 个 U.2/U.3 前置热插拔盘位（经背板直连 CPU PCIe lane，不占用 PCIe 扩展槽；12 盘 × 4 lane = 48 lane，双路 SPR 160 lane / 单路 EPYC 9004 128 lane 足够）；NVMe 硬件 RAID5 需三模（tri-mode）RAID 卡（如 Dell PERC H755N/H965i、Broadcom MegaRAID 9560/9600 系）或 Intel VROC。另一常见路线是 NVMe 不做 RAID（JBOD、每盘独立 XFS），冗余完全依赖 primary/mirror——吞吐更高，但单盘故障即触发 mirror 接管，本工具默认按更保守的 RAID5 计算容量。

NVMe RAID note: mainstream 2U servers take 12–24 hot-swap U.2/U.3 front bays (backplane-attached to CPU PCIe lanes, consuming no expansion slots; 12 drives × 4 lanes = 48 of the 128–160 lanes on EPYC 9004 / dual-socket SPR); hardware NVMe RAID5 needs a tri-mode controller (Dell PERC H755N/H965i, Broadcom MegaRAID 9560/9600) or Intel VROC. JBOD with mirror-only redundancy is a common higher-throughput alternative — a single disk failure then triggers mirror takeover; this tool sizes conservatively with RAID5.

Coordinator 固定 2 台（主+备），同级 CPU/内存，系统盘 RAID1 + 小容量数据阵列。计算约束按整机逻辑核数（2×32C 开 HT = 128 线程）与内存代入通用公式。

Coordinator is fixed at 2 (primary + standby), same CPU/memory class, RAID1 system disks + a small data array. The compute constraint uses the host's OS-visible logical cores (2×32C with HT = 128 threads) and memory in the common rule.

每主机段布局Segments per host

每台主机部署的 primary 数 = 主机资源 ÷ 单 segment 配额（8 逻辑核/32G × 并发系数），CPU 与内存取较小者；mirror 与 primary 同数量，用 spread mirroring 打散到其他主机（结果页按 N primary + N mirror 展示，并给出每 primary 实际管理的数据量）。核数一律按操作系统可见的逻辑核计（x86 开超线程即线程数，ARM 无 SMT 即物理核）——物理机、虚拟机、云主机同一条规则，无任何特判。例：物理机 2×32C 开 HT = 128 线程 / 512G → 16 primary + 16 mirror；虚拟机 Lite（8 vCPU/32G）→ 1 段；云主机 r5.4xlarge（16 vCPU/128G）→ 2 段。段数由更紧的约束（通常是 CPU）决定；内存富余不用于加段，而是抬高每段实际内存（如 r5.4xlarge 每段 64G），直接转化为更高并发余量与更少溢写——这正是内存优化机型的价值：不是更多 segment，是更好的 segment。

Primaries per host = host resources ÷ per-segment quota (8 logical cores / 32G × f), the tighter of CPU and memory; mirrors equal primaries, spread across other hosts (the result page shows N primary + N mirror plus the actual data per primary). Cores always mean OS-visible logical cores (thread count on x86 with hyperthreading; physical cores on SMT-less ARM) — one rule for physical, VM, and cloud alike, with no special cases. Examples: a physical host with 2×32C + HT = 128 threads / 512G → 16 primary + 16 mirror; a Lite VM (8 vCPU/32G) → 1 segment; an r5.4xlarge (16 vCPU/128G) → 2 segments. The tighter constraint (usually CPU) sets the segment count; surplus memory is not spent on extra segments — it raises the actual memory per segment (64G each on r5.4xlarge), buying concurrency headroom and fewer spills. That is the point of memory-optimized instances: not more segments, better segments.

每主机 segment 数需综合考虑：核数、内存、网卡数、存储容量、primary/mirror 混布、主机上的 ETL 及其他进程。相关内存参数按以下公式配置（Cloudberry 同名参数）：

Segments per host must weigh: cores, RAM, NICs, attached storage, the primary/mirror mixture, and ETL or other processes on the host. Memory parameters follow these formulas (same-named Cloudberry GUCs):

gp_vmem（≥256G 主机）      = ((SWAP + RAM) − (7.5GB + 0.05 × RAM)) ÷ 1.17
gp_vmem_protect_limit      = gp_vmem ÷ max_acting_primary_segments
statement_mem              = gp_vmem_protect_limit × 0.9 ÷ 预期并发数

gp_vmem (host ≥256G)       = ((SWAP + RAM) − (7.5GB + 0.05 × RAM)) ÷ 1.17
gp_vmem_protect_limit      = gp_vmem ÷ max_acting_primary_segments
statement_mem              = gp_vmem_protect_limit × 0.9 ÷ expected_concurrency

4. 虚拟机VM · Cloudberry MPP

存储节点数用统一公式，nominalTB 代入虚拟机数据盘标称容量。默认部署 primary+mirror；若底层为 vSAN 等多副本分布式存储，可勾选高级选项「Mirrorless 部署」——存储层已有冗余，segment 镜像可省，可用容量近乎翻倍（需商业适配，见通用规则）。

Storage nodes use the unified formula with nominalTB = the VM's nominal data-disk capacity. Primary+mirror is the default; on replicated distributed storage such as vSAN you may opt into the advanced "Mirrorless deployment" option — the storage layer already keeps replicas, so mirrors can be skipped and usable capacity nearly doubles (commercial adaptation required, see common rules).

三档虚拟机规格（1:4 内存比，每档 = N × 单 segment 的 8c/32G；如需更多缓存/并发余量可升到 1:8 内存优化型，不影响节点数）。按数据量自动推荐，可手动覆盖：

Three VM profiles (1:4 memory ratio — each tier is exactly N × the 8c/32G per-segment quota; a 1:8 memory-optimized variant adds cache/concurrency headroom without changing node counts). Auto-recommended by data size, manual override available:

5. 云主机Cloud · Cloudberry MPP

节点数公式与虚拟机相同，单节点存储取所选云方案的数据盘容量。每个云厂商提供两套方案：

Same node-count formula as VM, with per-node storage from the selected cloud scheme. Two schemes per provider:

• 云盘方案（云平台部署最佳实践）：AWS r5.4xlarge + 3×EBS ST1/GP3；Azure Standard_E16s_v5 + 3×P40 Premium SSD；GCP n2-highmem-8 + pd-ssd。默认同样部署 primary+mirror；云盘自身多副本且支持快照，可勾选「Mirrorless 部署」省去 mirror、可用容量近乎翻倍（需商业适配）。
• 本地盘方案（生产部署实践）：AWS i3en.2xlarge、Azure Standard_L8s_v3、GCP c3d-standard-8-lssd 本地 NVMe。吞吐更高、成本更低；本地盘随主机失效，因此始终保留 primary/mirror（Mirrorless 选项不适用）。

• Managed-disk schemes (cloud deployment best practice): AWS r5.4xlarge + 3×EBS ST1/GP3; Azure Standard_E16s_v5 + 3×P40 Premium SSD; GCP n2-highmem-8 + pd-ssd. Primary+mirror by default; managed disks are replicated and snapshot-capable, so the "Mirrorless deployment" option can skip mirrors and nearly double usable capacity (commercial adaptation required).
• Local-NVMe schemes (production practice): AWS i3en.2xlarge, Azure Standard_L8s_v3, GCP c3d-standard-8-lssd. Higher throughput, lower cost; local disks die with the host, so primary/mirror is always kept (the mirrorless option does not apply).

附加建议：Azure 使用 UDP interconnect 并预留端口 65330；GCP 上建议用更多的小节点（相对 AWS）。

Extra guidance: on Azure use the UDP interconnect and reserve port 65330; on GCP prefer more, smaller nodes (vs AWS).

6. 容器 / K8s · 存算分离Container / K8s · Compute-storage separation

存算分离形态下数据本体在对象存储（OSS，按需扩容），计算节点本地盘只是缓存/工作区。Segment 遵循与 MPP 路径完全相同的并发大原则：每 segment 管理 1 TB 数据，规格 = 8 vCPU / 32G × 并发系数（高级选项里的同一个并发规模选项：≤80 默认 ×1 / ≤120 ×1.5 / ≤160 ×2）。Segment 数量只由数据量决定，并发只影响单 segment 规格：

With compute-storage separation the data lives in object storage (OSS, scaled on demand) and local disks are cache/workspace only. Segments follow exactly the same concurrency principle as the MPP paths: each segment manages 1 TB with 8 vCPU / 32G × the concurrency factor (the same advanced-options selector: ≤80 default ×1 / ≤120 ×1.5 / ≤160 ×2). Segment count is driven by data size alone; concurrency only scales the per-segment spec:

segments    = max( 2, CEIL( dataTB ÷ 1TB ) )
segmentSpec = (8 × f) vCPU / (32 × f) G
本地缓存盘   = 1TB × 50% × f          # 标准 500G / 高 750G / 很高 1T

segments    = max( 2, CEIL( dataTB ÷ 1TB ) )
segmentSpec = (8 × f) vCPU / (32 × f) G
localCache  = 1TB × 50% × f          # std 500G / high 750G / very high 1T

存储的两层设计：OSS 容量 ≈ 业务数据量（该形态不启用压缩），按需扩展、不参与节点计算，结果页直接标出预期容量；segment 本地盘只是缓存 + 溢写空间，取所管数据的 50% 为基线并随并发系数放大——溢写文件量随并发查询数增长（500G–1T，与厂商规范区间一致）。

Two-layer storage design: OSS capacity ≈ business data size (compression is off in this form factor), scales on demand and never drives node counts — the result page states the expected capacity; segment local disks are cache + spill only, baselined at 50% of managed data and scaled by the concurrency factor, since spill volume grows with concurrent queries (500G–1T, matching the vendor spec range).

Proxy 固定 16 vCPU / 64G（覆盖 ≤80 并发）；更高并发档通过 LB 自动增加第二个 Proxy 实例。固定平台组件：Meta 服务 6 实例（UnionStore ×4 + Metadata-Proxy + Storage-Broker）、WebConsole ×11 小容器、负载均衡、OSS。

The proxy is fixed at 16 vCPU / 64G (covers ≤80 concurrent); higher tiers add a second proxy instance behind the LB. Fixed platform components: 6 meta-service instances (UnionStore ×4 + Metadata-Proxy + Storage-Broker), WebConsole ×11 small containers, load balancer, OSS.

7. 汇总与可承载容量Totals & usable capacity

资源汇总 = Σ(各角色节点数 × 每节点规格)。「可承载数据量」是把最终节点数代回存储公式反推的上限——它 ≥ 你输入的数据量，差值就是本方案的自然余量。

Totals sum count × per-node spec across roles. "Usable data capacity" inverts the storage formula at the final node count — it is ≥ your input, and the difference is the recommendation's natural headroom.

capacityTB = nodes × usableTB × compressionRatio

8. Mirrorless 部署前置条件Mirrorless prerequisites

Mirrorless 的本质是数据库层不做副本，冗余与故障恢复全部押在平台上。因此只有当底层虚拟化 + 分布式存储平台（vSAN、Ceph 类多副本块存储等）补齐下列能力时才成立。此清单可直接用于与平台厂商核对能力。

Mirrorless means the database keeps no second copy — redundancy and failure recovery rest entirely on the platform. It only holds up when the underlying virtualization + distributed storage stack (vSAN, Ceph-style replicated block storage, etc.) provides all of the capabilities below. Use this list to verify platform capabilities with your vendor.

代价：RTO 从秒级变分钟级The trade-off: RTO goes from seconds to minutes

带 mirror 时主机故障是秒级切换到 mirror，业务在线不断；mirrorless 下段没有副本，故障期间查询直接失败，恢复时间 = 平台判死 + VM 拉起 + 数据库自启，通常分钟级。选择 mirrorless 前先确认业务能接受这个 RTO。

With mirrors, a host failure fails over to the mirror in seconds and queries keep running. Under mirrorless the segment has no replica, so queries fail outright and recovery time = platform failure detection + VM restart + database autostart — typically minutes. Confirm the business accepts that RTO before choosing mirrorless.

必须压测的吞吐Throughput must be proven

单 segment 配额要求 300 MB/s 读 + 300 MB/s 写（见配额表）。多副本网络存储有写放大与网络往返，需全闪介质 + 独立高速存储网才可能达标。POC 必测三项：单 VM 顺序读写、全集群并发扫描的聚合带宽、以及故障注入（拔掉一台主机，实测 RTO 与数据完整性）。

Each segment's quota calls for 300 MB/s read + 300 MB/s write (see the quota table). Replicated network storage adds write amplification and network round-trips, so all-flash media plus a dedicated high-speed storage network are required to get there. Three POC musts: single-VM sequential read/write, cluster-wide concurrent scan aggregate bandwidth, and failure injection — pull a host and measure the real RTO and data integrity.

注意副本叠乘Watch out for stacked replication

本工具的容量公式只计数据库层副本（copies）；平台层副本需再乘一次。这也是分布式存储上 mirrorless 的最大价值——避免双层副本叠乘：

This tool's capacity formula counts database-layer copies only; platform-layer replication multiplies on top. Avoiding that stacked amplification is the main value of mirrorless on distributed storage:

数据库侧On the database side

初始化时不配置 mirror 本身很简单，难的是故障恢复流程、自启集成与支持背书。当前开源 Cloudberry 不提供 mirrorless 的编排与支持，需联系 Cloudberry 商业支持厂商适配，或自行适配相关平台能力。

Initializing without mirrors is the easy part; the hard parts are the failure-recovery runbook, autostart integration, and a support commitment. Open-source Cloudberry provides no mirrorless orchestration or support — engage a commercial Cloudberry support vendor, or adapt the platform capability yourself.

⚠ 所有结果为估算值，实际配置请以 POC 验证为准。

⚠ All results are estimates; validate with a POC before final sizing.