PostgreSQL 9.5.4数据库快速INSERT大量数据研究
背景
在一些应用场景中,需要向PostgreSQL数据库中快速装入大量的数据,比如数据库迁移,SQL日志分析等。在PG上快速插入数据有几种方案?每种方案的效率怎么样?如何调优能加快的数据装载?
场景设定
SQL日志分析是一个采集JDBC日志、分析SQL、发送分析结果工具。在分析阶段,需要解析大量的JDBC日志,并把解析后的结构化结果装入数据库供后续处理。以分析阶段为实验场景,以解析JDBC日志(多个)为开始,以完成结构化数据装入(包过索引建立完成)为结束,来测试不同方案的数据装入效率。
环境准备
- 数据库环境
名称 | 值 |
---|---|
操作系统 | CENTOS 6.5 |
CPU | Intel(R) Xeon(R) CPU E5-2698 v3 @ 2.30GHz,逻辑64核 |
内存 | 316G |
磁盘 | RAID 10,写入速度1GB/s |
数据库版本 | PostgreSQL 9.5.4 |
数据库内存参数 | shared_buffers:30G work_mem:4MB maintenance_work_mem:64MB |
数据库CPU参数 | max_worker_processes:16 |
- 建表语句
drop table if exists T_JDBC_SQL_RECORD ;
--无主键,没有用到C_BH 查询,增加insert速度先去掉
create table T_JDBC_SQL_RECORD (
C_BH VARCHAR(32) ,
C_BH_PARSE VARCHAR(32) NULL,
C_BH_GROUP VARCHAR(32) NULL,
C_BH_SQL VARCHAR(32) NULL,
DT_ZXSJ TIMESTAMP NULL,
N_RUNTIME INT NULL,
C_RZLJ VARCHAR(600) NULL,
N_STARTLINE INT NULL,
N_ENDLINE INT NULL,
N_SQLTYPE INT NULL,
N_SQLCOMPLEX INT NULL,
C_IP VARCHAR(100) NULL,
C_PORT VARCHAR(100) NULL,
C_XTBS VARCHAR(100) NULL,
N_CHECKSTATUS INT default 0,
N_SQL_LENGTH INT NULL,
N_SQL_BYTE INT NULL,
N_5MIN INT NULL,
C_METHOD VARCHAR(600) NULL,
C_PSSQL_HASH VARCHAR(300) NULL,
N_IS_BATCH INT,
N_RESULTSET INT
);
drop table if exists T_JDBC_SQL_CONTENT ;
CREATE TABLE T_JDBC_SQL_CONTENT (
C_BH VARCHAR(32) NOT NULL,
C_PSSQL_HASH VARCHAR(300) NULL,
C_SQL_TEXT varchar NULL,
C_PSSQL_TEXT varchar NULL
);
- 索引语句
create index i_jdbc_sql_record_zh01 on t_jdbc_sql_record(c_bh_group,dt_zxsj,N_CHECKSTATUS,C_PSSQL_HASH);
create index i_jdbc_sql_record_pshash on t_jdbc_sql_record(c_pssql_hash);
create index i_jdbc_sql_content_pshash on t_jdbc_sql_content(c_pssql_hash);
alter table t_jdbc_sql_content add constraint t_jdbc_sql_content_pkey primary key (C_BH);
- 异步提交和unlogged table
-- 异步提交,更改完重启数据库
alter system set synchronous_commit to off;
-- unlogged table
create unlogged table t_jdbc_sql_record
...
create unlogged table t_jdbc_sql_content
...
JDBC日志量
19个JDBC日志文件,共2G日志,600万记录方案设定
方案名称 | 方案描述 |
---|---|
方案一 | 建立结构化表及其索引,多线程单个insert装入数据 |
方案二 | 建立结构化表及其索引,多线程批量insert装入数据 |
方案三 | 建立结构化表及其索引,库设置为异步提交,多线程批量insert装入数据 |
方案四 | 建立结构化表,库设置为异步提交,多线程批量insert装入数据,建立索引 |
方案五 | 建立结构化表及其索引,表设置为unlogged table,多线程批量insert装入数据 |
方案六 | 建立结构化表,表设置为unlogged table,多线程批量insert装入数据,建立索引 |
方案七 | 建立结构化表,多线程批量insert装入数据,建立索引 |
实验结果
每次实验时,解析的JDBC日志量,解析代码和中间件环境保持不变。只调整流程顺序和数据库参数。
实验次数 | 方案一 | 方案二 | 方案三 | 方案四 | 方案五 | 方案六 | 方案七 |
---|---|---|---|---|---|---|---|
第一次 | 3596s | 2043s | 1164s | 779s | 545s | 528s | 1192s |
第二次 | 4092s | 2068s | 1283s | 843s | 528s | 528s | 1227s |
第三次 | 3891s | 2177s | 1378s | 858s | 536s | 537s | 1248s |
平均值 | 3859s | 2096s | 1275s | 826s | 536s | 531s | 1222s |
结果分析
- 方案一、方案二比较,数据库参数不变,流程顺序不变
- 方案一:单个insert提交,用时3859秒
- 方案二:批量insert提交,用时2096秒
- 方案二、方案三、方案五比较,流程顺序不变,均为建表->建索引->多线程批量插入。
- 方案二:同步提交(等待WAL日志完成),用时2096秒
- 方案三:异步提交(不等待WAL日志完成),用时1275秒
- 方案五:不记录WAL日志,用时536秒
- 方案二、方案七比较,均为同步提交
- 方案二:插入数据前建立索引,用时2096秒
- 方案七:插入数据后建立索引,用时1222秒
- 方案三、方案四比较,均为异步提交
- 方案三:插入数据前建立索引,用时1275秒
- 方案四:插入数据后建立索引,用时826秒
- 方案五、方案六比较,均为不记录WAL日志
- 方案五:插入数据前建立索引,用时536秒
- 方案六:插入数据后建立索引,用时531秒
总结
在该场景下:
- 批量提交比单个提交快55%
- 异步提交比同步提交快40%
- 不记录日志提交比同步提交快75%
- 记录日志且同步提交时,后建立索引比先建立索引快40%
- 记录日志且异步提交时,后建立索引比先建立索引快35%
- 不记录日志时,后建立索引比先建立索引略快,但差别不大
插入数据最快组合为:
unlogged table + 多线程批量insert+后建索引
猜想:
在insert过程中,维护索引的时间占总时间的35%到40%,且主要花费在日志持久化上。
其他:
同时在实验过程中的一些其他指标信息,如不同方案下数据库的写IO从未超过100MB/s,需要继续分析。