資料分析師都想使用資料庫作為資料倉庫處理并操作資料，那麼哪一款資料庫最合适分析師呢?
雖然網上已經有很多對各種資料庫進行比較的文章，但其着眼點一般都是架構、成本、可伸縮性和性能，很少考慮另一個關鍵因素：分析師在這些資料庫上編寫查詢的難易程度。最近，mode的首席分析師benn stancil釋出了一篇文章，從另一個角度闡釋了哪一款資料庫最适合資料分析師。
benn stancil認為資料分析工作不可能一蹴而就，分析師在使用資料庫的過程中阻礙他們速度的往往不是宏觀上的性能，而是編寫查詢語句時的細節。例如，在redshift中如何擷取目前時間，是now()、curdate()、curdate、sysdate 還是whatdayisit。
在mode公司，分析師每天都會使用各種不同的語言編寫幾千個查詢，運作在mode編輯器裡的查詢超過百萬個，而benn stancil就是從這些資料出發，對mysql、postgresql、redshift、sql server、bigquery、vertica、hive和impala這八款資料庫進行了比較。
1.查詢錯誤是否容易解決
首先，benn stancil認為查詢錯誤是否容易解決是衡量資料庫的一個最基本名額。資料庫提供的錯誤資訊(通常是文法錯誤、函數名錯誤、逗号錯位等)最能表明該系統是否會對資料分析師造成極大的挫敗感。通過對8種資料庫查詢錯誤頻率的比較，benn stancil發現vertica和sql server錯誤率最高，mysql和impala最低，如圖所示：
但是，對于該結果benn stancil認為可能有點不嚴謹，因為impala、mysql和hive是開源的免費産品，而vertica、sql server和bigquery不是，後三者的使用者通常是有充足分析預算的大型企業，其較高的錯誤率很有可能是由于使用更深入而不是語言“更難用”。
2.複雜性
除了錯誤率之外，benn stancil還讨論了複雜性。雖然不同語言其查詢長度、查詢複雜性和語言複雜性之間的關系盤根錯節，要界定清楚很難，但可以間接使用查詢長度作為度量的名額，因為一門語言之是以簡單很有可能是因為它簡潔。這八種資料庫查詢長度的統計結果如下：
如果說單純地比較最終的長度有失偏頗，那麼可以看看随着分析的逐漸深入，查詢逐漸變複雜的過程中，其修改次數與長度之間的關系：
該圖顯示，經過20次左右的編輯之後，查詢長度通常會變為之前的2倍，而在100次編輯之後，長度會變為之前的3倍。那麼在修改的過程中，其編輯次數與出錯的比率又是什麼樣子的呢?
從圖中可以看出，postgresql、mysql和redshift的錯誤率較低，impala、bigquery和sql server的錯誤率較高。另外，和之前一樣，vertica的錯誤率依然最高。
3.分析師技能
此外，benn stancil認為分析師的技能也很重要。他對使用多個資料庫并且在每個資料庫上至少運作了10個查詢的分析師進行了統計，計算了這些分析師在每個資料庫上的查詢錯誤率，并根據統計結果建構了下面的矩陣：
該矩陣展示的是頂部資料庫與左邊資料庫相比其錯誤率的差别，數值越高表現就越差。例如，hive和bigquery交叉處的“20.2”表示：對使用這兩款資料庫的分析師，其使用hive的錯誤率要比使用bigquery高20.2。最底部的total行是結果總計，從中可以看出mysql和postgresql始終表現較好;vertica跳躍最大，幾乎是從最底部跳到了中遊，打敗了sql server 和hive，這也暗示了vertica的高錯誤率很可能是由于分析師的能力而不是語言本身。
最後，benn stancil認為在分析的這8個資料庫中，mysql和postgresql編寫sql最簡單，應用也最廣泛，但與vertica和sql server相比它們的特性不夠豐富，而且速度要慢。綜合各方面的因素，redshift或許才是最好的選擇。
本文轉自d1net（轉載）