Sharding-jdbc與jdbc的性能比較

0 引言

關係型資料庫憑藉靈活查詢的SQL和穩定的存儲及事務引擎，一直以來是業務存儲領域的首選。而在規模越來越大的互聯網年代，單一的關係型資料庫卻已難滿足需求。開發人員不願放棄SQL查詢的靈活度及對之前代碼的兼容性，而又無法承受數據量過大時所帶來的性能瓶頸。因此大多數互聯網公司趨向使用關係型資料庫中間件採用單體向分散式透明轉化的方案來解決數據量和訪問量巨大這兩個互聯網場景的核心問題。sharding-jdbc是一款最為常用的輕量級分庫分表的「中間件」，其架構圖如下，本文就其性能作探討。

1 測試目的

在同等數據讀寫量環境下，檢驗sharding-jdbc與單庫單表jdbc的性能比較。

2 測試場景

數據批量寫入：

批量寫入10000條數據，測試結果如下表

數據查詢:

查詢約15萬條數據所用時長，測試結果如下表

以上數據均為平均時長。

3 測試結論

在單伺服器下，相比jdbc，使用sharding-jdbc進行分庫分表後，Sharding-JDBC在查詢中的性能損失非常低，插入和更新略高，並不會對程序性能造成負面影響，並且在批量寫入、帶分頁要求的數據查詢方面會有很大的性能提升。

4 附錄：

測試環境

服務端為單機部署，機器配置如下：

Jdbc：單庫test，單表user。
Sharding-jdbc：分三個庫test_0,test_1,test_2，水平分庫分表，每個庫兩張表user_0,user_1。

測試腳本

建表sql

CREATE TABLE `user` ( `id` int(12) unsigned zerofill NOT NULL AUTO_INCREMENT, `user_name` varchar(50) DEFAULT NULL, `user_id` int(20) NOT NULL, `c_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=28204 DEFAULT CHARSET=utf8;

插入sql

insert into user(user_name,user_id,c_time) values(?,?,?)

查詢sql

select id,user_id,user_name,c_time from user where user_id >= ? and user_id <= ? ORDER BY c_time DESC select id,user_id,user_name,c_time from user where c_time >= ? and c_time <= ? ORDER BY c_time DESC select id,user_id,user_name,c_time from user where user_id >= ? and user_id <= ? ORDER BY c_time DESC limit ?,? select id,user_id,user_name,c_time from user where c_time >= ? and c_time <= ? ORDER BY c_time DESC limit ?,?