萧少聪 PGPool and pg_shard

端木博超

2018/05/13 发布于 技术 分类

自2010年以来,国内领先的IT专业网站IT168联合旗下ITPUB、ChinaUnix两大技术社区,已经连续举办了五届中国数据库技术大会,每届大会与会规模超千人,大会云集了国内水平最高的数据架构师、数据库管理和运维工程师、数据库开发工程师、研发总监和IT经理等技术人群,是目前国内最受欢迎、人气最高的的数据库技术交流盛会。

文字内容
1. PGPool-II & pg_shard 萧少聪 scott.siu@postgres.cn
2. PGPool-II 主要的三种模式 • 连接池 • 水平分库 • 查询负载均衡
3. PGPool-II 水平分库 PGPool-II 冗余表 Data Node 数据1 冗余表 Data Node 分布表 数据2 冗余表 Data Node 数据3
4. PGPool-II 水平分库 PGPool-II PGPool-II Data Node Data Node Data Node Data Node Data Node Data Node
5. PGPool-II 查询负载均衡 应用程序 读写分离 负载均衡组件 PGPool II PostgreSQL (主库:读/写) PostgreSQL (备库:只读) PostgreSQL (备库:只读) Stream Replication
6. PGPool-II 查询负载均衡 具体参考:PGPool-II用户手册中的 负载均衡的条件
7. 我的PGPool演变过程 – 双节点
8. 我的PGPool演变过程 – 双节点
9. 我的PGPool演变过程 – 双节点
10. 我的PGPool演变过程 – 双节点
11. 我的PGPool演变过程 – 双节点
12. 我的PGPool演变过程 – PGPool自动Failover 应用程序 读写分离 负载均衡组件 PGPool II failover_command = '/usr/local/src/pgsql/9.0beta/bin/failover_stream.sh %d %H /tmp/trigger_file0’ 问题: 1、第1个备库promote后,第2个备库依然等 待原主库的信息 2、还要浪费1台服务器作为PGPool-II的备用 节点 PostgreSQL (主库:读/写) PostgreSQL (备库:只读) PostgreSQL (备库:只读) Stream Replication 具体参考:PGPool-II用户手册中的 流复制下的故障切换
13. 2 PGPool + 3 PostgreSQL Node 我的PGPool演变过程 – 双节点 PGPool PGPool PGPool PostgreSQL Master PostgreSQL Slave1 PostgreSQL Slave2
14. 集群经典问题:“脑裂” 我的PGPool演变过程 – 双节点 动作: 1、自杀 --兄弟可看P到GPool Master Master Down 2、确认 PGPoo-l-Master确实Down PGPool Master Up PostgreSQL Master PostgreSQL Slave1 PostgreSQL Slave2
15. 2 PGPool + 3 PostgreSQL Node 性能表现 使用pgbench设计数据量级分别为:1.6GB、16GB、22GB、75GB(75GB大于当 前数据库服务器的64GB内存容量) 只读 Master 读写 Master 1.6GB 7658.746290 1397.658002 16GB 22GB 75GB 6261.945201 5686.477821 1578.743890 1405.554289 1324.288750 1153.064096 只读 读写 PGPool1 PGPool2 PGPool1 PGPool2 1.6GB 16GB 6742.551840 6112.995046 5208.373120 5174.249760 1134.719497 1137.917411 1009.877069 1076.546164 22GB 5993.060036 5215.216332 1087.843114 943.548856 75GB 1403.986160 1445.030742 1064.235234 1078.342543
16. pg_shard
17. 传统的水平分库模式 (4 TB) Node #1 (PostgreSQL) (4 TB) Node #2 (4 TB) Node #3
18. 传统的水平分库模式 Node #1 Node #2 Node #3 Node #4 Node #5 Node #6
19. pg_shard like Hadoop
20. 134 679 ……… ……… Node #1 (PostgreSQL) 124 578 ……… ……… Node #2 512 MB (each) 235 689 ……… ……… Node #3 Node #4
21. 167 ……… ……… ……… Node #1 (PostgreSQL) 348 ……… ……… ……… Node #4 127 ……… ……… ……… Node #2 459 ……… ……… ……… Node #5 238 ……… ……… ……… Node #3 569 ……… ……… ……… Node #6
22. 167 ……… ……… ……… Node #1 (PostgreSQL) 348 ……… ……… ……… Node #4 127 ……… ……… ……… Node #2 459 ……… ……… ……… Node #5 238 ……… ……… ……… Node #3 569 ……… ……… ……… Node #6
23. Example Data Distribution in pg_shard Cluster Metadata Server (PostgreSQL + pg_shard) shard and shard placement metadata 134 679 ……… ……… Worker Node #1 124 578 ……… ……… Worker Node #2 235 689 ……… ……… Worker Node #3
24. Users: Making Scaling SQL Easy CREATE EXTENSION pg_shard; 

