PostgreSql性能测试

# PostgreSql性能测试

## 1. 环境
+ 版本：9.4.9
+ 系统：OS X 10.11.5
+ CPU：Core i5 2.7G
+ 内存：16G
+ 硬盘：256G SSD

## 2. 测试情况

### 2.1 测试表结构

```sql
/*
Navicat Premium Data Transfer

Source Server : postgresql
Source Server Type : PostgreSQL
Source Server Version : 90409
Source Host : localhost
Source Database : postgres
Source Schema : public

Target Server Type : PostgreSQL
Target Server Version : 90409
File Encoding : utf-8

Date: 09/10/2016 16:59:58 PM
*/

-- ----------------------------
-- Table structure for bi_object
-- ----------------------------
DROP TABLE IF EXISTS "public"."bi_object";
CREATE TABLE "public"."bi_object" (
"id" int8 NOT NULL DEFAULT nextval(‘id_seq‘::regclass),
"features" jsonb,
"creator" varchar(64) COLLATE "default",
"type" int2,
"is_deleted" bool,
"gmt_create" timestamp(6) NULL,
"gmt_modify" timestamp(6) NULL
)
WITH (OIDS=FALSE);
ALTER TABLE "public"."bi_object" OWNER TO "postgres";

COMMENT ON COLUMN "public"."bi_object"."id" IS ‘对象ID，主键‘;
COMMENT ON COLUMN "public"."bi_object"."features" IS ‘对象特征集合，json结构‘;
COMMENT ON COLUMN "public"."bi_object"."type" IS ‘对象类型‘;
COMMENT ON COLUMN "public"."bi_object"."is_deleted" IS ‘是否已删除‘;
COMMENT ON COLUMN "public"."bi_object"."gmt_create" IS ‘创建时间‘;

-- ----------------------------
-- Primary key structure for table bi_object
-- ----------------------------
ALTER TABLE "public"."bi_object" ADD PRIMARY KEY ("id") NOT DEFERRABLE INITIALLY IMMEDIATE;
```

### 2.2 测试数据

数据量：500万条；

样例数据：
```sql
insert into "public"."Object" ( "gmt_modify", "id", "gmt_create", "type", "features", "creator", "is_deleted") values ( null, ‘1‘, ‘2016-09-10 15:35:32‘, ‘1‘, ‘{"age": 18, "sex": 1, "city": "Hangzhou", "height": 180, "userId": 1, "weight": 70, "country": "China", "userName": "zhenmo"}‘, ‘zhenmo‘, ‘f‘) RETURNING *;
```

### 2.3 插入性能测试

+ 只有主键索引的情况下，插入500万条记录测试结果

执行sql：
```sql
insert into bi_object(creator, features, gmt_create, is_deleted, type)
select ‘zhenmo‘, row_to_json(bi_user)::jsonb, now(), false, 1 from bi_user
```

执行结果：
```
Affected rows : 5000000, Time: 51.24sec
```

平均：97580条/秒

+ 除了主键，单个B-Tree索引的情况下，插入500万条记录测试

执行sql：同上

执行结果：
```
Affected rows : 5000000, Time: 194.78sec
```

索引对于插入数据的**性能影响非常大**，带有索引后插入速度慢了近4倍。

+ 除了主键，单个GIN索引的情况下，插入500万条记录测试

执行sql：同上

执行结果：
```
Affected rows : 5000000, Time: 100.40sec
```

**测试了几次，时间稳定在50秒多一点**

### 2.4 查询性能测试

#### 2.4.1 无索引查询

执行sql：
```sql
explain analyze select id, features from bi_object where features->>‘name‘ = ‘user_4000000‘;
```

执行结果：
```
Seq Scan on bi_object (cost=0.00..177028.79 rows=25000 width=113) (actual time=1234.339..1520.186 rows=1 loops=1)
Filter: ((features ->> ‘name‘::text) = ‘user_4000000‘::text)
Rows Removed by Filter: 4999999
Planning time: 0.044 ms
Execution time: 1520.204 ms
```

**测试了多次，时间稳定在1.5秒左右**

#### 2.4.2 创建索引
+ 创建B-Tree索引

执行sql：
```sql
create index idx_bi_object_features_name on bi_object using btree ((features ->> ‘name‘));
```
执行结果：
```
OK, Time: 183.59sec
```

可见创建索引**耗时比较很长**

+ 创建jsonb字段单个key的GIN索引

执行sql：
```sql
create index idx_bi_object_features_name on bi_object using gin ((features -> ‘name‘));

```

执行结果：
```
OK, Time: 26.82sec
```

+ 创建jsonb字段GIN索引，索引class为默认的jsonb_ops

执行sql：
```sql
create index idx_bi_object_features on bi_object using gin (features);
```

执行结果：
```
OK, Time: 85.74sec
```

