基准测试（TPC-H/TPC-DS/YCSB）与迁移工具

• TPC-H 基准构成
• 22 个查询类型
• 决策支持负载覆盖

TPC-H 是面向决策支持（分析）的业界标准基准，由 22 个查询（Q1-Q22）与两类更新操作组成，模拟企业经营分析负载。这 22 个查询覆盖了丰富的分析 SQL 特性：多表连接（多路 join）、分组聚合（GROUP BY）、子查询（相关/非相关）、窗口函数、排序、去重、IN/EXISTS 等，且包含大量对事实表的高基数扫描与过滤。它通过相对固定的数据规模（SF=1GB 等）度量查询吞吐与单查询性能，是衡量数据库联机分析处理（OLAP）能力的重要标尺。

TPC-H 的价值在于"标准、可复现、覆盖全面"。其查询大多体量大、涉及多表与复杂算子，能反映数据库在真实分析负载下的优化能力（join 顺序、聚合策略、并行度、索引/列存等）。

• pgloader 工具
• 多源数据导入
• 自动类型转换

pgloader 是一个开源的数据迁移工具，可将 MySQL、SQLite、CSV、MS SQL 等数据源导入 PostgreSQL，并支持 PostgreSQL 到 PostgreSQL 的迁移。它内置了类型映射规则，能自动把源库的类型（如 MySQL 的 int、varchar、datetime、tinyint 等）转换为 PostgreSQL 对应类型（integer、text、timestamp、boolean 等），减少手工改写。pgloader 通过 TOML 或命令行配置定义源与目标、表映射、过滤条件，内部使用 COPY 协议批量加载，配合并发与错误记录，迁移速度快且可靠。

自动类型转换是 pgloader 的核心价值，避免逐列手工迁移。它把"源 schema → 目标 schema"的映射规则化，配合 COPY 批量写入，兼顾正确性与吞吐。

• COPY 协议
• 批量加载
• 避免逐行 INSERT

pgloader 的写入端使用 PostgreSQL 的 COPY 协议把数据批量灌入目标表，而不是逐行执行 INSERT。COPY 将整批数据以二进制或文本格式一次性、内部绑定地写入，减少了每条记录的解析、SQL 解析、网络往返与事务开销，加载速度远高于逐行 INSERT。pgloader 还会并行读取源、按批次提交，结合错误重试与日志。相比逐行 INSERT（每行一个事务或语句），COPY 批量模式是数据迁移/导入的标准高性能手段。

逐行 INSERT 的瓶颈在于"每行一条语句"的固定开销（解析、绑定、日志、网络）。COPY 把成批数据交给存储引擎内部批量写入，通常能获得数量级的吞吐提升，同时对大表迁移至关重要。

• AWS DMS 迁移模式
• 全量 + 增量/CDC
• 持续复制与同步

AWS DMS（Database Migration Service）支持三种迁移模式：全量迁移（一次性复制现有数据）、全量 + 增量（先全量复制，后捕获变化继续同步，即 CDC）、仅增量复制（从已有基线开始持续同步变化）。CDC（Change Data Capture）通过解析源库事务日志/redo 捕获变更，实时把 INSERT/UPDATE/DELETE 应用到目标，实现数据持续同步，常用于数据库迁移的停机窗口控制、双写校验与持续灾备。全量 + CDC 是最常见的迁移方式：以全量建基线，再以 CDC 追平增量，最终切换。

全量 + CDC 的关键是"追平"与"切换"：全量把存量搬过去，CDC 让增量持续流入，待两边追平后短窗口切换，降低停机时间。这是生产迁移的标准做法。

• AWS SCT 工具
• schema 自动转换
• 异构迁移

AWS SCT（Schema Conversion Tool）是 AWS 的异构数据库迁移辅助工具，用于把 Oracle、SQL Server、DB2 等商业数据库的 schema（表、索引、视图、存储过程、函数、触发器、包等）自动转换为 PostgreSQL、MySQL、Aurora 等目标数据库的 schema。它解析源 DDL，按内置规则映射类型、函数与语法，并对无法自动转换的对象（如复杂存储过程、专用函数）标记为需人工改写，输出评估报告。SCT 常与 DMS 配合：SCT 负责 schema 转换与对象评估，DMS 负责数据迁移。

