很多 Greenplum 用户都在关心这样一个问题：如果我们什么都不改，迁移到 YMatrix，性能能提升多少？如果进一步使用 YMatrix 的存储引擎 MARS3，又能快多少？
本期我们基于 TPC-H 标准测试，回答这两个问题。
在之前的文章中，我们介绍了YMatrix 与 Greenplum 的相同与不同，简而言之，从 Greenplum 迁移至 YMatrix， 能够在上层应用基本无改动的情况下，获得三大收益：
分析更高效
压缩比更高
服务更可靠
本期将聚焦其中的分析，通过实测结果给出明确答案，并展示如何通过合理使用 YMatrix 的 MARS3 存储引擎，实现大幅性能跃升。
TPC-H 是针对分析型场景，被广泛采用的的一个基准测试，用以衡量数据库系统在复杂分析查询和 BI 工作负载下的性能。
它模拟一个供应链管理业务的模型，包含 8 张规范化的表，具体的查询均基于真实的场景，涉及销售分析、库存管理、客户行为分析、供应商评估等。
比如：
分析特定时间段内收入变化趋势(Q1,Q5)
识别销售表现最好的地区(Q3,Q7)
分析不同供应商提供的零件成本差异(Q2,Q16)
预测哪些订单可能会延迟发货(Q12,Q21)
计算客户购买行为的市场份额变化(Q8,Q18)
从查询复杂度、负载多样性上也覆盖非常全面：
查询复杂度从简单到高度复杂不等
包含各种 SQL 特性(聚合、子查询、连接等)
包含并发数据修改操作
覆盖计算密集型和连接密集型查询
本次测试环境并非高配，但仍能清晰地反映系统间的真实性能差异。本次测试环境并非高配，但仍能清晰地反映系统间的真实性能差异。
本次测试结果来源于 YMatrix 开发过程中进行常规基准测试。虽然硬件规格不高，但也能很好的反映出 Greenplum 与 YMatrix 之间在相同或不同的存储引擎中的性能差异：
CPU：8c
内存：64G
部署方式： 1 主角点 + 2 数据节点（每个数据节点上 2 个实例)
Greenplum version: 6.26.4
YMatrix version: 6.3.0
数据量：100 GB (比例因子 = 100)
Heap 是 Greenplum 的默认存储引擎，目前也是 YMatrix 的默认存储引擎。
作为继承自 PostgreSQL 的经典存储引擎，Heap 存储能够更好的支持写入、更新、删除等操作，但是作为行存，在大数据分析型场景中表现不佳。
受益于计算引擎和其他组件的优化，虽然 Heap 存储引擎不是 TPC-H 这类场景中的最佳选择，但 YMatrix 也获得了较好的成绩。
AOCO 是 Greenplum 的列式存储引擎，MARS3 是 YMatrix 自研的行列混合存储引擎。二者都具备列式存储的优势，能够提升数据库在大数据量分析型场景中的性能表现。
虽然使用了 AOCO 这样的列式存储，但 Greenplum 的计算引擎仍然是传统的火山式存储引擎，无法充分发挥列式存储的的优势，因此性能提升不明显。
而 YMatrix 的计算引擎经过了全面的向量化改造，能够利用现代 CPU 的 SIMD 指令集实现批量的数据计算，配合 MARS3 存储引擎，性能提升更明显。
基于 TPC-H 的实测结果，即便不使用 MARS3，YMatrix 也能在 Greenplum 基础上实现约 3 倍性能提升。
如果进一步启用 MARS3 存储引擎，整体性能最高可提升至 14 倍以上。更重要的是，使用方式几乎无学习成本，即可实现业务侧“0 改动”的平滑加速。
MARS3 虽然经过了大量优化，但绝大多数情况下使用起来和其他类型的表并无区别。
如何使用：
USING MARS3，就会使用 MARS3 作为存储引擎CREATE TABLE metrics (
ts timestamp,
dev_id bigint,
power float,
speed float
) USING MARS3 -- 使用 MARS3 存储引擎
DISTRIBUTED BY (dev_id)MARS3 存储引擎支持 UPDATE/DELETE， 无论是查询还是其他操作都可以使用标准的 SQL 直接进行操作
MARS3 还支持 ORDER BY 操作，当指定了排序键时，数据会根据指定的排序键存储，在一些场景中（特别是按排序键进行点查的场景），还能提升 30% 以上的效率
CREATE TABLE metrics (
ts timestamp,
dev_id bigint,
power float,
speed float
) USING MARS3
DISTRIBUTED BY (dev_id)
ORDER BY (dev_id,ts) --- 排序键