100TB级,⽇增量1TB（100亿）,OLTPOLAP混合场景数据库
设计⽅向
标签
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混合场景吗？PostgreSQL 100TB+, ⽇增量1TB的OLTP OLAP混合场景数据库设计从单机聊起
以10万左右的 32Core + SSD 单机为例，聊⼀下单机能做到什么样的性能。
单机OLTP性能如何? TPC-C
tpc-c是OLTP的⼯业测试标准之⼀，商业数据库，硬件⼚商⼤都会⽤TPC-C的测试结果来彰显⾃⼰的性能。
PostgreSQL TPC-C在单机的⼀组测试数据(warehouses=3000, terminals=256)如下，（这组测试数据是机器上有其他混合应⽤时的测试数据，还有较⼤的提升空间，到120万tpmC应该没有问题。）。
08:54:57,345 [main] INFO jTPCC : Term-00,
08:54:57,348 [main] INFO jTPCC : Term-00, +-------------------------------------------------------------+
08:54:57,348 [main] INFO jTPCC : Term-00, BenchmarkSQL v5.0
08:54:57,348 [main] INFO jTPCC : Term-00, +-------------------------------------------------------------+
08:54:57,348 [main] INFO jTPCC : Term-00, (c) 2003, Raul Barbosa
08:54:57,349 [main] INFO jTPCC : Term-00, (c) 2004-2016, Denis Lussier
08:54:57,350 [main] INFO jTPCC : Term-00, (c) 2016, Jan Wieck
08:54:57,351 [main] INFO jTPCC : Term-00, +-------------------------------------------------------------+
08:54:57,351 [main] INFO jTPCC : Term-00,
08:54:57,351 [main] INFO jTPCC : Term-00, db=postgres
08:54:57,351 [main] INFO jTPCC : Term-00, driver=org.postgresql.Driver
08:54:57,351 [main] INFO jTPCC : Term-00, conn=jdbc:postgresql://x:1921/db0
08:54:57,351 [main] INFO jTPCC : Term-00, user=benchmarksql
08:54:57,351 [main] INFO jTPCC : Term-00,
08:54:57,351 [main] INFO jTPCC : Term-00, warehouses=3000
08:54:57,351 [main] INFO jTPCC : Term-00, terminals=256
08:54:57,353 [main] INFO jTPCC : Term-00, runMins=30
08:54:57,353 [main] INFO jTPCC : Term-00, limitTxnsPerMin=0
08:54:57,353 [main] INFO jTPCC : Term-00, terminalWarehouseFixed=false
08:54:57,354 [main] INFO jTPCC : Term-00,
08:54:57,354 [main] INFO jTPCC : Term-00, newOrderWeight=45
08:54:57,354 [main] INFO jTPCC : Term-00, paymentWeight=43
08:54:57,354 [main] INFO jTPCC : Term-00, orderStatusWeight=4
08:54:57,354 [main] INFO jTPCC : Term-00, deliveryWeight=4
08:54:57,354 [main] INFO jTPCC : Term-00, stockLevelWeight=4
08:54:57,354 [main] INFO jTPCC : Term-00,
08:54:57,354 [main] INFO jTPCC : Term-00, resultDirectory=null
08:54:57,354 [main] INFO jTPCC : Term-00, osCollectorScript=null
08:54:57,355 [main] INFO jTPCC : Term-00,
08:54:57,439 [main] INFO jTPCC : Term-00, C value for C_LAST during load: 223
08:54:57,440 [main] INFO jTPCC : Term-00, C value for C_LAST this run: 138
08:54:57,440 [main] INFO jTPCC : Term-00,
09:24:58,011 [Thread-46] INFO jTPCC : Term-00,
09:24:58,012 [Thread-46] INFO jTPCC : Term-00,
09:24:58,012 [Thread-46] INFO jTPCC : Term-00, Measured tpmC (NewOrders) = 380234.68
09:24:58,012 [Thread-46] INFO jTPCC : Term-00, Measured tpmTOTAL = 844858.82
09:24:58,012 [Thread-46] INFO jTPCC : Term-00, Session Start = 2017-01-27 08:54:57
09:24:58,012 [Thread-46] INFO jTPCC : Term-00, Session End = 2017-01-27 09:24:58
09:24:58,012 [Thread-46] INFO jTPCC : Term-00, Transaction Count = 25346862
PostgreSQL的优化器完备（例如成熟的CBO体系，丰富的NODE运算⽅法等），在线事务处理能⼒⽅⾯，性能卓越。
AGG_HASHED:
AGG_MIXED:
AGG_PLAIN:
AGG_SORTED:
JOIN_ANTI:
JOIN_FULL:
JOIN_INNER:
JOIN_LEFT:
JOIN_RIGHT:
JOIN_SEMI:
T_Agg:
T_Append:
T_BitmapAnd:
T_BitmapHeapScan:
T_BitmapIndexScan:
T_BitmapOr:
T_CteScan:
T_CustomScan:
T_ForeignScan:
T_FunctionScan:
T_Gather:
T_GatherMerge:
T_Group:
T_Hash:
T_HashJoin:
T_IndexOnlyScan:
T_IndexScan:
T_Limit:
T_LockRows:
T_Material:
T_MergeAppend:
T_MergeJoin:
T_ModifyTable:
T_NamedTuplestoreScan:
T_NestLoop:
T_ProjectSet:
T_RecursiveUnion:
T_Result:
T_SampleScan:
T_SeqScan:
T_SetOp:
T_Sort:
T_SubqueryScan:
T_TableFuncScan:
T_TidScan:
T_Unique:
T_ValuesScan:
T_WindowAgg:
T_WorkTableScan:
单机OLAP性能如何? TPC-H
tpc-h是OLA的⼯业测试标准之⼀，有⼤量的JOIN，GROUP等⼤运算量的操作。⼤多数的商业AP数据库会以tpc-h测试结果来彰显⾃⼰的性能。
1、PostgreSQL 10 1TB TPC-H在单机的⼀组测试数据(SF=1000，即1TB的量)。
这组测试⾮常具有代表意义，例如⽤户每天新增1TB的数据增量，对增量进⾏统计，⽣成报表。
PG 10 分区表的并⾏度⽬前不⽀持alter设置，需要UPDATE PG_CLASS，例如
update pg_class set reloptions =array['parallel_workers=32'] where relname ~ 'lineitem'and relkind='r';
update pg_class set reloptions =array['parallel_workers=32'] where relname ~ 'orders'and relkind='r';
从这组数据来看，⽇增量1TB的场景中，仅仅使⽤现有特性，PG已可以应付其OLAP需求。
2、另外，在同⼀主机上，测了⼀组deepgreen的性能，1TB TPC-H跑完约1⼩时。（deepgreen是⼀个完全兼容Greenplum的MPP数据库，在列存储、SQL优化器、JIT、向量计算⽅⾯有⼤幅增强）。
为什么要测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
Unlogged table "public.customer"
Column | Type | Collation | Nullable | Default
--------------+------------------------+-----------+----------+---------------------------------------------
c_custkey | bigint || not null | nextval('customer_c_custkey_seq'::regclass)
c_name | character varying(25) |||
c_address | character varying(40) |||
c_nationkey | bigint || not null |
c_phone | character(15) |||
c_acctbal | double precision |||
c_mktsegment | character(10) |||
c_comment | character varying(117) |||
postgres=# create unlogged table vops_customer (c_custkey vops_int8, c_nationkey vops_int8, c_acctbal vops_float8);
CREATE TABLE
postgres=# select populate(destination := 'vops_customer', source := 'customer');
populate
-----------
150000000
(1 row)
postgres=# create unlogged table c as select c_custkey,c_nationkey,c_acctbal from customer;
SELECT 150000000
测试时确保数据均在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 | avg | min | max | sum | avg | min | max | sum | min | max | avg | count
-------------------+-----------------------+-----+-----------+------------+---------------------+-----+-----+-----------------+---------+---------+------------------+-----------
11250000075000000 | 75000000.500000000000 | 1 | 150000000 | 1800117761 | 12.0007850733333333 | 0 | 24 | 675048124067.72 | -999.99 | 9999.99 (1 row)
Time: 55972.494 ms (00:55.972)
postgres=# explain (analyze,verbose,timing,costs,buffers) select sum(c_custkey),avg(c_custkey),min(c_custkey),max(c_custkey),sum(c_nationkey),avg(c_nation QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Aggregate (cost=7330421.81..7330421.82 rows=1 width=200) (actual time=57319.855..57319.855 rows=1 loops=1)
Output: 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
Buffers: shared hit=955415
-> Seq Scan on public.c (cost=0.00..2455416.60 rows=150000160 width=24) (actual time=0.012..14185.622 rows=150000000 loops=1)
Output: c_custkey, c_nationkey, c_acctbal
Buffers: shared hit=955415
Planning time: 0.068 ms
Execution time: 57319.926 ms
(8 rows)
Time: 57320.443 ms (00:57.320)
使⽤向量化后，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 | avg | min | max | sum | avg | min | max | sum | min | max | avg | countall
-------------------+------------------+-----+-----------+------------+------------------+-----+-----+-----------------+---------+---------+------------------+-----------
11250000075000000 | 75000000.4473924 | 1 | 150000000 | 1800117761 | 12.0007850733333 | 0 | 24 | 675048124067.72 | -999.99 | 9999.99 | 4500.32082 (1 row)
Time: 9785.634 ms (00:09.786)
postgres=# explain (analyze,verbose,timing,costs,buffers) select sum(c_custkey),avg(c_custkey),min(c_custkey),max(c_custkey),sum(c_nationkey),avg(c_nation QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Aggregate (cost=568359.38..568359.39 rows=1 width=104) (actual time=9707.393..9707.393 rows=1 loops=1)
Output: 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
常见mpp数据库Buffers: shared hit=468750
-> Seq Scan on public.vops_customer (cost=0.00..492187.50 rows=2343750 width=1584) (actual time=0.008..842.816 rows=2343750 loops=1)
Output: c_custkey, c_nationkey, c_acctbal
Buffers: shared hit=468750
Planning time: 0.073 ms
Execution time: 9707.461 ms
(8 rows)
Time: 9709.400 ms (00:09.709)
PG 10采样向量化插件提升了N倍性能，叠加并⾏化，甚⾄可以超过DP的性能。
使⽤向量化除了性能本⾝的提升，还可以更好的压缩数据。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论