CUBRID数据库和MySQL使用SSD前后性能测试对比-DBMNG数据库管理与应用网

目录 / 分类

数据库基础

Access

SQLServer

MySQL

SQLite

Oracle

PostgreSQL

移动应用

经验分享

服务器配置

网文摘录

下载中心

软件下载

CUBRID数据库

介绍及使用

验证/二维/条形码

当前位置：首页 > 网文摘录 > 行业新闻

CUBRID数据库和MySQL使用SSD前后性能测试对比

MySQL在收归Oracle之后，人们开始寻找MySQL的代替品，甚至出现了MySQL的新分支，同样为开源数据库的CUBRID开始进入越来越多人的视线，在维基百科上是这样介绍CUBRID的：

　　“CUBRID 是一个广泛使用的免费开源关系数据库，该数据库为高效执行网络应用程序进行了高度优化，特别适合大数据量和高并发请求的业务逻辑。通过提供独特的优化特性，CUBRID可以支持更多的并发请求，更少的响应时间。使用CUBRID的公司可以得到更好的性能，高可靠性，灵活性，扩展性和高可用性，为其重要客户提供7*24小时的持续服务”

　　CUBRID被韩国IT业的领头企业NHN公司大量的使用，该公司部署了超过一万台CUBRID服务器，看来它的确和MySQL有得一比，本文主要测试两者的性能，我们同时在HDD硬盘和SSD硬盘上完成了测试，为了保证公平，每个数据库(CUBRID和MySQL)都安装在两台服务器上，一个配HDD硬盘，一个配SSD硬盘，因此我们总共准备了4台测试用机。

　　测试机环境

　　为了保证准确区分出使用HDD和使用SSD时两个数据库之间的性能差异，除硬盘外，测试用机的其它硬件配置全部一样，具体配置如下：

	HDD测试机	SSD测试机
操作系统	CentOS 5.2 x86-64	CentOS 5.3 x86-64
CPU	至强四核2.5GHz*2	至强2.26GHz（L5640）2路6核
内存	2G*4	8G
硬盘	RAID 0+1 SAS 300G*6	RAID 0+1 100G*6

　　每台测试机都安装上CUBRID和MySQL数据库，CUBRID使用2008 R3.0版本，MySQL使用5.1.47(innoDB)。下面是CUBRID和MySQL的默认配置，数据缓冲区大小均设为4G，为了体现公平，测试时均采用了默认配置，未做任何调整和优化。

　　CUBRID配置(cubrid.conf)

[service]
service=server,broker,manager

[common]
data_buffer_pages=25000
sort_buffer_pages=16
log_buffer_pages=50
lock_escalation=100000
lock_timeout_in_secs=-1
deadlock_detection_interval_in_secs=1
checkpoint_interval_in_mins=720
isolation_level="TRAN_REP_CLASS_UNCOMMIT_INSTANCE"
cubrid_port_id=15097
max_clients=50
auto_restart_server=yes
replication=no
java_stored_procedure=no

checkpoint_every_npages=100000000
data_buffer_pages=262144
error_log_level=notification
communication_histogram=yes
num_LRU_chains=200
async_commit=yes
group_commit_interval_in_msecs=1000

　　MySQL配置(my.cnf)

[client]
socket = /home1/mysql/mysql/tmp/mysql.sock

[mysqld]
user = mysql
port = 3306
basedir = /home1/mysql/mysql
datadir = /home1/mysql/mysql/data
tmpdir = /home1/mysql/mysql/tmp
socket = /home1/mysql/mysql/tmp/mysql.sock

default-character-set = utf8
default_table_type = InnoDB
skip_name_resolve

back_log = 100
max_connections = 500
max_connect_errors = 999999
max_allowed_packet = 16M
max_heap_table_size = 64M
tmp_table_size = 64M
binlog_cache_size = 1M
thread_cache_size = 128

table_cache = 1024
sort_buffer_size = 8M
join_buffer_size = 8M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
query_cache_size = 64M
query_cache_limit = 2M

# MyISAM options
key_buffer_size = 32M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_max_extra_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover
ft_min_word_len = 4

# INNODB options
innodb_buffer_pool_size = 4G # 50 ~ 70% of main memory
innodb_log_buffer_size = 8M
innodb_additional_mem_pool_size = 16M
innodb_data_file_path = ibdata1:100M:autoextend
innodb_file_per_table
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_support_xa=0
innodb_thread_concurrency = 16
innodb_lock_wait_timeout = 60
innodb_flush_log_at_trx_commit = 0 # 0 for slave, 1 for master

# Loging Configuration
log-bin=mysql-bin
expire_logs_days=5
log_warnings
log_slow_queries
log_slow_admin_statements
long_query_time = 2
log_long_format

# Replication setting
server-id = 1

　　测试场景(测试使用的表方案)

　　测试使用下面的SQL命令创建40个表名从tbl_200到tbl_239的数据表。

CREATE TABLE tbl_200;

