|
标签 PostgreSQL , LLVM , JIT , 并行 , 列存储 , GPU 背景 总量100TB，日增量1TB左右。这样的体量应该可以覆盖目前绝大多数企业的数据库体量。 提到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的OLTP OLAP混合场景吗？ PostgreSQL 100TB+, 日增量1TB的OLTP OLAP混合场景数据库设计 从单机聊起 以10万左右的 32Core + SSD 单机为例，聊一下单机能做到什么样的性能。 单机OLTP性能如何? TPC-C tpc-c是OLTP的工业测试标准之一，商业数据库，硬件厂商大都会用TPC-C的测试结果来彰显自己的性能。 PostgreSQL TPC-C在单机的一组测试数据(warehouses=3000, terminals=256)。 《数据库界的华山论剑 tpc.org》 08:54:57,345 [main] INFO jTPCC : Term-00, PostgreSQL的优化器完备（例如成熟的CBO体系，丰富的NODE运算方法等），在线事务处理能力方面，性能卓越。 AGG_HASHED: 单机OLAP性能如何? TPC-H tpc-h是OLA的工业测试标准之一，有大量的JOIN，GROUP等大运算量的操作。大多数的商业AP数据库会以tpc-h测试结果来彰显自己的性能。 测试使用这个github: https://github.com/digoal/gp_tpch 1、PostgreSQL 10 1TB TPC-H在单机的一组测试数据(SF=1000，即1TB的量)。 这组测试非常具有代表意义，例如用户每天新增1TB的数据增量，对增量进行统计，生成报表。 从这组数据来看，日增量1TB的场景中，仅仅使用现有特性，PG已可以应付其OLAP需求。 2、另外，在相同主机上，测了一组deepgreen的性能，1TB TPC-H跑完约1小时。（deepgreen是一个完全兼容Greenplum的MPP数据库，在列存储、SQL优化器、JIT、向量计算方面有大幅增强）。 deepgreen tpch explain result 为什么要测deepgreen？前面说了在OLAP性能方面，Greenplum已经远超Oracle。而Deepgreen的性能已在Greenplum之上。我们可以将deepgreen作为一个标杆（DP实际上也是基于PG开发的MPP版本），PostgreSQL将来在经过增强后OLAP方面有可能达到甚至超过DP的性能。 如果PostgreSQL能达到DP的水平，超过Oracle自然没问题（没有对比就没有伤害，读者可以试试同样数据量的Oracle性能）。 （PostgreSQL 10目前仅使用了JIT、多核并行、OP复用、分区表、哈希聚合、哈希分组 等若干对OLAP场景有较大性能提升的技术手段，还有列存储、向量计算、appendscan并行等手段可以使用，预计至少还有10倍左右的性能提升空间。） 100TB+, 日增量超过1TB后 - PostgreSQL 黑科技 除了PG 10已经具备的 JIT，多核并行、OP复用、分区表、哈希聚合、哈希分组，等OLAP场景黑科技，PostgreSQL还有哪些黑科技可用来大幅提升单机OLAP场景的性能？ 1、JIT LLVM增强，目前PG 10已整合了JIT框架，但是要支持更多的算子。 2、向量化 目前有一个PG插件，可以实现PG的向量计算。 已支持的向量计算类型如下 下面是一组使用向量化技术后的性能提升数据。 postgres=# \d customer 测试时确保数据均在shared buffer中. 使用向量化前，56秒。 postgres=# select sum(c_custkey),avg(c_custkey),min(c_custkey),max(c_custkey),sum(c_nationkey),avg(c_nationkey),min(c_nationkey),max(c_nationkey),sum(c_acctbal),min(c_acctbal),max(c_acctbal),avg(c_acctbal),count(*) from c; 使用向量化后，10秒。 postgres=# select sum(c_custkey),avg(c_custkey),min(c_custkey),max(c_custkey),sum(c_nationkey),avg(c_nationkey),min(c_nationkey),max(c_nationkey),sum(c_acctbal),min(c_acctbal),max(c_acctbal),avg(c_acctbal),countall(*) from vops_customer; 提升了N倍性能。 使用向量化除了性能本身的提升，还可以更好的压缩数据。 非向量化存储 VOPS guide 3、多核并行 目前PG已支持大多数NODE的多核并行，例如SEQ SCAN，INDEX SCAN，HASH AGG，SORT等。将来会支持更多的NODE。 比如将要支持 APPEND 并行，那么多个分区表可以并行扫描，理论上这个FEATURE加上后，性能和开源版本Greenplum应该可以对齐。 4、列存储 目前PG内置的是行存储，要支持列存储，可以安装列存储插件，例如IMCS插件，CSTORE插件。 使用列存储，可以提升数据压缩比，同时降低列统计时的数据扫描量和deform开销，提升列统计性能，以及更好的支持向量计算（目前VOPS向量计算通过新增数据类型，批量瓦片式存储来实现，比较别扭）等。 列存插件如下： https://github.com/knizhnik/imcs https://github.com/citusdata/cstore_fdw 期待未来的PG版本可以支持列存储。 5、hll 通过hhl插件，可以支持一些估值统计的问题，在用户允许一些误差的情况下，高效率的实现实时的PV,UV等查询需求。例如实时查询APP的uv TOP 10。 hll的插件如下： https://github.com/citusdata/cstore_fdw 6、GPU CPU的计算能力有限，通过GPU可以大幅提升OLAP的性能。pg-strom是一个利用PostgreSQL scan api和GPU实现的OLAP加速插件。 https://github.com/pg-strom/devel JOIN几十张大表毫无压力。 7、读写分离 通过流复制，可以创建PostgreSQL的备库，WAL延迟接近于0。提升数据库集群整体的处理能力。 8、流计算 pipelinedb是基于PostgreSQL开发的一个流计算数据库，正在进行插件化，将来可以作为插件安装到PostgreSQL数据库中。 使用流计算，可以将大量的计算任务分摊到全天，从而减少集中计算的运力需求。集中计算就好像春节放假，大量的人群流动。而流计算就好比城镇化崛起，大家都不外出打工，都在家附近发展，杜绝了节假日的大迁徙。 《流计算风云再起 - PostgreSQL携PipelineDB力挺IoT》 9、冷热存储分离 阿里云的RDS PG与云对象存储OSS无缝结合，实现了数据的分层存储。 https://help.aliyun.com/document_detail/44461.html 存放于OSS的数据，通过OSS_FDW插件，使用外部表进行访问，用户访问PG外部表和访问本地表的SQL语法完全一样，无需修改应用。 存放于OSS的数据，用户不需要对其进行备份因为OSS本身就是多副本存储。从而减轻了数据库备份的开销和成本。 使用OSS，PG实际上相当于实现了无限容量的存储，拓展了单个数据库的存储边界。 存放于OSS的数据，不仅可以给一个PG实例使用，同时还可以给多个实例同时使用，例如可以创建一个RDS实例，对接OSS上的数据，分析师就可以在上面进行分析而不需要消耗在线数据库的资源。 10、类rac架构 这个架构最早由亚马逊Aurora提出，目前已经推出了PG的Aurora版本。 和Oracle RAC一样，都使用共享存储的架构，差别仅仅在于一写多读，Oracle是多写多读。 存储为多副本的设计，可以实现跨可用区的多副本一致性，从而解决了HA、容灾层面的问题，使用一写多读，还解决了读性能扩展的问题。 结合PostgreSQL本身的功能、性能等特性，aurora架构让PG可以覆盖更多的企业场景。 相信会有更多的公司会跟进这样的架构。 11、mpp或sharding 不推荐sharding，因为要牺牲一些功能层面的特性。但是不妨碍社区为了某些特定场景而推出的一些sharding插件。 例如citus插件，自带节点间数据传输，JOIN，透明的数据重分布功能。可以很好的支撑OLAP的横向扩展能力。 https://github.com/citusdata/citus 例如TP方面的sharding，基于fdw的sharding，可以解决TP的横向扩展需求。 《PostgreSQL 10.0 preview sharding增强 - 支持分布式事务》 《PostgreSQL 10.0 preview sharding增强 - pushdown 增强》 《PostgreSQL 10.0 preview sharding增强 - 支持Append节点并行》 《PostgreSQL 10.0 preview sharding增强 - postgres_fdw 多节点异步并行执行》 《PostgreSQL 9.6 sharding based on FDW & pg_pathman》 《PostgreSQL 9.6 sharding + 单元化 (based on postgres_fdw) 最佳实践 - 通用水平分库场景设计与实践》 《PostgreSQL 9.6 单元化,sharding (based on postgres_fdw) - 内核层支持前传》 12、OLAP SQL兼容性 PostgreSQL在OLAP SQL兼容性方面的支持是非常完备的，包括多维分析(grouping sets,cube,rollup,grouping等)，递归查询，窗口查询，多表JOIN，科学计算，机器学习函数 等等。 PostgreSQL vs Oracle 架构对比 比Oracle强的点 开源软件强大之处在于发展非常的迅速，非常的开放。同时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方面有非常大的性能提升。 需要向Oracle学习的点 类RAC架构。 未来的发展方向 《数据库的未来 - HTAP，软件、硬件、云生态的融合》 小结 现在已经不是商业数据库的天下，越来越多的开源产品在崛起，正在从稳定性、性能、功能各个方面包围商业产品，PG 10是一个非常典型的代表。 PG 10 会扛起100TB，日增量1TB 级别这个市场的OLTP+OLAP混合场景HTAP的大旗，值得期待。 而在云上，用户不需要担心运维、高可用、备份、扩容、迁移、诊断、监控等问题，用户只管用，云为用户提供贴身服务。云上的PG提供了更多的扩展（包括 与对象存储的无缝结合，内核的优化，增值服务，类RAC架构(越来越多的厂商会跟进aurora形态)等）。 如果你不想用云服务，没有关系，在不改内核的情况下，你依旧可以使用目前社区版本提供的这些特性，来满足你的需求（包括流计算、HLL、读写分离、JIT、向量计算、列存储等）。 参考 《数据库界的华山论剑 tpc.org》 《数据库的未来 - HTAP，软件、硬件、云生态的融合》 |
|
|