+ 创建jsonb字段GIN索引，索引class为默认的jsonb_ops

执行sql：
```sql
create index idx_bi_object_features on bi_object using gin (features jsonb_path_ops);
```

执行结果：
```
OK, Time: 74.71sec
```

#### 2.4.3 使用索引查询

+ 使用B-Tree索引（为features.name单独建立索引）查询

执行sql：
```sql
explain analyze select id, features from bi_object where features->>‘name‘ = ‘user_4000000‘;
```

执行结果：
```
Bitmap Heap Scan on bi_object (cost=582.20..58832.89 rows=25002 width=113) (actual time=0.045..0.045 rows=1 loops=1)
Recheck Cond: ((features ->> ‘name‘::text) = ‘user_4000000‘::text)
Heap Blocks: exact=1
-> Bitmap Index Scan on idx_bi_object_features_name (cost=0.00..575.95 rows=25002 width=0) (actual time=0.041..0.041 rows=1 loops=1)
Index Cond: ((features ->> ‘name‘::text) = ‘user_4000000‘::text)
Planning time: 0.055 ms
Execution time: 0.061 ms
```

添加索引前查询耗时：1520.204 ms，创建索引后查询耗时：0.061 ms，查询速度提升：24921倍

+ 使用GIN索引（为features.name单独建立索引，索引class为默认的jsonb_ops）查询

执行sql：
```sql
explain analyze select * from bi_object where features->‘name‘ ? ‘user_4000000‘;
```

执行结果：
```
Bitmap Heap Scan on bi_object (cost=66.75..16463.02 rows=5000 width=139) (actual time=0.021..0.022 rows=1 loops=1)
Recheck Cond: ((features -> ‘name‘::text) ? ‘user_4000000‘::text)
Heap Blocks: exact=1
-> Bitmap Index Scan on idx_bi_object_features_name (cost=0.00..65.50 rows=5000 width=0) (actual time=0.012..0.012 rows=1 loops=1)
Index Cond: ((features -> ‘name‘::text) ? ‘user_4000000‘::text)
Planning time: 0.062 ms
Execution time: 0.043 ms
```

相比较B-Tree索引，查询速度并没有提升很多，但是GIN索引占用的存储空间却是B-Tree的3倍左右，这样看来使用GIN索引并不是一个好选择。

+ 将整个jsonb字段建立GIN索引(索引class为默认的jsonb_ops)后查询

执行sql：
```sql
explain analyze select * from bi_object where features @> ‘{"name":"user_4000000"}‘;
```

执行结果：
```
Bitmap Heap Scan on bi_object (cost=86.75..16470.52 rows=5000 width=139) (actual time=0.100..0.100 rows=1 loops=1)
Recheck Cond: (features @> ‘{"name": "user_4000000"}‘::jsonb)
Heap Blocks: exact=1
-> Bitmap Index Scan on idx_bi_object_features (cost=0.00..85.50 rows=5000 width=0) (actual time=0.091..0.091 rows=1 loops=1)
Index Cond: (features @> ‘{"name": "user_4000000"}‘::jsonb)
Planning time: 0.064 ms
Execution time: 0.123 ms
```

<code>疑问：</code>
一下查询没有用到索引，感觉很奇怪，在单独为features.name建立的GIN索引时，可以利用索引查询，但是为features建立索引后，再次查询却不会使用索引，而官方文档却说可以支持‘?‘，操作很疑惑：什么鬼？？GIN的脾气很奇怪。

执行sql：
```sql
explain analyze select * from bi_object where features->‘name‘ ? ‘user_4000000‘;
```

执行结果：
```
Seq Scan on bi_object (cost=0.00..177030.00 rows=5000 width=139) (actual time=100.820..2059.617 rows=1 loops=1)
Filter: ((features -> ‘name‘::text) ? ‘user_4000000‘::text)
Rows Removed by Filter: 4999999
Planning time: 0.051 ms
Execution time: 2059.635 ms
```

+ 将整个jsonb字段建立GIN索引(索引class为jsonb_path_ops)后查询

执行sql：
```sql
explain analyze select * from bi_object where features @> ‘{"name":"user_4000000"}‘;
```

执行结果：
```
Bitmap Heap Scan on bi_object (cost=66.75..16450.52 rows=5000 width=139) (actual time=0.019..0.019 rows=1 loops=1)
Recheck Cond: (features @> ‘{"name": "user_4000000"}‘::jsonb)
Heap Blocks: exact=1
-> Bitmap Index Scan on idx_bi_object_features (cost=0.00..65.50 rows=5000 width=0) (actual time=0.012..0.012 rows=1 loops=1)
Index Cond: (features @> ‘{"name": "user_4000000"}‘::jsonb)
Planning time: 0.065 ms
Execution time: 0.045 ms
```