SCT 的价值在"自动化 + 评估"。它把大量可转换的 schema 机械转换，把不可转换的（复杂 PL/SQL、特殊语法）显式列出，让迁移团队聚焦人工改造，降低异构迁移风险。

• Liquibase changelog
• 变更集（changeset）
• 多格式描述

Liquibase 是一个数据库变更管理（schema 迁移）工具，用 changelog 文件描述数据库变更，支持 XML、YAML、JSON 与 SQL 格式。changelog 由多个 changeset 组成，每个 changeset 包含 id、author、changes 等属性，changes 描述具体操作（createTable、addColumn、createIndex、sql 等）。Liquibase 通过 CHANGELOG 的 id 与 checksum 跟踪哪些 changeset 已执行，未执行的自动应用于目标库，实现版本化、可重复的 schema 管理。它支持上下文与标签控制执行范围，并可在多环境回放。

changelog 把数据库变更"代码化、版本化"，团队可像管理代码一样管理 schema。多格式（XML/YAML/JSON/SQL）让不同团队选择熟悉的方式，changeset 的幂等与 id 追踪保证可重复执行。

• 数据库 + ES 协同
• 数据同步（binlog/CDC）
• 读写分离与查询分流

常见架构是"关系库（MySQL/PostgreSQL）承担事务与权威数据，Elasticsearch 承担全文检索与复杂查询"。数据通过同步机制从数据库流入 ES：用 CDC（如 binlog、Debezium、logstash）捕获变更，或应用双写（事务内写库后写 ES）。查询时，结构化/事务查询走关系库，全文、模糊、聚合、地理等查询走 ES，两者协同。同步需处理一致性（双写失败、延迟）与幂等，通常用"强一致库 + 异步近实时 ES"模型，接受秒级延迟。

协同的核心是"各司其职 + 数据同步"。数据库保证 ACID 与权威，ES 提供倒排索引与高并发搜索。同步链路的可靠性（重试、幂等、对账）是架构成败关键。

• TPC-DS 基准
• 99 个查询
• 数据仓库负载特征

TPC-DS 是面向决策支持/数据仓库的业界标准基准，由 99 个查询（Q1-Q99）与数据维护操作组成，模拟真实零售/电商企业分析。相比 TPC-H，TPC-DS 的 schema 更复杂（多事实表、多维度、雪花模型），查询更贴近真实数据仓库：大量多路 join、子查询、窗口函数、OLAP 聚合、数据倾斜、相关子查询与复杂表达式，且覆盖高并发的分析会话。它更强调"真实业务分析"的多样性，因此被广泛用于衡量 MPP、数据仓库与 OLAP 引擎的分析能力。

"更接近真实"体现在语义复杂度与数据分布（如倾斜、季节相关性）。TPC-DS 的 CBase 方法论可复现，99 个查询覆盖从简单扫描到复杂多级聚合的完整谱系，是 OLAP 引擎优化与基准对标的权威依据。

• YCSB 基准
• 6 种工作负载 A-F
• 混合读写比例

YCSB（Yahoo! Cloud Serving Benchmark）是面向 NoSQL/云数据库的基准，定义 6 种核心工作负载，每种有不同的读写混合比例：

• A：Update Heavy（50% 读 / 50% 写）
• B：Read Heavy（95% 读 / 5% 写）
• C：Read Only（100% 读）
• D：Read Latest（95% 读 / 5% 插入，读取最新插入的数据）
• E：Short Ranges（95% 扫描 / 5% 插入）
• F：Read-modify-write（50% 读 / 50% 读-改-写） 覆盖读、写、扫描、插入与更新混合，模拟不同应用特征的键值负载。YCSB 通过 workload 配置文件控制分布与比例，并支持脚本化压测。

