成本与运维与 MPP 架构基础

• I/O 计费方式（按 I/O 次数）
• I/O-Optimized 与标准模式的差异
• 适用场景与成本权衡

Aurora 传统上按存储用量和 I/O 请求次数计费（I/O 写入/读取次数），在 I/O 密集场景下这一项成本可能很高。Aurora I/O-Optimized 是一种定价模式：它把 I/O 费用并入实例费用（包含更高的每小时实例单价），从而取消单独的 I/O 计费，让 I/O 成本可预测。适合 I/O 密集、读多写多的工作负载；而标准模式（单独计 I/O）适合 I/O 相对较少、以空闲为主的工作负载。选择时需根据实际 I/O 量估算哪种更划算，I/O 量大时 I/O-Optimized 更省钱。

I/O-Optimized 本质是"把可变 I/O 成本转成固定溢价"。对高 I/O 负载，固定溢价低于按 I/O 计费，成本可预测；对低 I/O 负载，标准模式更便宜。这是成本建模与选型的关键。

• 慢查询日志与慢查询定位
• Performance Insights 的负载分析
• 等待事件与瓶颈定位

云数据库（如 Aurora）通过慢查询日志记录执行时间超过阈值的 SQL，配合性能洞察（Performance Insights）提供数据库负载的可视化分析。Performance Insights 把数据库负载按维度（SQL、等待事件、用户、主机）聚合，以"数据库负载（DB Load）"为单位展示，帮助定位消耗资源最多的 SQL 与等待事件（如 IO、锁、CPU）。它支持按时间回溯，配合 Explain 分析慢查询产生的原因（缺索引、数据倾斜、锁等待、大扫描等），从而对症优化。

慢查询定位是"发现问题"，Performance Insights 是"定位根因"。它把负载拆解到 SQL 与等待事件，量化哪些查询、哪些等待在拖累数据库。结合慢日志与 Explain，形成完整的慢查询优化闭环。

• Share-Nothing 架构特征
• 节点间数据分布与协作
• 与 Share-Everything 的对比

MPP（Massively Parallel Processing，大规模并行处理）采用 Share-Nothing（无共享）架构：每个节点（segment）拥有独立的 CPU、内存和磁盘，数据按分区分布在各个节点上，节点之间不共享存储，通过高速网络（Interconnect）通信协作。查询时，每个节点并行处理自己分到的数据（本地扫描、聚合、排序），再通过数据交换（重分布、广播）合并结果。这种"节点独立、数据分布、并行协作"的模型让系统可横向扩展（加节点加吞吐），是 Greenplum、ClickHouse 等 MPP 数据库的基础。

Share-Nothing 的核心是"数据分片 + 并行计算"，避免共享存储的竞争瓶颈。代价是节点间数据交换（shuffle）会产生网络开销，Join 等跨节点操作需要重分布。理解它才能理解 MPP 的扩展性与局限。

• 数据倾斜的检测方法
• 加盐（salt）、二次聚合、skew join 的适用场景
• 对结果正确性的要求

数据倾斜指部分节点分到远多于其他节点的数据，导致个别节点成为瓶颈、整体拖慢。检测：观察各节点处理时间/数据量分布，统计字段值分布（高频 key），或用执行计划中的重分布行数判断。缓解：加盐（salt）针对倾斜聚合，给倾斜 key 拼接随机盐值后在段内做部分聚合，再做最终聚合，但要保证正确性需合并所有盐值结果；二次聚合是先做一遍部分聚合减少数据量，再做最终聚合，适合可压缩的聚合（如 count/sum 可分解，但 count distinct、median 等不可简单分解）；skew join 专门处理倾斜 Join，把倾斜侧拆开（如按盐值拆分）与非倾斜侧分别处理，再合并。结果正确性要求：任何优化都必须保持聚合/Join 的语义正确，如 count distinct 不能靠简单加盐丢重，需要特殊处理；若聚合函数不可分解（如取中位数、去重计数），不能直接二次聚合，需保留中间状态。

