經(jīng)常聽人說滩愁，數(shù)據(jù)庫的IO性能不佳躯喇，但說歸說，并沒有感性認(rèn)識硝枉。我們現(xiàn)在就來實際測試一下廉丽，常用的Oracle和MySQL的JDBC讀取性能如何。
之所以測試JDBC妻味，是因為大部分應(yīng)用是JAVA寫的正压，也就只能用JDBC來訪問數(shù)據(jù)。這里僅測試用JDBC讀出數(shù)據(jù)责球，并產(chǎn)生成Java的記錄對象（畢竟到了這一步才能在應(yīng)用中使用）焦履，不作任何計算拓劝。
1.??????? 數(shù)據(jù)來源
使用TPCH生成的數(shù)據(jù)，選用其中的customer表來做測試嘉裤，數(shù)據(jù)記錄為3000萬行郑临，8個字段。它生成的原始文本文件名為customer.tbl屑宠，文件大小為4.9G厢洞。利用數(shù)據(jù)庫提供的數(shù)據(jù)導(dǎo)入工具將此文件數(shù)據(jù)導(dǎo)入到Oracle和MySQL的數(shù)據(jù)表中。
2.??????? 測試環(huán)境
在一臺Intel服務(wù)器上完成測試典奉，2個Intel2670 CPU躺翻，主頻2.6G，共16核卫玖，內(nèi)存64G公你。數(shù)據(jù)庫表數(shù)據(jù)及文本文件均存儲在同一塊SSD硬盤上。
所有測試均在服務(wù)器本機上完成假瞬，沒有消耗網(wǎng)絡(luò)傳輸時間陕靠。
3.??????? 數(shù)據(jù)庫讀數(shù)測試
通過Oracle提供的JDBC接口，用SQL語句執(zhí)行數(shù)據(jù)讀取笨触。
Java寫起來麻煩懦傍，用SPL腳本執(zhí)行測試：
MySQL的測試代碼類似，不再贅述芦劣。
測試結(jié)果（時間單位：秒）
第二次可能由于操作系統(tǒng)有了硬盤緩存，所以更快说榆。因為我們主要是為了測試JDBC的讀取時間虚吟，所以就以第二次為準(zhǔn)，減少數(shù)據(jù)庫本身從硬盤讀數(shù)的影響签财。每秒讀出行數(shù)也是按第二次時間來計算的串慰，也就是說，Oracle每秒能讀出10萬行多數(shù)據(jù)唱蒸，MySQL大概接近8萬行邦鲫。當(dāng)然這個值和表的字段數(shù)及類型都有關(guān)（customer表有8個字段），只是一種參考神汹。
4.??????? 文本文件對比
只從上面的數(shù)據(jù)量還沒有太多感性認(rèn)識庆捺，我們再讀一下文本文件來對比。辦法是一樣的屁魏，從文件中讀出數(shù)據(jù)滔以，并解析出記錄，不作任何計算氓拼。
編寫如下SPL腳本執(zhí)行測試：
測試結(jié)果是42秒你画！
這意味著抵碟，讀取文本要比讀取Oracle快281/42=6.69倍，比MySQL要快381/42=9.07倍坏匪！
我們知道拟逮，文本解析是個非常麻煩的事情，但即使這樣适滓，從文本文件讀取數(shù)據(jù)還是遠遠快于從數(shù)據(jù)庫中讀數(shù)敦迄。Oracle和MySQL的IO實在是太慢了！
5.??????? 二進制方式
我們進一步再看使用二進制方式的存儲格式的讀取性能粒竖，并和文本比對颅崩。
為了對比明顯，這次換一個更大的表蕊苗，用TPCH中的orders表沿后，有3億行數(shù)據(jù)，9個字段朽砰。
文本讀取的代碼和上面類似尖滚，讀取時間測試為438秒。
然后瞧柔，我們將這個文本文件轉(zhuǎn)換成SPL組表漆弄，再寫代碼測試：
測試結(jié)果是164秒，大概僅僅是文本讀取的三分之一造锅。
這是情理之中的事情撼唾，因為二進制數(shù)據(jù)不再需要解析，可以直接產(chǎn)生對象哥蔚，計算量少了很多倒谷，因而要更快。
需要說明的是糙箍，組表文件雖然采用列存格式渤愁，但在這里讀出了所有列，并沒有比文本少取任何內(nèi)容深夯，沒有占列存的便宜抖格。事實上，因為讀所有列咕晋，使用列存還會吃點虧雹拄，如果采用SPL集文件（一種行存格式）還會更快。
6.??????? 并行提速
從文件中取數(shù)還很容易實現(xiàn)并行捡需，文本和組表都容易寫出并行程序办桨。還是用上面的orders表為例來測試，使用4線程取數(shù)站辉。
文本取數(shù)代碼：
組表取數(shù)代碼：
用SPL很容易實現(xiàn)數(shù)據(jù)分段和并行計算呢撞。
測試結(jié)果為：
文本?????? 119秒
組表?????? 43秒
與串行相比损姜，接近了線性提升，將CPU的多核充分利用起來了殊霞。
?????? 數(shù)據(jù)庫中的數(shù)據(jù)則不容易簡單地實施分段并行摧阅，需要用WHERE條件去拼，結(jié)果很難說清到底是并行不力還是WHERE執(zhí)行損失太多绷蹲，測試結(jié)果的參考意義就打折扣了棒卷，這里就不再做了。
7.??????? 結(jié)論
數(shù)據(jù)庫（Oracle和MySQL）的JDBC性能非常非常差祝钢！比文本文件還要差5倍以上比规。而采用二進制數(shù)據(jù)時，會比文本再提高3倍的讀取性能拦英。也就是說蜒什，合理格式的二進制文件會比數(shù)據(jù)庫有15倍以上的優(yōu)勢。再考慮到并行因素疤估，比數(shù)據(jù)庫快出幾十上百倍也是完全可能的灾常。
在關(guān)注性能且數(shù)據(jù)量較大時，千萬不要把數(shù)據(jù)讀出數(shù)據(jù)庫計算铃拇！
如果實在需要讀出后再計算（有時SQL很難寫出復(fù)雜的過程計算）钞瀑，就不要再用數(shù)據(jù)庫存儲了（大數(shù)據(jù)都是歷史，基本也不再改了慷荔，可以事先讀出）雕什，用文本都比數(shù)據(jù)庫強，用二進制當(dāng)然更好（推薦使用SPL組表显晶，哈哈）监徘。切不要把時間浪費在讀數(shù)這種非計算任務(wù)上了。
