JDBC数据库插入性能测试

版本

2008年8月21日，完成测试1的Oracle_Win、Mysql_Li、Mysql _Win、MSSQL部分。
2008年8月22日，完成测试2的Oracle_Win、Mysql_Li、Mysql _Win、MSSQL部分。

2008年8月23日，文档整理。

2008年8月25日，完成postgresql linux版本的测试1、测试2。
2008年8月27日，完成postgresql windows版本的测试1、测试2。

1.背景
这不是数据库性能的综合测试，这里只测试插入，并且是用JDBC插入。这是针对某种应用的某模块的简单模拟，不可能适用所有的情况。
假设系统的基本情况是，有后台线程要不停的读取数据，并写入流水表，写入以后就不会update。没有人使用系统的时候，就没有查询，偶尔才会有人来使用。查询的时候，因为数据量比较大，性能优化也是一个重要的问题，但不在本文讨论范围之内。

本文还没有完成，测试3还没有进行，并缺少Oracle Linux版本和PostgreSQL的数据。计划将来补上。

2.测试方法

测试1，简单表测试
建立3个一模一样的小表，只有3个数字类型的字段，一个主键，没有另外建索引。对不同的数据库执行以下测试：
A.用1个线程写一个表
B.用2个线程同时写2个不同的表
C.用2个线程写同一个表
D.用3个线程同时写3个不同的表
E.用3个线程写同一个表
每50条为一批进行批量操作，每5秒进行一次采样，稳定运行一段时间以后，取每秒插入的数据条数进行比较。用多个线程并发进行操作可以检查对双核CPU的利用效果。

测试2，普通表测试
与测试1相同，但是表不一样，建立3个一模一样的表。表包含10个各种字段，另外再单独建3个索引。

测试3，超大表测试（TODO）
与测试1相同，但是表不一样，建立3个一模一样的表。表包含100个以上的字段，10个索引。系统中有类似这样的流水表。

 

3.环境定义
3.1.硬件环境定义
笔记本
CPU Core Duo T2350（双核，1.86G）
硬盘120G
内存2G

Java程序和数据库跑在一个机器上测试确实不太好，不过只有这样的条件。另外，在小型客户那里的生产环境，有把数据库和Java应用服务器安装在一个机器的情况，因此这样也能说明一些问题。

3.2.操作系统定义
Windows平台：Windows XP Pro SP2，文件系统NTFS
Linux平台：Ubuntu 8.04，文件系统EXT3

Windows 平台上已经尽可能停用了无关的程序，比如杀毒软件等。
CPU在负载低的时候会自动降频到800M，在Windows下，使用软件RMClock将主频强制稳定在1.86G，避免CPU频率调整可能带来的性能波动。Linux下没有做这个处理（因为不知道用什么软件）。
为了偷懒是在Eclipse里面运行的，不过应该没有太多的影响。程序在循环中没有生成垃圾对象，不清楚数据库驱动程序会不会，但是应该不会频繁GC吧。

3.3.待测试数据库环境定义

 

数据库	OS	缩写	说明
Oracle 10g 10.2.01	Windows	Oracle_win	JDBC驱动程序用的安装Oracle后自带的。先整理磁盘碎片，然后建立新的表空间和用户，数据表空间5G，临时表空间200M，重做日志文件3×50M。
Oracle 10g 10.2.01	Linux	Oracle_Li
MS SQL Server 2005 SP2	Windows	MSSQL	JDBC驱动程序为jtds1.2.2。磁盘碎片整理后建立数据库文件5G，日志文件100M。
MySQL 5.1.26 RC	Linux	Mysql_Li	存储引擎为InnoDB。JDBC驱动为mysql-connector-java-5.1.6-bin.jar
MySQL 5.1.26 RC	Windows	Mysql_Win	存储引擎为InnoDB。JDBC驱动为mysql-connector-java-5.1.6-bin.jar
Postgresql 8.3.3	Linux	Pgsql_Li	JDBC3 Postgresql Driver, Version 8.3-603。
Postgresql 8.3.3	Windows	Pgsql_Win	JDBC3 Postgresql Driver, Version 8.3-603。

数据库没有再做什么优化，简单的调整内存之类的参数，对测试结果基本没有影响。

4.测试结果

明细结果在附件（Eclipse工程）的result中。有的测试重复做过多次，基本上数据都是稳定的。
文件名命名规则是：数据库_s_线程数_表相同或不相同，s表示simple，n表示normal

输出每行表示一次采样，5秒1次，“本阶段平均”表示这5秒的平均速度，“共处理”是进程启动以后处理记录的总和，“平均”是根据启动后处理的记录总数和总时间计算出来的：

normal_evt 2170/s normal_evt 2050/s normal_evt 2170/s 本阶段平均6390/s 共处理3,1950条 平均6390/s