倾斜缓解的核心是"打散热点"：加盐把倾斜 key 扩散到多节点做部分计算，再汇总。但"可分解性"决定了能否用两阶段聚合，不可分解的聚合需要保真中间态。理解正确性约束是优化不引入 bug 的前提。

• Query Dispatcher（QD/QE）的角色
• 数据重分布（shuffle）的触发
• 分发与执行的流程

在 MPP 数据库（如 Greenplum）中，查询分发由 Query Dispatcher（QD，主节点/协调器）完成：QD 接收客户端 SQL，生成并行执行计划，然后把计划分发给各个 segment（QE，Query Executor）并行执行。当 join/聚合/排序需要跨节点数据时，会触发数据重分布（shuffle）：各节点按哈希/哈希键把数据重新分布到对应节点，使相同 key 的数据落到同一节点，再进行本地 join/聚合。QD 负责汇总各段结果并返回给客户端。重分布是 MPP 并行计算的关键，也是网络开销的主要来源。

QD 是"指挥者"，QE 是"执行者"，重分布是"数据搬运"。QD 决定计划，QE 并行执行，重分布保证数据局部性以便本地计算。理解这条链路才能分析 MPP 查询的瓶颈（往往是重分布网络）。

• Stage/Fragment 的概念
• 流水线划分与执行
• 与并行度的关系

MPP 查询执行把计划划分成多个 Stage（或 Fragment，如 Trino 的 stage、Presto 的 fragment）：每个 Stage 是在一批节点上并行执行的一组算子（如扫描、本地聚合、重分布），Stage 之间通过数据交换（Exchange/Shuffle）连接。上游 Stage 产出的数据流经 Exchange 流入下游 Stage，形成流水线（pipeline）执行。划分的原则是：把可并行、可下推的算子分段，跨节点交换处切分阶段。Stage 划分定义了并行度与数据流，是整个分布式执行计划的结构骨架。

Stage/Fragment 是 MPP 执行计划的分层结构。Exchange 是阶段边界，也是跨节点数据流的连接点。理解 Stage 划分，才能读懂执行计划、定位重分布与并行瓶颈。

• Broadcast 与 Shuffle 的含义
• 两种交换的适用场景
• 网络开销的权衡

Broadcast 与 Shuffle 是 MPP 中两种数据交换方式。Broadcast（广播）：把整张表的数据复制发送到所有节点，每个节点都有一份完整数据，适合小表与任意表 join（每个节点本地 join 即可），避免按 key 重分布，但网络开销随节点数线性增长。Shuffle（重分区）：按某 key 的哈希把数据重新分布到目标节点，使相同 key 落在同一节点，适合大表 join 或分组聚合，网络开销与数据量相关。优化器根据表大小、join 类型选择 broadcast 或 shuffle：小表广播、大表 shuffle，或大表 join 大表用 shuffle。

Broadcast 是"复制到所有节点"，Shuffle 是"按 key 分派"。前者适合小表、避免重分布，后者适合大表 join。选择依据是"哪个网络开销小"。理解二者是优化 MPP join 的基础。

• Greenplum 的 MPP 架构（PostgreSQL 内核）
• ClickHouse 的列式 + 分布式
• 两者数据处理模型的差异

Greenplum 基于 PostgreSQL 内核扩展，是传统 MPP 数仓：支持 SQL 全覆盖、事务、复杂 join，通过 interconnet 做数据交换，适合复杂分析 SQL 与高并发并发查询。ClickHouse 是列式存储 + 分布式表：数据按分区/分片存储在各节点，通过分布式表（Distributed table）做查询路由，主打列式压缩、向量化执行、极快的单表聚合扫描，但 join 能力较弱、不适合高频点查与复杂事务。差异在于：Greenplum 强在"通用复杂 SQL 分析"，ClickHouse 强在"大表列式聚合扫描的快"，前者面向 AD-HOC 分析，后者面向实时宽表聚合。

