PostgreSQL数据库技术分析

1、PostgreSQL数据库技术分析PG去“O”，非你莫属目录PG社区的独特性PG的商业能力和创新能力PG 新版本与新特性PG on 云独特性学生为什么应该学PG, PG与其他数据库有哪些独特性, 为什么PG是数据库的未来？/digoal/blog/blob/master/201906/201906 26_01.mdPostgreSQL 社区分析 - 为什么PostgreSQL社区几乎不可能被任 何一个商业公司、国家所控制？/digoal/blog/blob/master/201906/201906 08_02.md社区独特性如果：99%的开源数据库都是被商业公司控制的那么：PG是那1%商业数据

2、库 - 1为什么要开源？2为什么改协议？逐利，培养背书群体，扩大生态，收割大客户。上云是大趋势，“云开源数据库服务” 吞噬开源数据库市 场，用户更多选择的是云服务，而不是商业开源数据库的 企业版。商业开源公司与云发生利益冲突，改协议是必然 的。PG为什么没有被商业公司控制？纯社区sponsors 国家日本3德国3美国11英国1瑞典1澳大利亚2法国1俄罗斯2他们为什么要持续贡献核心代码？数据库厂商推一款新的商业数据库，通常都需要背书，小厂产品，谁为你背书？1、有技术的厂商，很难挑战已有数据库市场格局。2、有渠道的厂商，需要抓住窗口期，快速占领市 场，避免重复造轮子，需要一款可以无法律风险， 二次

3、分发的开源数据库。唯有PG。贡献核心代码，社区所有的用户都可以为之背书数据库服务 | DaaS服务提供商开源产品的服务提供商，能力如何体现？架构能力？优化能力？管理能力？FIX BUG的能力？背书他们为什么要持续贡献核心代码？最终用户希望社区长久，期望可以享受免费的、可持续发展的、开源的、不被任何商业公司、不被 任何国家控制的企业级的数据库。去O(贵)，去DB2去sybase(产品下市、无法再升级、支持)不靠数据库赚钱1、PG用到人越多，越多人背书，使用越靠谱（事实证明是如此，比商业数据库还靠谱），2、抛砖引玉，企业投入2个研发持续贡献(一年可能一两百万)，实际上整个PG社区有数千 人在贡献，

4、对最终用户来说，简直赚到了。使用商业数据库，除了LICENSE等成本，依旧需要投管理、研发、外包资源，一年数千万甚至上亿。公司越大，越有动力去贡献社区。 从趋势来看，给PG贡献代码的大客户只会越来越多。云厂商开源数据库纷纷改协议数据库市场巨大自研是最佳选择自研的问题：需要培养生态，需要市场背书，需要大量研发资源，可能需要重复造轮子？BASE PG， 1 免去自己培养生态，2 避免重复造轮子，3 PG 的代码基础非常不错 (开源界“O”)防止其他厂商控制PG失去市场主导能力(AWS,google,IBM,微软都已进入sponsor行列)开源许可独特性-活雷锋PG的开源许可是类BSD许可。可以随意

5、分发，闭源或开源。架构独特性PG采用了开放接口的设计，例如type, operator, index,storage, language, fdw,custom scan, sample, hook等PG是最具扩展能力的数据库（基于PG的 图数据库、流数据库、GIS、时序数据库、 推荐数据库、搜索引擎等。围绕PG的应用 垂直化插件机器学习、图像识别、分词、 向量计算、MPP等。）基本上都是使用PG扩展接口扩展出来的商业趋势1、全球都在提高安全、合规、正版化意识2、PG是去O首选3、PG是数据库厂商首选，避免重复造轮子，前面说了PG的功能覆盖度高，是很好的基础。同时扩展性很强很容易做出行业特色，

6、最重要的是它的开源许可允许任意的使用（分发、闭源）。4、PG 是云首选很多开源数据库的背后有商业公司，商业公司如果和云厂商没 有很好的合作协议。云厂商拿去卖，客户被带上云，数据库厂 商的利益与与云厂商的利益发生冲突的概率非常大。商业数据库厂商被迫修改许可协议是一种手段。PG是纯社区开源数据库，没有修改协议的动机。PG的协议干净，是云厂商首 选。技术趋势1、PG是多模数据库，因为它的开放性，可以 随意扩展。例如前面提到的诸多插件，使得PG 是目前最强度大的多模数据库。2、内置并行计算3、支持存储引擎扩展(12)。4、对芯片友好，例如ARM芯片的支持。以上4点满足市场的既要又要还要的需求：既要SQ

