在之前的文章中，我们介绍了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 虽然经过了大量优化，但绝大多数情况下使用起来和其他类型的表并无区别。
如何使用：
1. 创建表时显式的声明 USING MARS3，就会使用 MARS3 作为存储引擎
CREATE TABLE metrics (
ts timestamp,
dev_id bigint,
power float,
speed float
) USING MARS3 -- 使用 MARS3 存储引擎
DISTRIBUTED BY (dev_id)
2. MARS3 存储引擎支持 UPDATE/DELETE， 无论是查询还是其他操作都可以使用标准的 SQL 直接进行操作
3. MARS3 还支持 ORDER BY 操作，当指定了排序键时，数据会根据指定的排序键存储，在一些场景中（特别是按排序键进行点查的场景），还能提升 30% 以上的效率
CREATE TABLE metrics (
ts timestamp,
dev_id bigint,
power float,
speed float
) USING MARS3
ORDER BY (dev_id,ts) --- 排序键
DISTRIBUTED BY (dev_id)
4. MARS3 支持 Brin 索引，还有包括压缩在内的更多可灵活配置的参数，具体可参考文档：https://ymatrix.cn/doc/6.4/reference/storage/intro
📞 想进一步了解？
若您想了解更多测试结果？需要 Greenplum 迁移技术方案？欢迎留言或联系我们的数据库专家。
感谢你的阅读，YMatrix 期待与志同道合的你一起同行。