4.1.结果数据

测试1，简单表，3字段，1主键，无索引

条/秒	1线程1表	2线程2表	2线程1表	3线程3表	3线程1表
Oracle_Li
Oracle_Win	3,7205	5,6065	4,2437	5,0640	4,6861
Mysql_Li	1,0287	2,0449	1,2751	2,0397	1,4239
Mysql_Win	1020	1173	1167	1706	1671
MSSQL	2975	5584	5561	7705	7703
Pgsql_Li	1,3882	2,1870	2,2225	2,2402	2,4181
Pgsql_Win	1,0241	1,7287	1,7323	1,7153	1,8160

测试2，普通表，10字段，1主键，3索引

条/秒	1线程1表	2线程2表	2线程1表	3线程3表	3线程1表
Oracle_Li
Oracle_Win	1,9989	2,2001	1,8419	2,2442	1,8643
Mysql_Li	5857	1,0226	5890	1,0204	6180
Mysql_Win	973	1152	1142	1685	1595
MSSQL	2692	5155	5150	7173	6922
Pgsql_Li	8763	1,1492	1,2935	1,0141	1,2517
Pgsql_Win	7043	9997	9671	1,2274	1,2645

4.2.结果分析
不同的数据库在不同的方式下表现不一样，取最好的成绩，结果是Oracle_Win > Mysql_Li > MSSQL >> Mysql_Win。具体情况可以看上面的表。
除了Oracle以外，其他的数据库插入的性能都很稳定。
CPU占用率通常在20%~60%之间，随着线程数的增加略有提高。

下面对单个数据库做分析：
4.2.1.Mysql_Li

mysql的特点是，当使用2个线程插入2个不同的表时，性能立刻提高了整整一倍，使用3个线程插入3个表的时候却，相比2线程2表没有提高。看起来，要用至少两个线程才能充分利用双核的两个CPU（其实是4个线程，2个java线程，2个数据库线程，但是java线程资源占用率较小，主要瓶颈还是在数据库）。
当使用多个线程同时入1个表时，性能只是稍微有点提高。

4.2.2.Mysql_Win
都说Mysql Windows版本性能不行，没想到差那么多。但是有两个很有意思的特点（MS SQL差不多也有这样的特点）：第一是测试2的数据比测试1几乎没有下降，而测试2的表要复杂的多，看来mysql有个瓶颈在我们不知道的地方，使得面对一个很简单的表，速度也上不去；第二是不断增加线程，性能始终能够提高，后来我又做了4线程和5线程的测试，仍然如此，不过提高的幅度越来越小。

4.2.3.Oracle_Win
插入性能很不稳定。如果把采样时间缩短为1秒，会发现大部分时间性能是基本稳定的，但每隔一小段时间，会基本失去响应（插入速度能降低到200以下），估计是重做日志的切换引起的，Oracle重做日志是3×50M。
随着数据量的增加，性能稍有下降，因此每次测试先都先truncate表，测试1的5次运行每次都在单表数据量达到1000w时结束测试，测试2在500w时结束测试。尚未测试在极大的数据量情况下会怎么样，但oracle在这种情况下的表现应该是久经考验的，估计可能到了一定的程度会稳定吧。

oracle的数据相当的好，并且其他数据库往往需要增加线程来获得更好的成绩，而oracle在1个线程的情况下能得到相对最好的成绩，增加线程以后提高不多。
当使用2个线程入2个表时，测试1提高50%，测试2略微提高。3个线程入3表则没有提高。
多个线程入同一个表的时候，测试1性能只有一些提高，而测试2竟出现了下降，但这种情况也不是不可思议的，测试2有10个字段，包括主键有4个索引，多个线程可能在争夺资源中出现了锁定。

cpu占有率波动很大，通常在10%~70%左右以大约20秒的周期剧烈波动，随着线程数的增加，占有率稍有上升。cpu占有率低时，写入速度也急剧下降，应该是切换重做日志引起。

最初做Oracle这个测试的时候，是把表建在一个已经有很多数据的表空间里面。后来，做碎片整理，然后新建表空间和用户，再测试，性能提高了30%。

4.2.4.MSSQL
MSSQL的特点和Windows下的Mysql差不多，测试1和测试2数据相当，似乎有别的瓶颈。刚开始的时候，数据真是非常可怜（与它假象的对手oracle相比），不过在增加线程后出现了可观的提高，不然就要沦落为和Mysql_win一个量级了。

 4.2.5.Pgsql_Li
Postgresql的数据比mysql略高。

 4.2.6.Pgsql_Win
postgresql在windows下性能只出现了少量下降。有一个特点是在3个线程的时候CPU占用率接近到100%。