Skip to content

Commit 6efaf1e

Browse files
digoaldigoal
committed
new doc
1 parent 8e8512f commit 6efaf1e

File tree

5 files changed

+586
-0
lines changed

5 files changed

+586
-0
lines changed

‎201711/20171107_32.md‎

Lines changed: 280 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,280 @@
1+
## HTAP数据库 PostgreSQL 场景与性能测试之 31 - (OLTP) 高吞吐数据进出(堆存、行扫、无需索引) - 阅后即焚(读写大吞吐并测)
2+
3+
### 作者
4+
digoal
5+
6+
### 日期
7+
2017-11-07
8+
9+
### 标签
10+
PostgreSQL , HTAP , OLTP , OLAP , 场景与性能测试
11+
12+
----
13+
14+
## 背景
15+
PostgreSQL是一个历史悠久的数据库，历史可以追溯到1973年，最早由2014计算机图灵奖得主，关系数据库的鼻祖[Michael_Stonebraker](https://en.wikipedia.org/wiki/Michael_Stonebraker) 操刀设计，PostgreSQL具备与Oracle类似的功能、性能、架构以及稳定性。
16+
17+
![pic](20171107_02_pic_003.jpg)
18+
19+
PostgreSQL社区的贡献者众多，来自全球各个行业，历经数年，PostgreSQL 每年发布一个大版本，以持久的生命力和稳定性著称。
20+
21+
2017年10月，PostgreSQL 推出10 版本，携带诸多惊天特性，目标是胜任OLAP和OLTP的HTAP混合场景的需求：
22+
23+
[《最受开发者欢迎的HTAP数据库PostgreSQL 10特性》](../201710/20171029_01.md)
24+
25+
1、多核并行增强
26+
27+
2、fdw 聚合下推
28+
29+
3、逻辑订阅
30+
31+
4、分区
32+
33+
5、金融级多副本
34+
35+
6、json、jsonb全文检索
36+
37+
7、还有插件化形式存在的特性，如 **向量计算、JIT、SQL图计算、SQL流计算、分布式并行计算、时序处理、基因测序、化学分析、图像分析** 等。
38+
39+
![pic](20171107_02_pic_001.jpg)
40+
41+
在各种应用场景中都可以看到PostgreSQL的应用：
42+
43+
![pic](../201706/20170601_02_pic_002.png)
44+
45+
PostgreSQL近年来的发展非常迅猛，从知名数据库评测网站dbranking的数据库评分趋势，可以看到PostgreSQL向上发展的趋势：
46+
47+
![pic](20171107_02_pic_002.jpg)
48+
49+
从每年PostgreSQL中国召开的社区会议，也能看到同样的趋势，参与的公司越来越多，分享的公司越来越多，分享的主题越来越丰富，横跨了 **传统企业、互联网、医疗、金融、国企、物流、电商、社交、车联网、共享XX、云、游戏、公共交通、航空、铁路、军工、培训、咨询服务等** 行业。
50+
51+
接下来的一系列文章，将给大家介绍PostgreSQL的各种应用场景以及对应的性能指标。
52+
53+
## 环境
54+
环境部署方法参考：
55+
56+
[《PostgreSQL 10 + PostGIS + Sharding(pg_pathman) + MySQL(fdw外部表) on ECS 部署指南(适合新用户)》](../201710/20171018_01.md)
57+
58+
阿里云 ECS：```56核，224G，1.5TB*2 SSD云盘```。
59+
60+
操作系统：```CentOS 7.4 x64```
61+
62+
数据库版本：```PostgreSQL 10```
63+
64+
PS：**ECS的CPU和IO性能相比物理机会打一定的折扣，可以按下降1倍性能来估算。跑物理主机可以按这里测试的性能乘以2来估算。**
65+
66+
## 场景 - 秒杀 - 高并发单点更新 (OLTP)
67+
68+
### 1、背景
69+
高吞吐的数据写入，消费，通常是MQ的强项和功能点，但是MQ没有数据存储的能力，也没有计算能力。
70+
71+
而PostgreSQL具备了存储、计算能力，同时PG还提供了高吞吐，可靠性。
72+
73+
在需要高吞吐计算的环境，PG是非常不错的选择。
74+
75+
如果业务上需要先进先出的模式，可以加一个时间索引，即可达到这样的效率，写入和消费都在300万行/s以上：
76+
77+
![pic](20171107_32_pic_001.jpg)
78+
79+
详见：
80+
81+
[《HTAP数据库 PostgreSQL 场景与性能测试之 27 - (OLTP) 物联网 - FEED日志, 流式处理 与 阅后即焚 (CTE)》](../20171107_28.md)
82+
83+
如果业务上不要求强烈的先进先出，并且处理吞吐足够强悍的话，实际上PG可以不需要索引，因为是堆表，没有索引，写和消费的吞吐可以做到更大。
84+
85+
本文测试的是不需要索引的裸写入和消费吞吐能力(消费、不计算)。
86+
87+
下一篇压测大吞吐下，结合 函数计算和JSON的能力。
88+
89+
### 2、设计
90+
1、堆表、多表、大吞吐写入
91+
92+
2、堆表、多表、大吞吐消费
93+
94+
同时压测写入和消费。
95+
96+
### 3、准备测试表
97+
98+
```
99+
create table t_sensor (sid int, info text, crt_time timestamp) ;
100+
```
101+
102+
使用2048个分表。
103+
104+
```
105+
do language plpgsql $$
106+
declare
107+
begin
108+
for i in 0..2047 loop
109+
execute 'create table t_sensor'||i||'(like t_sensor including all) inherits(t_sensor) '||case when mod(i,2)=0 then ' ' else ' tablespace tbs1' end;
110+
end loop;
111+
end;
112+
$$;
113+
```
114+
115+
### 4、准备测试函数(可选)
116+
1、批量生成传感器测试数据的函数
117+
118+
```
119+
CREATE OR REPLACE FUNCTION public.ins_batch(integer,integer)
120+
RETURNS void
121+
LANGUAGE plpgsql
122+
STRICT
123+
AS $function$
124+
declare
125+
suffix int := mod($1, 2048);
126+
begin
127+
execute 'insert into t_sensor'||suffix||' select '||$1||', 0.1, now() from generate_series(1,'||$2||')';
128+
end;
129+
$function$;
130+
```
131+
132+
2、批量消费传感器数据的函数，按时间，从最早开始消费。
133+
134+
处理逻辑也可以放到里面，例如预警逻辑(采用PostgreSQL异步消息、CTE语法)。
135+
136+
[《PostgreSQL 异步消息实践 - Feed系统实时监测与响应(如 电商主动服务) - 分钟级到毫秒级的跨域》](../201711/20171111_01.md)
137+
138+
[《PostgreSQL 内存表》](../201608/20160818_01.md)
139+
140+
```
141+
CREATE OR REPLACE FUNCTION public.consume_batch(integer,integer)
142+
RETURNS void
143+
LANGUAGE plpgsql
144+
STRICT
145+
AS $function$
146+
declare
147+
suffix int := mod($1, 2048);
148+
begin
149+
-- 带流式处理业务逻辑的例句(采用CTE语法)：
150+
-- with t1 as (delete from t_sensor$suffix where ctid = any(array(select ctid from t_sensor$suffix limit 1000)) returning *)
151+
-- select pg_notify('channel_name', 'reason:xxx::::'||row_to_json(t1)) from t1 where ......;
152+
--
153+
-- 如果有多个判断基准，可以先存入TMP TABLE，再到TMP TABLE处理。
154+
-- 使用普通的TMP table或者使用内存TMP TABLE。
155+
-- [《PostgreSQL 内存表》](../201608/20160818_01.md)
156+
157+
-- 本例仅测试不带处理逻辑，只消费的情况，关注消费速度。
158+
execute format('delete from t_sensor%s where ctid = any(array(select ctid from t_sensor%s limit %s))', suffix, suffix, $2);
159+
end;
160+
$function$;
161+
```
162+
163+
### 5、准备测试数据
164+
165+
### 6、准备测试脚本
166+
同时压测写入和消费。
167+
168+
1、高吞吐写入测试，100万个传感器，每批1000条。
169+
170+
```
171+
vi test.sql
172+
173+
\set sid random(1,1000000)
174+
select ins_batch(:sid, 1000);
175+
```
176+
177+
压测
178+
179+
```
180+
CONNECTS=28
181+
TIMES=300
182+
export PGHOST=$PGDATA
183+
export PGPORT=1999
184+
export PGUSER=postgres
185+
export PGPASSWORD=postgres
186+
export PGDATABASE=postgres
187+
188+
pgbench -M prepared -n -r -f ./test.sql -P 5 -c $CONNECTS -j $CONNECTS -T $TIMES
189+
```
190+
191+
2、高吞吐消费测试，100万个传感器，每批1000条。
192+
193+
```
194+
vi test.sql
195+
196+
\set sid random(1,1000000)
197+
select consume_batch(:sid, 1000);
198+
```
199+
200+
压测
201+
202+
```
203+
CONNECTS=28
204+
TIMES=300
205+
export PGHOST=$PGDATA
206+
export PGPORT=1999
207+
export PGUSER=postgres
208+
export PGPASSWORD=postgres
209+
export PGDATABASE=postgres
210+
211+
pgbench -M prepared -n -r -f ./test1.sql -P 5 -c $CONNECTS -j $CONNECTS -T $TIMES
212+
```
213+
214+
### 7、测试
215+
216+
1、高吞吐写入测试，100万个传感器，每批1000条。
217+
218+
```
219+
transaction type: ./test.sql
220+
scaling factor: 1
221+
query mode: prepared
222+
number of clients: 28
223+
number of threads: 28
224+
duration: 300 s
225+
number of transactions actually processed: 581437
226+
latency average = 14.446 ms
227+
latency stddev = 12.231 ms
228+
tps = 1937.869058 (including connections establishing)
229+
tps = 1937.999398 (excluding connections establishing)
230+
script statistics:
231+
- statement latencies in milliseconds:
232+
0.002 \set sid random(1,1000000)
233+
14.445 select ins_batch(:sid, 1000);
234+
```
235+
236+
2、高吞吐消费测试，100万个传感器，每批1000条。
237+
238+
```
239+
transaction type: ./test1.sql
240+
scaling factor: 1
241+
query mode: prepared
242+
number of clients: 28
243+
number of threads: 28
244+
duration: 300 s
245+
number of transactions actually processed: 1254322
246+
latency average = 6.697 ms
247+
latency stddev = 10.925 ms
248+
tps = 4180.897450 (including connections establishing)
249+
tps = 4181.104213 (excluding connections establishing)
250+
script statistics:
251+
- statement latencies in milliseconds:
252+
0.002 \set sid random(1,1000000)
253+
6.696 select consume_batch(:sid, 1000);
254+
```
255+
256+
#### 一、 TPS
257+
同时压测写入和消费的吞吐如下：
258+
259+
##### 1、数据写入速度： 193万 行/s。
260+
261+
##### 2、数据消费速度： 418万 行/s。
262+
263+
#### 二、 平均响应时间
264+
同时压测写入和消费的吞吐如下：
265+
266+
##### 1、数据写入速度： 14.4 毫秒
267+
268+
##### 2、数据消费速度： 6.7 毫秒
269+
270+
## 参考
271+
[《PostgreSQL、Greenplum 应用案例宝典《如来神掌》 - 目录》](../201706/20170601_02.md)
272+
273+
[《数据库选型之 - 大象十八摸 - 致 架构师、开发者》](../201702/20170209_01.md)
274+
275+
[《PostgreSQL 使用 pgbench 测试 sysbench 相关case》](../201610/20161031_02.md)
276+
277+
[《数据库界的华山论剑 tpc.org》](../201701/20170125_01.md)
278+
279+
https://www.postgresql.org/docs/10/static/pgbench.html
280+

‎201711/20171107_32_pic_001.jpg‎

122 KB
Loading

0 commit comments

Comments
 (0)