两者都是 MPP 思想，但定位不同：Greenplum 是"MPP 化的 PostgreSQL"（重 SQL、重 join），ClickHouse 是"列式 + 分布式"（重扫描、重聚合）。选型取决于查询复杂度 vs 扫描性能的权衡。

• MPP 的并行执行模型
• MapReduce 的 Map/Shuffle/Reduce 模型
• 迭代、延迟与交互性差异

MPP 与 MapReduce 都采用"数据分布 + 并行计算 + 聚合"的思路，但执行模型不同。MPP：数据常驻内存磁盘，查询直接被优化器编译为并行物理计划，节点间通过高速网络流式交换，支持交互式、低延迟、可迭代的复杂查询（如 join、窗口函数）。MapReduce：把计算抽象为 Map（本地处理）→ Shuffle（按 key 分组）→ Reduce（聚合）三个阶段，数据多写磁盘（中间结果落盘），任务调度由 JobTracker/YARN 管理，适合批处理、吞吐优先，但延迟高、迭代查询需反复读写磁盘，交互性差。差异本质：MPP 是"常驻 + 流式 + 低延迟"，MapReduce 是"批处理 + 落盘 + 高吞吐"。

两者共享"分治法"思想，但工程模型不同：MPP 优化低延迟交互查询，MapReduce 优化批处理吞吐。理解差异有助于判断何时用 SQL 并行引擎、何时用批处理框架。

• 按需实例（On-Demand）计费
• 预留实例（Reserved）的折扣
• 适用场景与权衡

按需实例（On-Demand）按使用时长灵活计费，随时创建/释放，适合负载波动、临时需求，但单价高。预留实例（Reserved Instance）承诺长期（1年/3年）使用，换取显著折扣（通常 30%-50%+），适合长期稳定运行的常驻实例，但不灵活（提前终止有成本）。对比上：预留实例单位成本更低、适合持续运行的基准负载；按需实例更灵活、适合临时或波动负载。实际 TCO 往往采用"预留兜底 + 按需/Serverless 弹性"的组合，用预留覆盖基准、按需覆盖尖峰。

预留 vs 按需是"承诺换折扣"的权衡。预留适合确定性负载，按需适合不确定性负载。混合策略兼顾成本与弹性，是云数据库成本优化的常见做法。

• 核心监控指标（CPU、内存、IOPS、连接数、延迟）
• 告警阈值与等级
• 监控与故障定位

云数据库监控应覆盖核心指标：CPU 使用率、内存、磁盘/存储占用、IOPS 与存储延迟、连接数、慢查询数、复制延迟（只读副本）、主从故障、错误率等。告警配置应分级：紧急告警（如实例不可用、存储耗尽、复制中断）即时通知；警告告警（如 CPU 高、连接数逼近上限、慢查询增多）设置合理阈值并避免误报。同时监控"等待事件/性能洞察"用于定位瓶颈。配置原则是"指标要能反映瓶颈、阈值要能提前预警、告警要分级可行动"。

监控是"眼睛"，告警是"警报"。指标要覆盖资源、性能、可用性、容量维度；告警要避免"报了没用"和"应该报没报"。结合性能洞察与慢查询，才能从"看到异常"到"定位根因"。

• TCO 的构成（硬件、软件、运维、人力）
• 云数据库的优势与隐形成本
• 自建的成本考量

TCO（总拥有成本）对比需综合硬件、软件授权、运维人力、故障停机、扩展成本。云数据库：省去硬件采购与机房、免运维（自动备份、高可用、补丁），按需付费，初始投入低，但长期高负载下费用可能增长、并存在迁移/出网带宽等成本。自建：硬件与人力成本高、需自建高可用与备份、运维风险大，但可一次性资本化、无云厂商绑定、对特定负载可极限优化。结论：中小企业、追求快速上线与免运维时云数据库 TCO 更低；大规模、长期稳定、有专业 DBA 团队时自建可能更省，需按实际负载建模对比。

