數(shù)據(jù)分析師都想使用數(shù)據(jù)庫作為數(shù)據(jù)倉庫處理并操作數(shù)據(jù)，那么哪一款數(shù)據(jù)庫最合適分析師呢?
雖然網(wǎng)上已經(jīng)有很多對各種數(shù)據(jù)庫進(jìn)行比較的文章，但其著眼點(diǎn)一般都是架構(gòu)、成本、可伸縮性和性能，很少考慮另一個(gè)關(guān)鍵因素：分析師在這些數(shù)據(jù)庫上編寫查詢的難易程度。最近，Mode的首席分析師Benn Stancil發(fā)布了一篇文章，從另一個(gè)角度闡釋了哪一款數(shù)據(jù)庫最適合數(shù)據(jù)分析師。
Benn Stancil認(rèn)為數(shù)據(jù)分析工作不可能一蹴而就，分析師在使用數(shù)據(jù)庫的過程中阻礙他們速度的往往不是宏觀上的性能，而是編寫查詢語句時(shí)的細(xì)節(jié)。例如，在Redshift中如何獲取當(dāng)前時(shí)間，是NOW()、CURDATE()、CURDATE、SYSDATE 還是WHATDAYISIT。
在Mode公司，分析師每天都會使用各種不同的語言編寫幾千個(gè)查詢，運(yùn)行在Mode編輯器里的查詢超過百萬個(gè)，而Benn Stancil就是從這些數(shù)據(jù)出發(fā)，對MySQL、PostgreSQL、Redshift、SQL Server、BigQuery、Vertica、Hive和Impala這八款數(shù)據(jù)庫進(jìn)行了比較。
1.查詢錯(cuò)誤是否容易解決
首先，Benn Stancil認(rèn)為查詢錯(cuò)誤是否容易解決是衡量數(shù)據(jù)庫的一個(gè)最基本指標(biāo)。數(shù)據(jù)庫提供的錯(cuò)誤信息(通常是語法錯(cuò)誤、函數(shù)名錯(cuò)誤、逗號錯(cuò)位等)最能表明該系統(tǒng)是否會對數(shù)據(jù)分析師造成極大的挫敗感。通過對8種數(shù)據(jù)庫查詢錯(cuò)誤頻率的比較，Benn Stancil發(fā)現(xiàn)Vertica和SQL Server錯(cuò)誤率最高，MySQL和Impala最低，如圖所示：
但是，對于該結(jié)果Benn Stancil認(rèn)為可能有點(diǎn)不嚴(yán)謹(jǐn)，因?yàn)镮mpala、MySQL和Hive是開源的免費(fèi)產(chǎn)品，而Vertica、SQL Server和BigQuery不是，后三者的用戶通常是有充足分析預(yù)算的大型企業(yè)，其較高的錯(cuò)誤率很有可能是由于使用更深入而不是語言“更難用”。
2.復(fù)雜性
除了錯(cuò)誤率之外，Benn Stancil還討論了復(fù)雜性。雖然不同語言其查詢長度、查詢復(fù)雜性和語言復(fù)雜性之間的關(guān)系盤根錯(cuò)節(jié)，要界定清楚很難，但可以間接使用查詢長度作為度量的指標(biāo)，因?yàn)橐婚T語言之所以簡單很有可能是因?yàn)樗啙崱＿@八種數(shù)據(jù)庫查詢長度的統(tǒng)計(jì)結(jié)果如下：
如果說單純地比較最終的長度有失偏頗，那么可以看看隨著分析的逐步深入，查詢逐漸變復(fù)雜的過程中，其修改次數(shù)與長度之間的關(guān)系：
該圖顯示，經(jīng)過20次左右的編輯之后，查詢長度通常會變?yōu)橹暗?倍，而在100次編輯之后，長度會變?yōu)橹暗?倍。那么在修改的過程中，其編輯次數(shù)與出錯(cuò)的比率又是什么樣子的呢?
從圖中可以看出，PostgreSQL、MySQL和Redshift的錯(cuò)誤率較低，Impala、BigQuery和SQL Server的錯(cuò)誤率較高。另外，和之前一樣，Vertica的錯(cuò)誤率依然最高。
3.分析師技能
此外，Benn Stancil認(rèn)為分析師的技能也很重要。他對使用多個(gè)數(shù)據(jù)庫并且在每個(gè)數(shù)據(jù)庫上至少運(yùn)行了10個(gè)查詢的分析師進(jìn)行了統(tǒng)計(jì)，計(jì)算了這些分析師在每個(gè)數(shù)據(jù)庫上的查詢錯(cuò)誤率，并根據(jù)統(tǒng)計(jì)結(jié)果構(gòu)建了下面的矩陣：
該矩陣展示的是頂部數(shù)據(jù)庫與左邊數(shù)據(jù)庫相比其錯(cuò)誤率的差別，數(shù)值越高表現(xiàn)就越差。例如，Hive和BigQuery交叉處的“20.2”表示：對使用這兩款數(shù)據(jù)庫的分析師，其使用Hive的錯(cuò)誤率要比使用BigQuery高20.2。最底部的Total行是結(jié)果總計(jì)，從中可以看出MySQL和PostgreSQL始終表現(xiàn)較好;Vertica跳躍最大，幾乎是從最底部跳到了中游，打敗了SQL Server 和Hive，這也暗示了Vertica的高錯(cuò)誤率很可能是由于分析師的能力而不是語言本身。
最后，Benn Stancil認(rèn)為在分析的這8個(gè)數(shù)據(jù)庫中，MySQL和PostgreSQL編寫SQL最簡單，應(yīng)用也最廣泛，但與Vertica和SQL Server相比它們的特性不夠豐富，而且速度要慢。綜合各方面的因素，Redshift或許才是最好的選擇。
京公網(wǎng)安備 11010502049343號