看一看出来2和4两次实验的查询速度接近，4比2的查询速度有了明显提升。2和4两次查询区别在于两点，前者使用的是GIN索引class是jsonb_ops，后者是jsonb_path_ops。后者仅支持‘@>‘操作，前者支持‘? ?& ?| @>‘等操作。按照官方文档的说法jsonb_path_ops的性能要高于jsonb_ops，这一点已经得到验证，并且前者占用的空间要小，以本次实验为例，jsonb_ops索引占用空间为686M，而jsonb_path_ops占用空间为446M。实际情况来看宁可牺牲点空间

+ jsonb类型的字段的某个key单独建立B-Tree索引

说明：jsonb类型的字段features的age建立B-Tree索引，然后使用索引检索。

执行sql：

step1：建立索引
```sql
create index idx_bi_object_features_age on bi_object using btree (((features ->> ‘age‘)::integer));
```
step2：查询，注意建立索引时指定的类型是integer那么查询也需要将数据转换成integer，其他的int类型如int2是不会使用索引查询的，这一点不友好，建议pg可以兼容所有int类型
```sql
explain analyze select * from bi_object where (features->>‘age‘)::integer = 50;
```

执行结果：
```
Bitmap Heap Scan on bi_object (cost=470.19..58840.83 rows=25000 width=139) (actual time=39.967..251.822 rows=50174 loops=1)
Recheck Cond: (((features ->> ‘age‘::text))::integer = 50)
Heap Blocks: exact=39786
-> Bitmap Index Scan on idx_bi_object_features_age (cost=0.00..463.94 rows=25000 width=0) (actual time=17.719..17.719 rows=50174 loops=1)
Index Cond: (((features ->> ‘age‘::text))::integer = 50)
Planning time: 0.082 ms
Execution time: 255.228 ms
```

即便是使用了索引，查询速度依然不理想，看来<code>jsonb字段建立的btree索引效率相较于普通字段的btree来说效率很差</code>，慢了差不多4200多倍。

#### 2.4.5 删除测试

删除500万条记录测试

执行sql：
```sql
delete from bi_object
```

执行结果：
```
Affected rows : 5000000, Time: 14.12sec
```

#### 2.4.6 表占用磁盘大小

表bi_object记录数5000000，建立单个字段B-Tree索引后总共占用磁盘1055M，其中索引258M，索引约占用1/4的空间。将索引类型改为GIN索引后，磁盘空间占用增大到1376M，索引占579M。详见下表：

|索引|类型|大小（M）|备注|
|---|----|-------|---|
|Object_pkey|B-Tree|107||
|idx_bi_object_features_name|B-Tree|151||
|idx_bi_object_features_name|GIN|472|索引class为默认的jsonb_ops|
|idx_bi_object_features|GIN|686|索引class为默认的jsonb_ops|
|idx_bi_object_features|GIN|446|索引class为jsonb_path_ops|

GIN索引占用的空间是B-Tree的3倍多。

## 3. 总结

### 3.1 我们的使用场景

我们需要为一类对象动态计算其所具有的特征，具体到一张表中来说，就是一个主键对应多个列，但是列的个数是不定的，会经常增加。同时了为了便于和其他关系表做关联查询，保证快速的查询响应时间，我们需要将其存储在关系型数据库中。由于列的数量动态变化，频繁修改表字段肯定不可取，所以想到将其存储到JSON字段中。

### 3.2 可以利用的资源

我们的应用环境依托于阿里云数加环境，数加的rds只提供了mysql5.6版本（5.7版本的mysql才支持json类型）和postgresql 9.4版，postgresql支持json和jsonb类型（后者存储空间小，支持部分索引操作）。所以我们决定采用postgresql作为数据存储工具。

### 3.3 频繁的查询

实际频繁查询的情况是，需要利用jsonb字段中的某些key来组合做条件查询，比如：features->‘age‘ >= 20 and features->‘age‘ < 30等

### 3.4 结论及问题

结合上面的测试，postgresql基本满足了我们的应用场景需求。在写入速度、简单查询响应时间、存储动态数据等方面都可以满足。

测试下来发现的一个潜在的问题就是jsonb类型字段的gin索引的不支持按范围检索，需要做全表扫描。postgresql的jsonb字段建立gin索引后，只支持精确查询，无法做范围检索，这样会导致查询比较慢。本地测试下来500万条记录检索时间是2秒多，以后如果数据量增大，那么很有可能导致查询超时。

时间： 2024-10-11 23:29:19

PostgreSql性能测试的相关文章

基于Jmeter的PostgreSQL空间性能测试笔记

这是很早之前做过的一个测试,最近在整理postgresql测试相关的资料,所以也把它拿出来了与大家分享. 首先解释一下所谓的PostgreSQL空间性能,主要是基于postgis的空间数据导入性能,详细的postgis知识请baidu,下面记录一下整个测试过程. PostgreSQL中空间图层手动创建 1.  跳过PostgreSQL.postgis和jmeter的部署操作(如果此步骤不会跳过一下所有步骤) 2.  创建模板为postgis数据库的数据库,创建成功的数据库模式中存在topolog