TCO 不等于云单价，要算上运维人力、停机损失、扩展成本。云的优势是"免运维+弹性"，自建的优势是"可资本化+无锁定"。对比 TCO 需结合团队规模、负载画像与风险偏好。

• 云厂商自动化的运维范围
• 仍需人工介入的环节
• 运维责任共担模型

云数据库（PaaS）自动化运维覆盖：硬件故障替换、存储扩容、自动备份/恢复、高可用故障转移、补丁与版本升级、监控告警等，这些由云厂商负责。但仍有大量人工介入点需要用户负责：业务级 Schema 与索引设计、慢 SQL 优化、容量规划与规格选择、数据迁移与校验、安全策略（账号、权限、网络）、应用重试与降级设计、成本管理等。即"云厂商管资源，用户管业务与数据"。理解责任共担模型，才能明确哪些靠云、哪些靠自己。

自动化运维边界 = 云厂商管"基础设施与替身运维"，用户管"业务建设与数据治理"。误以为 PaaS 全自动会出问题（如不优化索引、不做容量规划）。明确边界是高效用云的关键。

• 小版本升级的意义
• 自动升级的时机与风险
• 升级策略与窗口

云数据库小版本升级（minor version upgrade）通常包含 bug 修复、安全补丁与性能优化。自动小版本升级策略需权衡"及时修复"与"稳定可测"：可设置升级维护窗口（如业务低峰期），指定自动升级的时间段；或采取"先在测试环境验证 → 再随意参加维护窗口自动升级"的分阶段策略。风险是升级可能引入行为变化或导致短暂连接中断，因此应配置通知、在窗口内升级、并做好升级前后验证与回滚预案。对有严格 SLA 的场景，可关闭自动升级、手动在可控时间升级。

自动升级策略 = 及时获得修复 + 控制升级风险。核心是"维护窗口 + 分阶段 + 验证回滚"。小版本升级虽小，也需纳入变更管理，避免在生产高峰期意外升级。

• MPP 的 spill 到磁盘机制
• 与单机临时文件机制的异同
• 内存溢出与性能影响

MPP 数据库在聚合/排序超出内存时，会把部分数据 spill（溢写）到本地磁盘临时文件，采用外部归并排序（external merge sort）或部分聚合溢写：先把内存中的数据写成有序的临时段，再在最终阶段归并/汇总。与单机数据库的临时文件机制相似处：都通过"内存 + 磁盘临时文件 + 归并"处理超内存数据，避免 OOM。不同处：MPP 的 spill 发生在每个 segment 节点本地，各节点并行溢写，网络不参与；且 MPP 的 spill 影响是局部的（某节点溢写拖慢该节点，可能造成倾斜），而单机是单一的。大量 spill 会显著降低性能（磁盘 IO 替代内存），因此需优化内存配置与查询。

spill 是"内存不够换磁盘"的兜底，本质都是外部排序/溢写聚合。MPP 的差异在于把 spill 分散到各节点，且节点间不平衡会造成倾斜。减少 spill（调大内存、优化聚合顺序）是 MPP 性能优化要点。

• 容量规划的因素（QPS、连接数、存储）
• 实例规格的估算方法
• 预留容量 vs 自动扩容的取舍

容量规划需综合 QPS（每秒查询数）、TPS、并发连接数、存储增长速率、CPU/内存/IO 需求。估算方法：根据峰值 QPS 与单查询成本估算 CPU 核数；根据并发连接数与单连接内存估算内存；根据日均写入量与保留周期估算存储增长，预留 Buffer。设计上常按"峰值负载 + 一定余量"选规格，再结合监控校准。预留容量 vs 自动扩容的取舍：预留容量（固定规格）适合负载稳定、可预测、要求性能可控的场景，成本可控；自动扩容（Serverless/弹性）适合负载波动大、难预测的场景，按需付费但需接受扩容速度与上限。取舍依据是"负载可预测性 + 性能确定性 + 成本偏好"。