A-F 的梯度覆盖了从读多写到写多的各类访问模式，让用户能对比不同数据库在特定负载下的表现。负载的分布（随机/zipfian）与比例决定了吞吐与延迟特征。

• YCSB workload 配置
• 自定义模板
• 参数化负载

YCSB 通过 properties 文件（workload 模板）定义负载参数，包括：操作分布（recordcount、operations、readproportion、updateproportion、scanproportion、insertproportion）、数据分布（requestdistribution: uniform/zipfian/latest）、字段数、扫描长度、线程数等。用户可自定义 .properties 文件组合这些参数，模拟特定业务负载（如热点访问 zipfian、最新数据 latest、混合读写比例），也可用 -P 指定多个模板叠加。这种"参数化"让 YCSB 能灵活模拟真实应用场景而不局限于内置 A-F。

自定义模板是 YCSB 可扩展性的体现。通过调整分布与比例，可以复现"热点倾斜""读多写少""扫描密集"等真实模式，从而更准确地评估数据库在目标场景下的表现。

• YCSB 与 NoSQL
• MongoDB/Cassandra 对比
• 键值负载适配

YCSB 最初为云端 NoSQL 服务设计，其"键值 + 行式"的数据模型与读/写/扫描/插入操作天然贴合 MongoDB、Cassandra、HBase、ScyllaDB 等 NoSQL 数据库。由于这些数据库没有统一 SQL，YCSB 通过统一的键值接口（get/put/scan/update/insert）做黑盒压测，记录吞吐与延迟，从而在相同负载下对比不同 NoSQL 的读写性能、扩展性与一致性。它常被用于选型对比、容量评估与集群规模的横向度量。

统一接口 + 可配置负载使 YCSB 成为 NoSQL 横向对比的标准工具。但对比需注意各库的一致性级别、索引与事务差异，避免"同负载但不同语义"的误读。

• pgloader 命令行
• source/target 定义
• 并发加载

pgloader 通过命令行参数与 TOML 配置文件指定 source 与 target：命令行可用 pgloader mysql://src postgresql://dst 形式直接给出源、目标连接串，也可用 TOML 文件详细描述（含表映射、过滤、并发数）。pgloader 支持并发加载：可配置多个 worker/线程并行读取源数据并写入目标，通过 workers、concurrency 参数控制并行度，从而显著提升迁移吞吐。它还会自动分批、记录错误、支持断点续传。

命令行直接指定源与目标使简单迁移一行命令完成；TOML 用于复杂场景。并发把 CPU/IO 与网络带宽利用起来，是加快大表迁移的关键，但需注意目标端负载与一致性。

• 过滤条件
• 表映射
• 迁移定制

pgloader 在 TOML 配置中支持丰富的过滤与映射规则：可按表名/正则过滤（include/exclude），按列或条件过滤部分行（partial migration），以及表级别的重命名与映射（table -> table、quoting、schema 映射）。例如可指定"只迁移指定的表"、"跳过某些列"、"把源表 A 映射到目标表 B"、"仅迁移最近 N 天的数据"。这些规则让迁移可以按需裁剪，避免全量盲目迁移，也便于在迁移过程中做结构调整。

过滤与映射让 pgloader 从"全量复制"升级为"定制迁移"。生产迁移常需只迁部分表、跳过日志表、重命名字段，这些规则减少手工后处理，提升迁移可控性。

• Replication Instance
• 同步拓扑
• 资源与调度

Amazon DMS 的核心是 Replication Instance（复制实例）：一个托管在 AWS 上的计算实例，负责从源数据库读取数据/捕获变更，并写入目标数据库。Replication Instance 运行多个复制任务（Task），每个任务定义源、目标、迁移模式与表映射。数据流向为：源 → Replication Instance（内存中转）→ 目标。Replication Instance 的规格（CPU/内存/存储）决定复制吞吐，可配置多可用区与故障切换。通过它，DMS 实现全量、CDC 与持续复制。