ALTER CLASS tbl_200 ADD ATTRIBUTE
    id character varying(20) NOT NULL,
    seq integer NOT NULL,
    col3 character varying(16) NOT NULL,
    col4 character varying(5) NOT NULL,
    col5 character varying(50) NOT NULL,
    col6 character varying(1000),
    col7 character varying(300) NOT NULL,
    col8 character varying(150),
    col9 timestamp NOT NULL,
    col10 smallint DEFAULT 0 NOT NULL,
    col11 timestamp NOT NULL,
    col12 character varying(15) NOT NULL,
    col13 character(1) NOT NULL,
    col14 character(1) NOT NULL,
    col15 timestamp DEFAULT timestamp '04:25:44 PM 07/30/2009' NOT NULL;

ALTER CLASS tbl_200 ADD ATTRIBUTE
    CONSTRAINT "iuk_tbl" UNIQUE(id, col3, col4, col5),
    CONSTRAINT "ipk_tbl" PRIMARY KEY(id, seq);

CREATE INDEX ink1_tbl ON tbl_200 (id, col9 DESC, col14);

　　四台测试机运行下面三种测试。

　　1、创建数据库后，向40张表中插入2500万条记录，通过连续30分钟的INSERT FULL负载测量性能。

　　2、创建数据库后，向40张表中插入6400万条记录，通过CPU Bound SELECT负载测量性能。

　　3、创建数据库后，向40张表中插入6400万条记录，通过I/O Bound SELECT负载测量性能。

　　上面所有负载由40个线程产生，一个INSERT负载由一个INSERT查询组成，一个SELECT负载由三个SELECT查询组成，一个使用主键，一个使用唯一索引，一个使用非唯一索引。

　　I/O Bound Insert负载测试

　　创建好包含40张表的数据库，每张表插入大约62.5万条记录(总共2500万条)后，HDD和SSD测试机连续运行30分钟INSERT FULL负载性能测试，测试结果如下图所示：

图1 INSERT FULL负载测试结果

　　TPS变化情况如下图所示。

图2 INSERT FULL测试TPS值对比

　　从上面的INSERT FULL负载测试的结果可以看出：CUBRID在SSD测试机上的性能大约是在HDD测试机上的5倍，而MySQL在SSD测试机上的性能大约是HDD测试机上的2.5倍，在SSD测试机上，MySQL没有达到100%的利用率，因此性能还有上升的空间。

　　CPU Bound Select负载测试

　　创建好包含40张表的数据库，每张表插入大约160万条记录(总共6400万)后，HDD和SSD测试机连续运行10分钟CPU Bound负载测试，在这个负载中，当SELECT查询执行时，为了在内存缓冲区中分配完整的Page(页面)，追求100%的缓冲区命中率，查询请求的搜索访问应该很小。在这个负载测试中，由于没有发生I/O，因此去除了I/O相关的结果，如下图所示。

图3 CPU Bound负载测试结果

　　下图显示了TPS的变化情况。

图4 CPU Bound负载测试TPS值对比

　　当无I/O发生时，CUBRID的性能下降了大约17%，而MySQL的性能上升了约6%。

　　I/O Bound Select负载测试

　　在创建好包含40张表的数据库，并向每张表插入约160万条记录(总共6400万)后，HDD和SSD测试机连续运行10分钟I/O Bound负载测试，在这个负载中，当查询执行时，为了不在内存缓冲区中分配需要的完整Page(页面)，防止频繁地页面替换，查询请求的搜索访问应该扩大，因此当工作负载非常密集时I/O操作也会随之增多，下图显示了本次测试的结果。

图5 I/O Bound Select负载测试结果

　　下图反应了TPS的变化情况。

图6 I/O Bound Select负载测试TPS值对比

　　根据I/O Boudn SELECT负载测试结果，我们可以看出，CUBRID在SSD测试机上的TPS结果大约是HDD测试机的4.2倍，而MySQL只有2.8倍，无论如何，在使用SSD硬盘时，两者的性能都有所提升。

　　合并SELECT测试结果

　　下图显示了前面两个测试的合并结果。

图 7 CPU BOUND和IO BOUND SELECT测试合并结果

　　下图显示了TPS结果的合并效果，CPU Bound测试结果显示在左侧，I/O Bound测试结果显示在右侧。

图8 CPU BOUND和IO BOUND SELECT测试TPS合并图

　　从上图可以看出，CPU Bound的测试结果总是比I/O Bound的测试结果高，因此I/O操作是数据库性能下降的主要原因，在本次测试发现一个有趣的现象，CUBRID在SSD测试机上执行CPU Bound和I/O Bound负载测试时，它们之间的差异很小，也就是说，CUBRID更善于利用SSD硬盘的优势优化自己的性能。

　　小结

　　从本次测试可以得出一个结论，无论是CUBRID还是MySQL，在SSD测试机上的TPS结果都比HDD要高，在I/O Bound负载测试中，CUBRID的TPS值提高了4.2倍，而MySQL提高了2.8倍，并且两者都是采用的默认配置，未针对SSD硬盘专门进行优化，因此要提高双方I/O BOUND操作的性能是完全可能的，此外，如果采用其它HDD和SSD产品，测试结果可能会有所不同，因此要在生产环境中部署，最好先执行一次大规模的测试。

　　原文出处：http://www.cubrid.org/ssd_performance_test

上一篇：开源数据库CUBRID
下一篇：IBM把Informix数据库给“卖了”