容量规划 = 量化负载 + 估算资源 + 预留余量。可预测负载用预留（稳、省），不可预测负载用自动扩容（灵活、按需）。核心是"算清峰值、留足余量、选对弹性形态"。

• 审计日志的开启与内容
• 日志归档与保留
• 审计与合规的平衡（脱敏、最小化）

云数据库审计日志记录数据库访问行为（登录、SQL 执行、权限变更等），可通过控制台/参数开启，输出到日志服务（如 CloudWatch/OSS）便于查询与归档。归档策略按合规要求设置保留周期（如 3 年），并配置存储分区与生命周期。审计与合规的平衡：审计需保留足够信息以追溯，但日志含敏感数据（SQL 中的明文、IP、账号），需做脱敏（掩码敏感字段）、限制访问权限、最小化采集（只审计必要操作），避免过度采集造成存储与隐私风险。即"该留的留、该藏的藏、该省的省"。

审计是合规要求，但也要平衡成本与隐私。关键是"保留期满足合规 + 敏感字段脱敏 + 访问受限 + 采集最小化"。这是数据库审计治理的常见平衡点。

• SMP（对称多处理）并行
• MPP 的节点级并行
• 两者的层次与协同

SMP（对称多处理）指单机内多核多 CPU 共享内存/总线的并行，对应"单机内并行"（如多线程/多核并行执行算子）。MPP 指多节点（多台机器）的并行，对应"集群级并行"。两者是不同层次：MPP 的每个节点内部仍是 SMP（多核并行），每个节点既跑自己的并行算子，又通过 MPP 协调跨节点并行。因此层次关系是"MPP 在节点间并行，SMP 在节点内并行"，是包含关系（MPP 节点内用 SMP）。优化时两者都会影响性能：单核效率（SMP）与节点扩展（MPP）。

SMP 是"单机多核"，MPP 是"多机并行"。MPP 节点内即 SMP，二者叠加。理解层次关系，才能区分"节点内并行度"与"节点间并行度"的优化。

• MPP 节点故障的影响
• 查询重试与恢复
• 高可用设计

MPP 集群中，任一节点（segment）故障会导致该节点上的数据与任务不可用，正在执行的查询可能失败。MPP 通过数据冗余（如镜像/副本）与故障恢复：节点故障时，其副本接管，集群重新分配任务；查询层面，失败的查询需要重新提交/重试（MPP 通常是"查询失败、由上层重试"而非原子重放）。部分 MPP 支持段级故障检测与自动恢复、查询失败重跑。设计上，主节点（QD）负责监控与协调，节点故障时尽量隔离故障、重平衡数据，并配合应用层重试。也强调"节点故障需快速恢复数据副本，避免影响后续查询"。

MPP 的节点故障处理依赖"数据副本 + 任务重试"。查询本身可能失败，需要上层重试；数据的恢复靠副本与重平衡。理解这一点才能设计 MPP 的可用性与重试策略。

• 扩容与数据重分布的原因
• 重分布期间的读写影响
• 迁移窗口的规划

MPP 集群新增节点后，各节点数据不再均衡（新节点无数据），为保证数据均匀分布、充分利用新节点并行能力，需要进行数据重分布（如 Greenplum 的 gpexpand），按哈希分区把数据重新分布到所有节点。重分布是数据密集操作，会占用大量 CPU/IO/网络，期间对读写性能有影响（尤其对原有数据分区），且可能造成数据暂时不一致（分阶段）。因此迁移窗口规划：选择业务低峰期执行，分批/分表重分布，控制并发与限速，监控进度，尽量在维护窗口内完成并做校验。规划的核心是"错峰、分批、限速、校验"。

扩容必须重分布才能让新节点"有活干"，否则负载倾斜。重分布是重操作，需在窗口内错峰进行，控制影响。理解"为什么重分布 + 怎么控制影响"是 MPP 扩缩容运维的关键。