數據分析師都想使用數據庫作為數據倉庫處理并操作數據，那么哪一款數據庫最合適分析師呢？雖然網上已經有很多對各種數據庫進行比較的文章，但其著眼點一般都是架構、成本、可伸縮性和性能，很少考慮另一個關鍵因素：分析師在這些數據庫上編寫查詢的難易程度。最近，Mode的首席分析師Benn Stancil發布了一篇文章，從另一個角度闡釋了哪一款數據庫最適合數據分析師。

Benn Stancil認為數據分析工作不可能一蹴而就，分析師在使用數據庫的過程中阻礙他們速度的往往不是宏觀上的性能，而是編寫查詢語句時的細節。例如，在Redshift中如何獲取當前時間，是NOW()、CURDATE()、CURDATE、SYSDATE 還是WHATDAYISIT。在Mode公司，分析師每天都會使用各種不同的語言編寫幾千個查詢，運行在Mode編輯器里的查詢超過百萬個，而Benn Stancil就是從這些數據出發，對MySQL、PostgreSQL、Redshift、SQL Server、BigQuery、Vertica、Hive和Impala這八款數據庫進行了比較。

首先，Benn Stancil認為查詢錯誤是否容易解決是衡量數據庫的一個最基本指標。數據庫提供的錯誤信息（通常是語法錯誤、函數名錯誤、逗號錯位等）最能表明該系統是否會對數據分析師造成極大的挫敗感。通過對8種數據庫查詢錯誤頻率的比較，Benn Stancil發現Vertica和SQL Server錯誤率最高，MySQL和Impala最低，如圖所示：

但是，對于該結果Benn Stancil認為可能有點不嚴謹，因為Impala、MySQL和Hive是開源的免費產品，而Vertica、SQL Server和BigQuery不是，后三者的用戶通常是有充足分析預算的大型企業，其較高的錯誤率很有可能是由于使用更深入而不是語言“更難用”。

除了錯誤率之外，Benn Stancil還討論了復雜性。雖然不同語言其查詢長度、查詢復雜性和語言復雜性之間的關系盤根錯節，要界定清楚很難，但可以間接使用查詢長度作為度量的指標，因為一門語言之所以簡單很有可能是因為它簡潔。這八種數據庫查詢長度的統計結果如下：

如果說單純地比較最終的長度有失偏頗，那么可以看看隨著分析的逐步深入，查詢逐漸變復雜的過程中，其修改次數與長度之間的關系：

該圖顯示，經過20次左右的編輯之后，查詢長度通常會變為之前的2倍，而在100次編輯之后，長度會變為之前的3倍。那么在修改的過程中，其編輯次數與出錯的比率又是什么樣子的呢？

從圖中可以看出，PostgreSQL、MySQL和Redshift的錯誤率較低，Impala、BigQuery和SQL Server的錯誤率較高。另外，和之前一樣，Vertica的錯誤率依然最高。

此外，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或許才是最好的選擇。