7、L通用性，又要NOSQL扩展性，还要多模开发便捷性。既要OLTP又要OLAP。目录PG社区的独特性PG的商业价值与创新价值PG 新版本与新特性PG on 云多模Oracle兼容企业级混合负载创 新 价 值商 用 价 值0丢失+高可用:quorum based sync repl安全:SSLSQL防火墙TDE(13)弹性:插件化 shard模块化扩展 性能:32C TPCC 100万+并行计算OLTP、OLAP、SMP并行计算、GPU并行计算、 实时分析、 列存储、JIT、向量计算时空、GIS、图像 文本、时序、 向量相似、图谱 流计算、异构、 机器学习、多维计算、shard降低迁移成本。 社区

8、版： ora2pg+orafce阿里云版：ADAM+PPAS目录PG社区的独特性PG的商业能力和创新能力PG 新版本与新特性PG on 云PG版本发布节奏PG 11分区表增强并行计算增强btree index include索引叶子附加属性添加字段（含默认值）更快支持存储过程分区表增强hash分区支持触发器支持默认分区允许修改分区字段并行计算增强/digoal/blog/blob/master/201903/20190318_05.md36个CASE, 平均20倍提升create table|mview as,create indexhash join, hash agg, parallel

9、multi-phase aggbtree index include索引叶子附加属性/digoal/blog/blob/master/201905/20190503_03.md类似B+tree数据聚集，create index idx_t1_1 on t1 (id) include(c1,c2,c3,info,crt_time);添加字段（含默认值）更快/digoal/blog/blob/master/201805/20180518_01.md支持存储过程/docs/11/sql-createprocedure.htmlCREATE OR REPLACE PROCEDUREname ( arg

10、mode argname argtype DEFAULT | = default_expr , . ) LANGUAGE lang_name| TRANSFORM FOR TYPE type_name , . | EXTERNAL SECURITY INVOKER | EXTERNAL SECURITY DEFINER| SET configuration_parameter TO value | = value | FROM CURRENT | AS definition| AS obj_file, link_symbol ./digoal/blog/blob/master/201905/2

11、0190531_01.md支持事务commit|rollbackPG 12AM接口分区表-大量分区性能提升GiST index include索引叶子附加属性CTE 物化、非物化日志采样COPY WHEREAM接口/digoal/blog/blob/master/201903/20190331_03.md/digoal/blog/blob/master/201905/20190531_03.mdPG 12zedstore(列存)zheap(支持回滚段)分区表-大量分区性能提升1000个分区、469倍/digoal/blog/blob/master/201905/20190521_01.md /

12、digoal/blog/blob/master/201903/20190331_01.mdGiST index include索引叶子附加属性轨迹，时空搜索按结果集（索引）聚集存储，消除回表IO放大。CTE 物化、非物化/digoal/blog/blob/master/201903/20190309_04.md非物化-条件下推WITH w AS NOT MATERIALIZED (SELECT * FROM big_table)SELECT * FROM w AS w1 JOIN w AS w2 ON w1.key = w2.refWHERE w2.key = 123;日志采样/digoal/

13、blog/blob/master/201904/20190405_09.mdlog_statement_sample_rate ，当设置了log_min_duration_statement时，如果log_statement_sample_rate也设置了，它表示百分之多少的超时SQL被记录。log_transaction_sample_rate ， 不管其他任何设置，它表示百分之多少的事务被 记录duration。（事务为最小粒度单位，如果一个事务被触发了记录duration， 这个事务中的所有SQL都会被记录。）COPY WHERE/digoal/blog/blob/master/2019

14、03/20190331_11.mdpluggable AMzheap/EnterpriseDB/zheap/EnterpriseDB/zheap/tree/master/src/backend/access/zheap64-bit transaction idszheap will prevent bloat(a) by allowing in-place updates in common cases and(b) by reusing space as soon as a transaction that has performed a delete or non-in-place-upd

15、ate has committed.Reduce write amplification both by avoiding rewrites of heap pages and by making it possible to do an update that touches indexed columns without updating every index.Reduce the tuple size by(a) shrinking the tuple header and(b) eliminating most alignment padding.In-place updates w

16、ill be supported except when(a) the new tuple is larger than the old tuple and the increase in sizemakes it impossible to fit the larger tuple onto the same page or(b) some column is modified which is covered by an index that has notbeen modified to support “delete-marking”.We have not begun work on

17、 delete-marking support for indexesyet, but intend to support it at least for btree indexes.pluggable AMzedstore/greenplum-db/postgres/tree/zedstore/src/backend/access/zedstore* Performance improvement for queries selecting subset of columns (reduced IO).* Reduced on-disk footprint compared to heap

18、table. Shorter tuple headers and alsoleveraging compression of similar type data* Be first-class citizen in the Postgres architecture (tables data can just independentlylive in columnar storage) and not be at arms length though an opaque interface.* Fully MVCC compliant - basically all operations su

19、pported similar to heap, like update, delete, serializable transactions etc.* All Indexes supported* Hybrid row-column store, where some columns are stored together, and others separately. Provide flexibility of granularity on how to divide the columns. Columns accessed together can be stored together.* Provide better control over bloat (using zheap)*