Replication Instance 是 DMS 的"执行引擎"，相当于一个中转与调度节点。它管理复制任务的并发、错误处理与日志，规格选择直接影响迁移速度与稳定性。

• Endpoints（源/目标端点）
• Tasks（复制任务）
• 配置流程

AWS DMS 用 Endpoints 定义数据库连接：source endpoint 描述源库（类型、主机、端口、凭据、SSL 等），target endpoint 描述目标库。Tasks 定义复制任务，将源 endpoint 与目标 endpoint 关联起来，并指定迁移模式（全量 / 全量+CDC / 仅 CDC）、表映射（table selection 与 transformation）、CDC 选项等。配置流程为：创建 Replication Instance → 创建源/目标 Endpoints → 创建 Task（绑定两端）→ 启动 Task 执行复制。Endpoints 可复用，Tasks 可挂起/恢复/删除。

Endpoints 是"连接的定义"，Tasks 是"复制动作的定义"，二者分离使一个端点可复用于多个任务。表映射与 CDC 配置都挂在 Task 上，实现灵活的数据筛选与同步。

• 异构迁移
• SCT 兼容度评估
• DMS 与 SCT 分工

DMS 主要负责"数据迁移"（行级数据与 CDC），而"对象兼容度"（schema、存储过程、函数、类型、约束等能否在目标库运行）是异构迁移（如 Oracle→PostgreSQL、SQL Server→MySQL）的核心难点。SCT 负责评估并转换这些对象：解析源 schema 与存储过程，判断哪些可自动转换、哪些需人工改写，输出兼容度报告。因此异构迁移通常先由 SCT 评估对象兼容度并转换 schema，再由 DMS 迁移数据，两者配合才能完成"对象 + 数据"的完整迁移。

数据迁移容易，对象兼容难（尤其 PL/SQL、包、函数、类型映射）。SCT 把"哪些能转、哪些要改"显式化，DMS 保证数据流，二者互补是 AWS 异构迁移标准流程。

• Flyway 命名约定
• 版本化迁移
• 迁移文件管理

Flyway 采用"版本化迁移"方式管理数据库变更，迁移文件遵循命名约定 V<n>__<description>.sql，其中 <n> 是递增版本号（如 V1__init.sql、V2__add_user.sql），description 是描述。Flyway 按版本号顺序执行这些迁移脚本，并记录已执行版本。未执行过的脚本按版本顺序执行，已执行的不重复执行。此外还有 R__（可重复执行）与 U__（回滚）类型。命名约定让迁移"有序、可追溯、版本化"，配合 flyway_schema_history 表保证幂等。

命名约定是 Flyway 的核心：版本号决定执行顺序，描述承载语义。团队把每次 schema 变更写成版本化 SQL 文件，部署时 Flyway 自动按序应用，实现可重复、可审计的数据库演进。

• flyway_schema_history 表
• 版本跟踪
• 幂等与校验

Flyway 在目标数据库创建一张 flyway_schema_history 表，记录每次已执行的迁移：版本号、描述、类型、成功标志、执行时间、checksum 等。每次执行迁移前，Flyway 读取该表确定已应用版本，只执行未被记录的迁移；同时对已执行迁移的 checksum 做校验（若文件内容被改动且 checksum 不匹配则报错），防止迁移脚本被篡改。通过这张表，Flyway 保证"同一迁移只执行一次"，并支持 repair 修复不一致状态。

flyway_schema_history 是 Flyway 的"状态簿"，让迁移幂等且可审计。checksum 校验防止"改了已上线的脚本"造成不一致，是生产安全的关键。

• context（上下文）
• label（标签）
• 环境差异化执行

Liquibase 的 changeset 可通过 context 与 label 属性标记，用于控制其在哪些环境/场景执行。context 是"命名上下文"（如 context="dev/prod"），运行时指定 --contexts=prod 只执行匹配上下文的 changeset；label 是"标签"（如 label="DBA_APPROVED"），运行时用 --labels 过滤。二者支持 include/exclude 语法，使同一 changelog 在不同环境（开发/测试/生产）差异化执行，例如生产环境才执行某些数据初始化或特定索引。context 与 label 可组合使用。

