譯者 | 晶顏
審校 | 重樓
考慮到SQL的流行和成功，本文更像是一個悖論研究。SQL可能笨拙而冗長，但開發人員經常發現它是提取所需數據的最簡單、最直接的方法。當查詢寫入正確時，它可以像閃電一樣快，而當查詢出錯時，它又會慢得驚人。它已經存在了幾十年，但新功能一直在不斷增加。
這些矛盾并不重要，因為市場已經表明：SQL是許多人的首選，即使有更新的、更強大的選項。從最小的網站到最大的大型公司，各地的開發人員都知道SQL。他們依靠它來組織所有的數據。
SQL的表格模型如此流行，以至于許多非SQL項目最終都添加了SQLish接口，因為用戶需要它。甚至是“NoSQL”運動——其發明是為了擺脫舊的范式——最終似乎也敗給了SQL。
SQL的局限性可能不足以將其徹底拋棄。開發人員也可能永遠不會著手將所有數據從SQL中遷移出去。但是SQL的問題是真實存在的，足以給開發人員帶來壓力，增加延遲，甚至需要對某些項目進行重新設計。
下面是我們希望放棄SQL的9個原因，盡管我們知道這可能做不到。
表格不能擴展
關系模型鐘情于表格，所以我們一直在構建它。這對于小型甚至正常大小的數據庫來說還好，但面對真正的大規模數據庫，這個模型就會崩潰。
有些人試圖通過將新舊結合起來來解決問題，比如將分片集成到舊的開源數據庫中。添加層似乎可以使數據更易于管理，并提供無限的規模。但這些增加的層可能隱藏危險。根據分片中存儲的數據量，SELECT或JOIN的處理時間可能會有很大的不同。
分片還迫使數據庫管理員（DBA）考慮數據可能存儲在不同的機器上，甚至可能存儲在不同的地理位置上的可能性。沒有經驗的管理員在開始跨表搜索時，如果沒有意識到數據存儲在不同的位置，可能會感到困惑。該模型有時會將位置從視圖中抽象出來。
一些AWS機器配備了24TB的RAM，因為一些數據庫用戶需要這么多。他們在SQL數據庫中有這么多數據，而且這樣能夠運行得更好。
SQL不是JSON或XML原生的
SQL可能是一種“常青樹式”的語言，但它并不特別適合JSON、YAML和XML等較新的數據交換格式。所有這些都支持比SQL更分層、更靈活的格式。SQL數據庫的核心仍然停留在關系模型中，充斥著各種表格。
市場會想方設法掩蓋這種常見的抱怨。使用正確的粘合代碼添加不同的數據格式（如JSON）相對容易，但您將付出損失時間的代價。
一些SQL數據庫現在能夠編碼和解碼更現代的數據格式（如JSON、XML、GraphQL或YAML）作為原生特性。但是在內部，數據通常使用相同的舊表格模型進行存儲和索引。
在這些格式之間轉換數據要花費多少時間？用一種更現代的方式存儲數據不是更容易嗎？一些聰明的數據庫開發人員仍在繼續進行實驗，但奇怪的是，他們經常會使用某種SQL解析器。
封送（Marshaling）是一項耗費大量時間的工作
數據庫可以在表中存儲數據，但是需要程序員編寫處理對象的代碼。設計數據驅動的應用程序的大部分工作，似乎都是找出從數據庫中提取的數據并將其轉換為業務邏輯可以處理的對象的最佳方法。然后，必須通過將對象中的數據字段轉換為SQL upsert來解組數據。難道沒有一種方法可以讓數據保持一種隨時可用的格式嗎？
SQL并非實時的
最初的SQL數據庫是為批處理分析和交互模式而設計的。具有長處理管道的流數據模型是一個相對較新的想法，而且它并不完全匹配。
主要的SQL數據庫是在幾十年前設計的，當時的模型設想數據庫可以獨立運行，像某種Oracle一樣回答查詢。有時它們反應迅速，有時則不然。這就是批處理的工作方式。
一些最新的應用程序要求更好的實時性能——不僅僅是為了方便，而且因為應用程序需要它。在現代的流媒體世界里，缺乏實時功能是行不通的。
為這些市場設計的最新數據庫非常重視速度和響應能力。它們不提供那種復雜的SQL查詢，以免造成延遲。
JOIN是一個令人頭疼的問題
關系數據庫的強大之處在于將數據分解成更小、更簡潔的表。不過，問題也隨之而來。
使用JOIN動態地重新組裝數據通常是作業中計算成本最高的部分，因為數據庫必須處理所有數據。當數據開始超出RAM時，問題就開始了。
對于學習SQL的人來說，JOIN可能會讓人十分困惑。弄清楚內部JOIN和外部JOIN之間的區別僅僅是個開始。尋找將多個JOIN連接在一起的最佳方式更為困難。內部優化器可能會幫上忙，但是當數據庫管理員要求一個特別復雜的組合時，它們就無能為力了。
列（Column）是對空間的浪費
“NoSQL”運動的一個偉大思想就是讓用戶從列中解脫出來。如果有人想向條目添加新值，他們可以選擇他們想要的任何標記或名稱。不需要更新模式來添加新列。
SQL捍衛者在該模型中只看到了混亂。他們喜歡表自帶的順序，不希望開發人員匆忙添加新字段。他們有一定的道理，但是添加新列可能非常昂貴和耗時，特別是在大型表中。將新數據放在單獨的列中并使用JOIN對它們進行匹配會增加更多的時間成本和復雜性。
優化器并非始終有用
數據庫公司和研究人員已經花費了大量時間開發優秀的優化器，這些優化器可以分解查詢并找到排序其操作的最佳方式。
收益可能是顯著的，但是優化器所能做的是有限的。如果查詢需要一個特別大的或細致的響應，那么優化器不能只是說，“你真的確定嗎？”它必須把答案集合起來，然后按照指令去做。
有些數據庫管理員只有在應用程序開始擴展時才意識到這一點。早期的優化足以在開發期間處理測試數據集。但是在關鍵時刻，優化器無法發揮更多的功能。
反范式化（Denormalization）將表視為垃圾
面對想要更快性能的用戶和不想為更大、更昂貴的硬件付費的用戶，開發人員經常處于兩難境地。一種常見的解決方案是對表進行反范式化處理，這樣就不需要復雜的JOIN或跨表操作。
這并非一個糟糕的技術解決方案，而且它經常獲勝，因為磁盤空間已經變得比處理能力便宜。但是反范式化也拋棄了SQL和關系數據庫理論中最精華的部分。當數據庫變成一個長CSV文件時，所有這些花哨的數據庫功能幾乎都消失了。
附加特性會破壞數據庫
多年來，開發人員一直在為SQL添加新特性，其中一些非常優秀。但另一方面，有些新特性可能會導致性能問題。一些開發人員警告稱，“您應該特別小心子查詢（Subqueries），因為它們會減慢所有操作的速度”。另一些人則表示，“選擇像公共表表達式、視圖或windows這樣的子集會使代碼過于復雜”。
例如，窗口函數（Window function）的設計是為了通過加速計算結果（如平均值）來加快基本數據分析的速度。但是許多SQL用戶會發現并使用一些附加的特性。在大多數情況下，他們會嘗試新功能，只有當他們的機器慢得像爬行一樣時才會注意到這些問題。然后他們會需要一些經驗豐富的數據庫管理員來解釋發生了什么以及如何修復它。
原文標題：9 reasons SQL has got to go，作者：Peter Wayner
