postgresql , llvm , jit , 并行 , 列存储 , gpu , 向量计算 , hll , 流计算 , oss对象存储结合
总量100tb，日增量1tb(日增约100亿记录)左右。这样的体量应该可以覆盖目前绝大多数企业的数据库体量。
提到100tb级别，oltp和olap的混合场景，大家可能会想到oracle的一体机extradata，没错oracle在这方面做得确实是非常棒的，但是价格也是很漂亮的。
oracle主要通过几个方面来提升它在这个级别的性能：
共享存储+rac架构，同时提升oltp和olap的扩展能力，（oltp：多个业务可以分配到多个主机上，但是需要注意数据库维护缓存一致性带来的性能下降问题，所以通常不同的主机访问不同的数据块是较好的设计），（olap：同一条sql可以使用单机cpu多核甚至多个主机的cpu计算能力）。
列存储，提升olap的性能。
内部使用ib互联，解决了网络瓶颈的问题。
在单纯的olap数据库方面，代表作有greenplum, teradata, asterdata等mpp数据库，比如gpdb就可以利用廉价的x86达到及其好的ap性能，我记得很多年前用6台4万左右的x86搭建的gpdb集群，以性能逾10倍多的差异干掉了2台ibm p570顶配的oracle rac。
回到主题，开源界有没有应对oltp+olap场景的数据库呢？
大多数开源数据库选择了分而治之(sharding)的路线，因为大多数开源数据库单机做不到像oracle那么好的性能。
然而，sharding要做到体验和单机一样是非常困难的，包括分布式事务，全局一致性，全局时间点恢复，跨节点join，节点间数据交换，数据重分布，扩容，窗口查询，聚合下推等都是巨大的调整。目前还没有哪个sharding技术敢说体验和单机一样，（通常sharding为了实现的便利，会阉割掉大量单机下面的功能）。
其二，要支持olap其实仅仅sharding是不够的，还有大量的sql兼容性的工作（例如多维分析、多表join、窗口查询、递归查询、科学计算等等）。
个人认为目前体验做得最好的sharding应该属greenplum了，但是也仅仅局限在纯olap方面。
开源数据库如果不走sharding路线，能稳定的扛住100tb+, 日增量1tb(日增约100亿记录)的oltp olap混合场景吗？
以10万左右的 32core + ssd 单机为例，聊一下单机能做到什么样的性能。
tpc-c是oltp的工业测试标准之一，商业数据库，硬件厂商大都会用tpc-c的测试结果来彰显自己的性能。
postgresql tpc-c在单机的一组测试数据(warehouses=3000, terminals=256)如下，（这组测试数据是机器上有其他混合应用时的测试数据，还有较大的提升空间，到120万tpmc应该没有问题。）。
<a href="https://github.com/digoal/blog/blob/master/201701/20170125_01.md">《数据库界的华山论剑 tpc.org》</a>
postgresql的优化器完备（例如成熟的cbo体系，丰富的node运算方法等），在线事务处理能力方面，性能卓越。
tpc-h是ola的工业测试标准之一，有大量的join，group等大运算量的操作。大多数的商业ap数据库会以tpc-h测试结果来彰显自己的性能。
1、postgresql 10 1tb tpc-h在单机的一组测试数据(sf=1000，即1tb的量)。
这组测试非常具有代表意义，例如用户每天新增1tb的数据增量，对增量进行统计，生成报表。
pg 10 分区表的并行度目前不支持alter设置，需要update pg_class,例如
从这组数据来看，日增量1tb的场景中，仅仅使用现有特性，pg已可以应付其olap需求。
2、另外，在同一主机上，测了一组deepgreen的性能，1tb tpc-h跑完约1小时。（deepgreen是一个完全兼容greenplum的mpp数据库，在列存储、sql优化器、jit、向量计算方面有大幅增强）。
<a href="https://github.com/digoal/blog/blob/master/201707/20170703_01_explain.tar.bz2">deepgreen tpch explain result</a>
为什么要测deepgreen？前面说了在olap性能方面，greenplum已经远超oracle。而deepgreen的性能已在greenplum之上。我们可以将deepgreen作为一个标杆（dp实际上也是基于pg开发的mpp版本），postgresql将来在经过增强后olap方面有可能达到甚至超过dp的性能。
如果postgresql能达到dp的水平，超过oracle自然没问题（没有对比就没有伤害，读者可以试试同样数据量的oracle性能）。
（postgresql 10目前仅使用了jit、多核并行、op复用、分区表、哈希聚合、哈希分组 等若干对olap场景有较大性能提升的技术手段，还有列存储、向量计算、appendscan并行等手段可以使用，预计至少还有10倍左右的性能提升空间。）
除了pg 10已经具备的 jit，多核并行、op复用、分区表、哈希聚合、哈希分组，等olap场景黑科技，postgresql还有哪些黑科技可用来大幅提升单机olap场景的性能？
llvm增强，目前pg 10已整合了jit框架，但是要支持更多的算子。
目前有一个pg插件，可以实现pg的向量计算。
已支持的向量计算类型如下
下面是一组使用向量化技术后的性能提升数据。
测试时确保数据均在shared buffer中.
使用向量化前，56秒。
使用向量化后，10秒。
pg 10采样向量化插件提升了n倍性能，叠加并行化，甚至可以超过dp的性能。
使用向量化除了性能本身的提升，还可以更好的压缩数据。
并行叠加向量计算的效果测试。
pg 10: 439毫秒。
相对应的deepgreen测试如下: 532毫秒.
pg 10 多核+向量计算组合后，已和deepgreen的分析性能持平甚至略好。（要知道测试中，pg10 还没有使用正儿八经的列式存储呢，还有提升的潜力。）
<a href="https://github.com/digoal/blog/blob/master/201707/20170703_01_vops.html">postgresql vops guide</a>
<a href="https://github.com/digoal/blog/blob/master/201702/20170225_01.md">postgresql vops 向量计算中文guide</a>
目前pg已支持大多数node的多核并行，例如seq scan，index scan，hash agg，sort等。将来会支持更多的node。
比如将要支持 append 并行，那么多个分区表(或者多个继承表、多个外部表、以及union查询)都可以并行扫描，理论上这个feature加上后，性能和开源版本greenplum应该可以对齐。
同时还需要提供一种绕过os page cache的数据扫描方法，比如dio，在olap场景会非常有用。（例如突然发起一个大量数据的查询请求，不至于把cache打乱。）
目前pg内置的是行存储，要支持列存储，可以安装列存储插件，例如imcs插件，cstore插件。
使用列存储，可以提升数据压缩比，同时降低列统计时的数据扫描量和deform开销，提升列统计性能，以及更好的支持向量计算（目前vops向量计算通过新增数据类型，批量瓦片式存储来实现，比较别扭）等。
列存插件如下：
<a href="https://github.com/knizhnik/imcs">https://github.com/knizhnik/imcs</a>
<a href="https://github.com/citusdata/cstore_fdw">https://github.com/citusdata/cstore_fdw</a>
期待未来的pg版本可以支持列存储。
通过hhl插件，可以支持一些估值统计的问题，在用户允许一些误差的情况下，高效率的实现实时的pv,uv等查询需求。例如实时查询app的uv top 10。
hll的插件如下：
cpu的计算能力有限，通过gpu可以大幅提升olap的性能。pg-strom是一个利用postgresql scan api和gpu实现的olap加速插件。
<a href="https://github.com/pg-strom/devel">https://github.com/pg-strom/devel</a>
join几十张大表毫无压力。
通过流复制，可以创建postgresql的备库，wal延迟接近于0。提升数据库集群整体的处理能力。
pipelinedb是基于postgresql开发的一个流计算数据库，正在进行插件化，将来可以作为插件安装到postgresql数据库中。
使用流计算，可以将大量的计算任务分摊到全天，从而减少集中计算的运力需求。集中计算就好像春节放假，大量的人群流动。而流计算就好比城镇化崛起，大家都不外出打工，都在家附近发展，杜绝了节假日的大迁徙。
<a href="https://github.com/digoal/blog/blob/master/201612/20161220_01.md">《流计算风云再起 - postgresql携pipelinedb力挺iot》</a>
阿里云的rds pg与云对象存储oss无缝结合，实现了数据的分层存储。
<a href="https://help.aliyun.com/document_detail/44461.html">https://help.aliyun.com/document_detail/44461.html</a>
存放于oss的数据，通过oss_fdw插件，使用外部表进行访问，用户访问pg外部表和访问本地表的sql语法完全一样，无需修改应用。
存放于oss的数据，用户不需要对其进行备份因为oss本身就是多副本存储。从而减轻了数据库备份的开销和成本。
使用oss，pg实际上相当于实现了无限容量的存储，拓展了单个数据库的存储边界。
存放于oss的数据，不仅可以给一个pg实例使用，同时还可以给多个实例同时使用，例如可以创建一个rds实例，对接oss上的数据，分析师就可以在上面进行分析而不需要消耗在线数据库的资源。
这个架构最早由亚马逊aurora提出，目前已经推出了pg的aurora版本。
和oracle rac一样，都使用共享存储的架构，差别仅仅在于一写多读，oracle是多写多读。
存储为多副本的设计，可以实现跨可用区的多副本一致性，从而解决了ha、容灾层面的问题，使用一写多读，还解决了读性能扩展的问题。
结合postgresql本身的功能、性能等特性，aurora架构让pg可以覆盖更多的企业场景。
相信会有更多的公司会跟进这样的架构。
不推荐sharding，因为要牺牲一些功能层面的特性。但是不妨碍社区为了某些特定场景而推出的一些sharding插件。
例如citus插件，自带节点间数据传输，join，透明的数据重分布功能。可以很好的支撑olap的横向扩展能力。
<a href="https://github.com/citusdata/citus">https://github.com/citusdata/citus</a>
例如tp方面的sharding，基于fdw的sharding，可以解决tp的横向扩展需求。
<a href="https://github.com/digoal/blog/blob/master/201703/20170331_03.md">《postgresql 10.0 preview sharding增强 - 支持分布式事务》</a>
<a href="https://github.com/digoal/blog/blob/master/201703/20170312_20.md">《postgresql 10.0 preview sharding增强 - pushdown 增强》</a>
<a href="https://github.com/digoal/blog/blob/master/201703/20170312_11.md">《postgresql 10.0 preview sharding增强 - 支持append节点并行》</a>
<a href="https://github.com/digoal/blog/blob/master/201703/20170312_07.md">《postgresql 10.0 preview sharding增强 - postgres_fdw 多节点异步并行执行》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161027_01.md">《postgresql 9.6 sharding based on fdw & pg_pathman》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161005_01.md">《postgresql 9.6 sharding + 单元化 (based on postgres_fdw) 最佳实践 - 通用水平分库场景设计与实践》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161004_01.md">《postgresql 9.6 单元化,sharding (based on postgres_fdw) - 内核层支持前传》</a>
postgresql在olap sql兼容性方面的支持是非常完备的，包括多维分析(grouping sets,cube,rollup,grouping等)，递归查询，窗口查询，多表join，科学计算，机器学习函数 等等。
开源软件强大之处在于发展非常的迅速，非常的开放。同时postgresql这个产品本身的开源许可、设计很契合开发者，开放了大量的可扩展接口，因此我们可以看到postgresql生态中有特别多的插件，满足各种场景的需求。
相比oracle，pg有哪些优势？
1、云生态融合，例如oss_fdw，就是一个数据库和对象存储融合的例子。
2、软件生态融合，例如pl语言，用户可以通过plpython, plr, plcuda等语言开发存储过程，融合开发者的软件生态。
3、硬件生态融合，例如与gpu结合，让pg拥有更加强大的计算能力。
4、可扩展，通过开放的数据、索引、扫描、操作符、udf等接口，可以支持更多的用户场景。
比如图像特征值的存储和搜索，通过扩展就能支持，imgsmlr这个插件就是一个代表。
比如基因数据的存储和搜索，通过扩展就能支持，postbis这个插件就是一个代表。
比如化学数据的存储和搜索，rdkit。
机器学习插件，madlib。
gis插件，postgis。
时序数据插件，timescaledb。
hll估值插件。
5、流计算，通过pipelinedb，可以实现流式计算。
6、mpp，通过citus插件，可以实现mpp，多机并行计算。
7、llvm, 向量计算等优化手段，在olap方面有非常大的性能提升。
类rac架构，(aurora postgresql和这种形态非常类似，而且存储层做得更加强大)。
<a href="https://github.com/digoal/blog/blob/master/201705/20170526_01.md">《数据库的未来 - htap，软件、硬件、云生态的融合》</a>
现如今已不是商业数据库独舞，越来越多的开源产品在崛起，从稳定性、性能、功能各个方面包围商业产品，postgresql 是一个非常典型的代表。
扛起100tb，日增量1tb 级别这个市场的oltp+olap混合场景htap的大旗，postgresql 值得拥有。
同时，在云上，用户不再需要担心运维、高可用、备份、扩容、迁移、诊断、监控等问题，用户只管用，云为用户提供贴身服务。云上的pg提供了更多的扩展（包括 与对象存储的无缝结合，内核的优化，增值服务，类rac架构(越来越多的厂商会跟进aurora形态)等）。
如果用户不想使用云服务，没有关系，在不改内核的情况下，你依旧可以使用目前社区版本提供的这些特性，来满足你的需求（包括流计算、hll、读写分离、jit、向量计算、列存储等）。
<a href="https://github.com/digoal/blog/blob/master/201702/20170225_01.md">《postgresql 向量化执行插件(瓦片式实现) 10x提速olap》</a>