Postgresql 报表性能测试

1. 测试数据 表结构 一: CREATE TABLE fact_data ( day_id integer, popdb_id integer, region_id integer, area_id integer, city_id integer, product_id integer, f1 integer, f2 integer, f3 integer, f4 integer, f5 integer, f6 integer, f7 integer, f8 integer, user_id

Mysql多线程性能测试工具sysbench 安装、使用和测试

From:http://www.cnblogs.com/zhoujinyi/archive/2013/04/19/3029134.html 摘要:      sysbench是一个开源的.模块化的.跨平台的多线程性能测试工具,可以用来进行CPU.内存.磁盘I/O.线程.数据库的性能测试.目前支持的数据库有MySQL.Oracle和PostgreSQL.当前功能允许测试的系统参数有: file I/O performance (文件I / O性能) scheduler performance (调

几个性能测试工具

我个人认为一个优秀的软件工程师必须掌握一定的测试技能.可能有的开发工程师认为测试是测试工程师的事情,不是开发工程师的事情.这种开发工程师是缺一条腿的,离开了测试工程师,你如何证明你的程序没有问题. 下面是我这两天搜集的性能测试工具,如果大家知道别的工具,可以在回复中分享出来. Web Bench Web Bench is very simple tool for benchmarking WWW or proxy servers. Uses fork() for simulating multi

mysql几种性能测试的工具使用

mysql几种性能测试的工具使用 近期由于要比较mysql及其分支mariadb, percona的性能,了解了几个这方面的工具,包括:mysqlslap sysbench tpcc-mysql,做一个整理,备忘,分享 1.mysqlslap 安装:简单,装了mysql就有了 作用:模拟并发测试数据库性能. 优点:简单,容易使用. 不足:不能指定生成的数据规模,测试过程不清楚针对十万级还是百万级数据做的测试,感觉不太适合做综合测试,比较适合针对既有数据库,对单个sql进行优化的测试. 使用方法:

SQLite介绍、学习笔记、性能测试

SQLite介绍.学习笔记.性能测试 哪些人,哪些公司或软件在用SQLite: Nokia's Symbian,Mozilla,Abobe,Google,阿里旺旺,飞信,Chrome,FireFox可见SQLite的稳定性及性能是不会有什么问题的,详细列表请参见:http://www.sqlite.org/famous.html. 网上关于SQLite的介绍一抓一大把,总结起来,他有如下特点: SQLite优点及适应场合: 轻量级绿色组件单一文件跨平台查询效率极高使用事务插入速度极快支持limi

性能测试分析软件汇总–开源、商业全部收集

本文共包含:商业性能测试.监控.分析工具和免费.开源性能测试监控分析工具:共涉及java.php.net等各种开发语言平台,有系统性能分析.文件系统分析.微博.系统分析.数据性能分析等各种工具,可以说本文包含了现有的所有的性能测试监控分析工具工具133种. Java程序性能分析工具 VisualVM VisualVM是一个集成多个JDK命令行工具的可视化工具.可以作为Java应用程序性能分析和运行监控的工具.开发人员可以利用它来监控.分析线程信息,浏览内存堆数据.系统管理员可以利用它来监测.控制

数据库性能测试

12月10日,前阿里数据库团队资深DBA杨奇龙老师,在[DBA+社群]北京群进行了一次主题为"数据库性能测试"的线上分享.小编特别整理出其中精华内容,供大家学习交流.同时,也非常感谢杨奇龙老师对DBA+社群给予的大力支持. 嘉宾简介 杨奇龙 前阿里数据库团队资深DBA 主要负责淘宝业务线,经历多次11.11,有海量业务访问DB架构设计经验. 目前就职于有赞科技DBA,负责数据库运维工作,熟悉MySQL 性能优化,故障诊断,性能压测,对NoSQL感兴趣,希望与大家多多交流,彼此一起成长.

数据库性能测试---前阿里数据库团队资深DBA杨奇龙

杨奇龙 前阿里数据库团队资深DBA 主要负责淘宝业务线,经历多次11.11,有海量业务访问DB架构设计经验. 目前就职于有赞科技DBA,负责数据库运维工作,熟悉MySQL 性能优化,故障诊断,性能压测,对NoSQL感兴趣,希望与大家多多交流,彼此一起成长. 内容摘要 压测方法论 为什么要压测 影响因素 统计的指标 常用的压测工具 合理的压测平台 参考 这个是此次分享的大纲,本次分享其实相对比较简单,偏向于“纸上谈兵” 不涉及具体的实践操作,没有介绍工具如何使用 ,更多是介绍我对MySQL 压测的