當前的大數據平臺在處理結構化數據時大都仍然以提供SQL語法為主流。兼容SQL的好處是很明顯的，SQL的應用非常廣泛，會SQL的程序員很多，如果繼續采用SQL則可以避免許多學習成本。支持SQL的前端軟件也很多，使用SQL的大數據平臺很容易融入這個現成的生態圈中。大數據平臺打算替代的傳統數據庫也是SQL語法的，這樣兼容性會很好，移植成本相對較低。

一

但繼續使用SQL也有缺點，***的問題就是難以獲得大數據計算最需要的高性能。

我們在前面的文章中提到過，SQL中缺乏一些必要的數據類型和運算定義，這使得某些高性能算法無法描述，只能寄希望于計算引擎在工程上的優化。傳統商業數據庫經過幾十年的發展，優化經驗已經相當豐富，但即使這樣仍有許多場景難以被優化，理論層面的問題確實很難在工程層面解決。而新興的大數據平臺在優化方面的經驗還遠遠不如傳統數據庫，算法上不占優，就只能靠集群更多的機器獲得性能提升。另外，SQL還是一種描述性語言，不擅長指定執行路徑，而想獲得高性能常常需要專門優化的執行路徑，這又需要增加許多特殊的修飾符來人為干預，那還不如直接用過程性語法更為直接，這也會妨礙用SQL寫出高性能的代碼。

SQL發明之初的計算機硬件能力還比較差，要保證實用性，SQL的設計必須適應當時的硬件條件，這就導致了SQL很難充分利用當代計算機的硬件能力，具體來說就是大內存、多線程和集群。SQL中的JOIN是按鍵值對應的，而大內存情況下其實可以直接用地址對應，不需要計算HASH值和比對，性能可以提高很多;SQL的數據表無序，單表計算時還容易做到分段并行，多表關聯運算時一般就只能事先做好固定分段，很難做到同步動態分段，這就無法根據機器的負載臨時決定并行的線程數量;對于集群運算也是這樣，SQL在理論上不區分維表和事實表，JOIN運算簡單地定義為笛卡爾積后過濾，要實現大表JOIN就會不可避免地產生占用大量網絡資源的HASH Shuffle動作，在集群節點數太多時，網絡傳輸造成的延遲會超過節點多帶來的好處。

如果我們設計新的代數體系和運算模型，就可能克服SQL的這些缺點，一方面更好地描述高性能算法，另一方面能充分利用當前的硬件資源，從而獲得更高的性能。

不過，這樣一來，對外的接口也就不再是SQL語法了，不能再兼容以往的代碼了。

順便提一句，新的運算模型并不是指當前業內的NoSQL，NoSQL并不是為高性能計算設計的，事實上它以犧牲計算能力為代價而換取了可橫向擴展的能力，對于復雜大數據計算的需求而言是個倒退。

二

有沒可能讓高性能和兼容性共存呢?比如采用新的內核模型，然后基于它去解釋SQL語法，或者能將SQL代碼自動移植到新體系下。

理論上是可能的，解釋或移植SQL是有不少工作量，但并不是非常困難。不過，這樣做只能獲得語法的兼容性，并不能得到高性能。高效的代碼要針對運算模型的特征去編寫，而SQL語法中并沒有體現這些信息，一定要把SQL移植過來，仍然會面臨前述的工程層面優化問題，沒辦法做得***效果。事實上，兩種均采用SQL的數據庫，要讓其特有的語法能夠互相解釋和移植，在不影響性能的前提下都是很難做到的。新興的大數據廠商都愿意提供這種可移植的技術以降低老數據庫的移植成本，但并沒有多少成功者。

三

那么，結論是什么呢?

對于中短期目標的產品，那么繼續采用SQL是合理的，這將有利于產品的快速應用，性能主要依靠硬件能力或更大規模的集群來提升。而面向長期目標的產品，那就有必要采用取代關系代數體系的運算型，為獲得高性能，不能也不必再提供兼容SQL的方案了，需要忍受漫長的健全生態圈過程。