环境差异是 schema 管理的普遍难题。context/label 在同一 changelog 内做"按环境裁剪"，避免为每个环境维护不同 changelog，同时保证可追溯与可审计。

• baseline 基线
• repair 修复
• 生产回填

baseline 用于"在已有数据库上引入迁移工具"：当数据库已存在（非空库）时，执行 baseline 命令可把当前 schema 状态标记为基线（Flyway 的 baseline 会插入一条 baseline 记录，Liquibase 的 changelogSync 标记已应用变更），这样后续迁移只从基线之后的版本开始，避免对已存在的库重复执行早期脚本。repair 用于修复不一致状态：Flyway 的 repair 删除失败的迁移记录、更新 checksum 或补记已应用但未记录的迁移；Liquibase 的 clearCheckSums/update 类似。二者共同支撑"对已有生产库平滑回填迁移历史"。

生产库已有数据时无法从零执行全部迁移，baseline 把"现状"作为起点，repair 修正"历史记录与文件不一致"，两者结合让工具能安全地"回填"到已在运行的系统。

• 各数据库 SQL 方言差异
• 函数/类型/语法差异
• 迁移改写注意点

TPC-H 的 22 个查询在不同数据库上存在方言差异：日期/时间函数（如 EXTRACT、date_add、toDate）、字符串函数（substr、substring）、类型转换（CAST、::）、LIMIT 语法、COUNT(DISTINCT)、窗口函数支持、参数化（?/$1）等不尽相同。MySQL 与 PostgreSQL 有类型与函数差异（如 group_concat vs string_agg）；ClickHouse 强调函数名与 *GLOBAL、ANY 等语义；DuckDB 支持标准语法但部分函数名不同。迁移改写需核对这些差异，并注意 NULL 语义、隐式类型转换、聚合与排序的确定性。

迁移改写的关键是"语义等价 + 方言适配"。逐查询核对函数、运算符、类型、NULL 处理，并在目标库上跑结果对比（行数、求和）验证正确性，避免"语法能跑但结果不同"。

• 图模型转换
• 节点/边/属性
• 迁移工具链

Neo4j 与 NebulaGraph 都是属性图数据库，但存在差异：Neo4j 用 Cypher 查询、节点/关系有标签（label）与类型，NebulaGraph 用 nGQL、顶点/边有 tag/edge type。迁移时需做模型映射：Neo4j 的 label → NebulaGraph 的 tag，relationship type → edge type，属性类型与索引/约束需对照转换；同时 Cypher 语法需改写为 nGQL。工具链上可用 Neo4j 导出（apoc、export CSV）→ 中间文件 → NebulaGraph 导入（nebula-importer、exchange），或用自研脚本/ETL 转换。评估需测试数据一致性（节点/边数量、属性值）、性能（导入吞吐）与查询兼容度。

图迁移的难点在于"模型语义映射"而非纯数据搬运。label/tag、关系类型、属性类型、索引、约束的映射正确性决定迁移质量，工具链评估需兼顾数据正确性与查询性能。

• TPC-C vs TPC-H
• OLTP vs OLAP 定位
• 性能验证

TPC-C 是 OLTP 基准，模拟事务型应用（订单、库存、支付），特点是大量短小明细事务、高并发读写、索引点查/小范围更新、强调事务吞吐与延迟（tpmC）。TPC-H 是 OLAP 基准，模拟分析型负载，特点是复杂大查询、多表连接、聚合扫描、强调查询响应时间与吞吐。迁移前后性能验证应分别用对应基准：对事务型系统用 TPC-C 类负载验证并发与事务性能，对分析/数据仓库用 TPC-H/TPC-DS 类负载验证查询性能，二者定位不同，不能互相替代。

