PostgreSQL OLAP新高度 - CPU向量计算及瓦片式存储.docxVIP

PostgreSQL OLAP新高度 - CPU向量计算与瓦片式存储本文章来自于阿里云云栖社区摘要：?标签 PostgreSQL , OLAP , 向量化 , vector , postgrespro , tiles , 瓦片 , 瓦片索引 , map , reduce , 分组聚合 , 非分组聚合 , 分区键 , sort key , order by , brin , cpu Cache , projection , 行列变换背景在主流的OLTP数据库产品中，毫无疑问，PostgreSQL已经具备非常强大的竞争力（性能、功能、稳定性、成熟度、案例、跨行业应用等）。标签PostgreSQL , OLAP , 向量化 , vector , postgrespro , tiles , 瓦片 , 瓦片索引 , map , reduce , 分组聚合 , 非分组聚合 , 分区键 , sort key , order by , brin , cpu Cache , projection , 行列变换背景在主流的OLTP数据库产品中，毫无疑问，PostgreSQL已经具备非常强大的竞争力（性能、功能、稳定性、成熟度、案例、跨行业应用等）。《数据库选型之 - 大象十八摸 - 致架构师、开发者》（原文链：/digoal/blog/blob/master/20170201.md?spm=5176.100239.blogcont70993.17.UKDSBnfile01.md）《数据库选型思考》（原文链接：/digoal/blog/blob/master/20170203.md?spm=5176.100239.blogcont70993.18.iWIN23file03.md）《数据库界的华山论剑 》（原文链接：/digoal/blog/blob/master/20170101.md?spm=5176.100239.blogcont70993.19.NJsNISfile01.md）《PostgreSQL 前世今生》（原文链接：/digoal/blog/blob/master/20160902.md?spm=5176.100239.blogcont70993.20.fv1eyJfile02.md）在OLAP领域，PostgreSQL社区也是豪情万丈的，比如内核已经实现了基于CPU的多核并行计算、算子复用等。在社区外围的插件如 GPU运算加速、LLVM、列存储、多机并行执行插件等也层出不穷。虽然如此，PostgreSQL在OLAP领域还有非常巨大的提升潜力。OLAP profiling 分析 (OLAP哪些过程最耗资源)OLAP单个查询就会涉及大量数据的处理，与OLTP有非常鲜明的差别，那么数据库在OLAP场景会有哪些明显的瓶颈呢？1. unpack row(tuple) 带来的开销在PostgreSQL中，数据以行存储，变长类型可能存储在TOAST中，由于它是变长的，当访问第N列的数据时，也需要unpack前N-1列的内容数据（不过这块有优化空间，比如在行头记录每列的OFFSET，但是这样又引入另一个问题，增加了OFFSET必然会增加空间开销）。另一种优化方法是业务层面的，比如将定长类型和变长类型拆分成两张或多张表，或者将不怎么访问的大字段拆开到其他表，通过JOIN关联它们。不要小看这笔开销，这笔开销是O(N)的，所以数据量越大，开销越大，比如TPCH的Q6，40%是ROW格式化带来的开销。2. 解释执行引入的开销PostgreSQL的优化器通过构建树的方式来表述执行计划，所以执行器必须以递归的方式从树的最边缘节点一直往上执行。解释执行的好处是弹性，容易改写，比如PG的customize scan ，GPU运算就用到了它。通常解释执行比native code慢10倍，特别是在表达式非常多时。你可以通过这种方式观察postgres=# set debug_print_plan=true; postgres=# set client_min_messages =log; postgres=# select 1; LOG: plan: DETAIL: {PLANNEDSTMT :commandType 1 :queryId 0 :hasReturning false :hasModifyingCTE false :canSetTag true :transientPlan false :planTree {RESULT :startup_