-- create a regular PostgreSQL table: 
CREATE TABLE customer_reviews (customer_id TEXT NOT NULL, review_date DATE, ...); 

-- distribute the table on the given partition key: 
SELECT master_create_distributed_table('customer_reviews', 'customer_id');
25. Metadata and Hash Partitioning postgres=# SELECT * FROM pgs_distribution_metadata.shard; id relation_id storage min_value max_value -------+-------------+---------+-------------+------------- 10004 177880 t -2147483648 -1879048194 10005 177880 t -1879048193 -1610612739 10006 177880 t -1610612738 -1342177284 10007 177880 t -1342177283 -1073741829 10008 177880 t -1073741828 -805306374 10009 177880 t -805306373 -536870919 ... ... ... ... ...
26. Planning Example INSERT INTO customer_reviews (customer_id, rating) VALUES ('HN892', 5); 1. Determine partition key clauses: customer_id = 'HN892' 2. Find shards from metadata tables: hashtext('HN892') BETWEEN min_value AND max_value 3. Produce shard-specific SQL INSERT INTO customer_reviews_16 (customer_id, rating) VALUES ('HN892', 5);
27. Single-shard INSERT Replication factor: 2 INSERT INTO customer_reviews ... 134 679 ……… ……… Worker Node #1 Master 124 578 ……… ……… Worker Node #2 235 689 ……… ……… Worker Node #3
28. Single-shard INSERT One replica fails INSERT INTO customer_reviews ... 134 679 ……… ……… Worker Node #1 Master 124 578 ……… ……… Worker Node #2 235 689 ……… ……… Worker Node #3
29. Single-shard INSERT Master marks inactive 134 679 ……… ……… Worker Node #1 Master Sets shard 6, node 3 to inactive status 124 578 ……… ……… Worker Node #2 235 689 ……… ……… Worker Node #3
30. Single-shard SELECT Try first placement SELECT * FROM customer_reviews
 134 679 ……… ……… Worker Node #1 Master 124 578 ……… ……… Worker Node #2 235 689 ……… ……… Worker Node #3
31. Single-shard SELECT Encounter error SELECT * FROM customer_reviews
 134 679 ……… ……… Worker Node #1 Master 124 578 ……… ……… Worker Node #2 235 689 ……… ……… Worker Node #3
32. Single-shard SELECT Try next placement SELECT * FROM customer_reviews
 134 679 ……… ……… Worker Node #1 Master 124 578 ……… ……… Worker Node #2 235 689 ……… ……… Worker Node #3
33. pg_shard性能及瓶颈 If your data set size is large and your workload is bottlenecked by disk, pg_shard will effectively scale out your workload to disks on the worker nodes. In this case, the master node is unlikely to be a scaling bottleneck. If your workload is bottlenecked on CPU, then the master node could become a bottleneck. Our initial benchmarks show that the master node can process 5K inserts/sec per CPU core. We're currently looking at performance improvements on the master node to make query routing an even lighter operation. 64 shards and 256 concurrent processes, pg_shard 1.0 executed 14,532 inserts per second (ips) in our internal benchmark. In pg_shard 1.1, we had the throughput improve to 56,982 ips. PS:少聪 没有钱搭环境,求“土豪”!!!
34. pg_shard 还有一些问题 • 无法支持事务完整性 • 不支持JSON操作 • 无法实现跨shard的约束 • 架构很新只有2年左右 • 试想一下,在一个RDBMS的数据库中,有一个 表挂着数十台服务器还可以无限扩展(o) • https://github.com/citusdata/pg_shard
35. 分布式的“舍”与“得” • 强一致性 分布处理 • 存储空间 数据冗余 • 响应速度 整体效率 • 投入成本 性能、可靠
36. Postgres中国用户会 萧少聪 scott.siu@postgres.cn