OLTP 与 OLAP 的优化方向相反（索引 vs 列存、点查 vs 扫描、事务 vs 聚合）。迁移验证需按系统属性选择匹配的基准，并对比迁移前后的吞吐、延迟、资源占用，确保目标库在对应负载下达标。

• elasticdump / reindex / Logstash
• 数据同步迁移
• 一致性校验

Elasticsearch 数据迁移常用工具：elasticdump 逐条导出/导入 JSON（适合小规模、可带过滤）；reindex（_reindex API）在集群内/跨集群间批量重建索引，支持从快照/远程重建，性能好；Logstash 作为通用管道从源（如数据库、ES）读取并写入目标，可做转换。一致性校验常用：对比文档总数、按 _id 或字段抽样比对、用 _search 统计聚合值对比、比对时间戳/版本号，甚至用脚本对源与目标做逐条 hash 比对。为控制一致性，常配合"先存量再增量追平"的策略。

迁移的核心是"数据不丢、不重、一致"。reindex 适合大批量，elasticdump 适合灵活导子集，Logstash 适合异源管道；校验则是迁移的兜底，需在切换前后都做数据与文档数对账。

• 跨库结果可比性
• 一致性级别差异
• 索引与事务差异

YCSB 提供统一键值接口，但不同数据库的语义差异使其结果不能简单直接比较：一致性级别不同（强一致 vs 最终一致，读己之写、单调读等），同样负载可能允许不同"准确度"；索引与存储结构不同（是否建二级索引、LSM vs B+Tree），影响读写成本；事务支持不同（是否 ACID、是否多行事务、是否原子性保证），YCSB 默认的原子操作在不同库下语义不同。因此解读时需明确：在各库"等价配置（索引、一致性、副本数）"前提下比较，注意延迟/吞吐差异可能来自一致性成本而非原生性能，并说明事务与隔离假设。

YCSB 数字可对比但不是"公平的绝对对比"。跨库解读要控制变量（一致性、索引、副本），并理解"快"可能来自"更宽松的一致性或更少的保证"，需结合业务一致性要求解释结果。

• Lucene/Solr → ES/OpenSearch
• 兼容性评估
• 索引重建成本

Lucene 是底层全文库，Solr 与 ES/OpenSearch 都基于 Lucene，但 API、schema 与集群模型不同。迁移 Lucene/Solr 到 ES/OpenSearch 需评估：索引格式（Lucene 版本兼容性，可直接挂载或需重建）、schema 映射（Solr 的 fieldtype/analyzer 改写为 ES mapping）、查询语法（Solr 的 q/DisMax 改写为 ES query DSL）、配置（solrconfig 对应 ES 的 settings）。由于 Lucene 版本差异，通常无法直接复用旧索引，需重建：重建成本 = 全量 reindex（读源数据 + 重新分析 + 写入新索引）+ 副本/分片 + 存储，可通过滚动重建、多副本并行与快照加速。评估需量化数据量、重建耗时与索引体积。

兼容性关键在于"索引格式与查询 API"。能复用 Lucene 数据则省去重建，否则成本主要在 reindex 的 CPU/IO 与磁盘。迁移前需评估索引重建时间窗与切换策略。

• 增量同步位点管理
• 断点续传
• 一致性校验

增量同步阶段，迁移工具维护"位点"（position）记录已消费到源库的哪个位置（如 MySQL binlog 坐标、PostgreSQL WAL/LSN、Oracle redo log position）。位点管理的关键是：断点续传（工具崩溃后从保存的位点继续，不重不漏）、位点持久化（存于目标端或元数据表）、延迟监控（源与目标位点差）。目标端一致性校验常用：行数对比、关键字段 min/max/sum 聚合对比、按主键抽样比对、以及"双写/对账"窗口内的数据比对。增量同步还可能做"校验 + 修复"闭环，确保追平后数据一致。

位点是增量同步的"进度指针"，管理好位点才能保证不丢不重；一致性校验是增量+切换的最终保障。两者结合确保"追平可切换、切换后一致"。