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产品，测试结果可能会有所不同，因此要在生产环境中部署，最好先执行一次大规模的测试。