PostgreSQL 9.5.4数据库快速INSERT大量数据研究

PostgreSQL 9.5.4数据库快速INSERT大量数据研究

背景

在一些应用场景中,需要向PostgreSQL数据库中快速装入大量的数据,比如数据库迁移,SQL日志分析等。在PG上快速插入数据有几种方案?每种方案的效率怎么样?如何调优能加快的数据装载?

场景设定

SQL日志分析是一个采集JDBC日志、分析SQL、发送分析结果工具。在分析阶段,需要解析大量的JDBC日志,并把解析后的结构化结果装入数据库供后续处理。以分析阶段为实验场景,以解析JDBC日志(多个)为开始,以完成结构化数据装入(包过索引建立完成)为结束,来测试不同方案的数据装入效率。

环境准备

  • 数据库环境
名称
操作系统CENTOS 6.5
CPUIntel(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日志量,解析代码和中间件环境保持不变。只调整流程顺序和数据库参数。

实验次数方案一方案二方案三方案四方案五方案六方案七
第一次3596s2043s1164s779s545s528s1192s
第二次4092s2068s1283s843s528s528s1227s
第三次3891s2177s1378s858s536s537s1248s
平均值3859s2096s1275s826s536s531s1222s

结果分析

  • 方案一、方案二比较,数据库参数不变,流程顺序不变
    • 方案一:单个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,需要继续分析。

    原文作者:PostgreSQL
    原文地址: https://www.cnblogs.com/wangzhen3798/p/7994212.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