作者丨Peter Wayner

編譯丨Noe

出品 | 51CTO技術(shù)棧（微信號：blog51cto）

盡管SQL很受歡迎，也很成功，但它又總是充斥著種種矛盾。

SQL可能笨拙又冗長，但開發(fā)人員又經(jīng)常發(fā)現(xiàn)它往往是他們提取所需數(shù)據(jù)的最簡單直接的方法。當(dāng)查詢寫入正確時(shí)，它可以快如閃電，當(dāng)查詢出錯(cuò)時(shí)，它就會慢如蝸牛。SQL明明已經(jīng)經(jīng)歷了幾十年發(fā)展，但新功能仍然在不斷增加。

不過這些悖論并不重要，因?yàn)槭袌鲆呀?jīng)表明：時(shí)至今日，即使出現(xiàn)了不少更新的、更強(qiáng)大的選擇，SQL還是許多人的首選。無論是小網(wǎng)站還是大公司，各地的開發(fā)人員都知道SQL。

SQL的表格模型占據(jù)主導(dǎo)地位，以至于許多非SQL項(xiàng)目最終都添加了SQL的接口，因?yàn)橛脩粜枰?。這甚至適用于NoSQL運(yùn)動，盡管NoSQL的發(fā)明初衷是為了擺脫舊的范式。但最終，似乎還是SQL贏了。

大家都知道，SQL有一定的局限性，但這并不足以讓人們徹底放棄它。開發(fā)人員可能永遠(yuǎn)不會起身將所有數(shù)據(jù)從SQL中遷移出去。但是SQL的問題是真實(shí)的，足以給開發(fā)人員帶來壓力，有時(shí)候甚至需要對某些項(xiàng)目進(jìn)行重新設(shè)計(jì)。

下面是我們希望放棄SQL的9個(gè)原因，盡管我們心知肚明我們可能做不到。

SQL讓事情變得更糟的9種方式： 

• 表格無法縮放
• SQL不是JSON或XML原生的
• 列集是一項(xiàng)耗費(fèi)大量時(shí)間的工作
• SQL不是實(shí)時(shí)的
• JOINS是一個(gè)令人頭疼的問題
• 列是對空間的浪費(fèi)
• 優(yōu)化器只是有時(shí)有用
• 非規(guī)范化將表視為垃圾
• 附帶的想法會破壞你的數(shù)據(jù)庫

1、表格無法縮放

關(guān)系模型喜歡表格，所以我們不斷構(gòu)建它們。這對于小型乃至普通大小的數(shù)據(jù)庫來說都沒問題。但這個(gè)模型要是用在真正的大型數(shù)據(jù)庫上就會開始崩潰。

有些人試圖通過將新舊數(shù)據(jù)庫結(jié)合來解決這個(gè)問題，比如將分片集成到舊的開源數(shù)據(jù)庫中。添加層似乎可以使數(shù)據(jù)更易于管理，并提供無限的規(guī)模。但這些增加的層可能隱藏地雷。根據(jù)分片中存儲的數(shù)據(jù)量，SELECT或JOIN的處理時(shí)間可能會截然不同。

分片還迫使DBA考慮數(shù)據(jù)可能存儲在不同的機(jī)器上，甚至可能存儲在不同的地理位置上的可能性。缺乏經(jīng)驗(yàn)的管理員在開始跨表搜索時(shí)，如果沒有意識到數(shù)據(jù)存儲在不同的位置，可能會感到困惑。模型有時(shí)會從視圖中抽象出位置。

一些AWS機(jī)器配備了24tb的RAM。為什么?因?yàn)橐恍?shù)據(jù)庫用戶需要這么多。他們在SQL數(shù)據(jù)庫中有這么多數(shù)據(jù)，并且在一臺機(jī)器上，在一塊RAM中運(yùn)行得更好。

2、SQL不是JSON或xml原生的

SQL在語言界可能是一種常青樹，但它并不特別適合JSON、YAML和XML等較新的數(shù)據(jù)交換格式。所有這些都支持比SQL更分層、更靈活的格式。SQL數(shù)據(jù)庫的核心仍然停留在關(guān)系模型中，表無處不在。

市場會想方設(shè)法掩飾這種常見的抱怨。使用正確的粘合代碼添加不同的數(shù)據(jù)格式(如JSON)相對容易，但時(shí)間的損失不可避免，你要為此做好準(zhǔn)備。

一些SQL數(shù)據(jù)庫現(xiàn)在能夠編碼和解碼更現(xiàn)代的數(shù)據(jù)格式，如JSON、XML、GraphQL或YAML作為本地特性。但是在內(nèi)部，數(shù)據(jù)通常使用相同的舊表格模型進(jìn)行存儲和索引。

在這些格式之間轉(zhuǎn)換數(shù)據(jù)要花費(fèi)多少時(shí)間?用一種更現(xiàn)代的方式存儲數(shù)據(jù)不是更容易嗎?一些聰明的數(shù)據(jù)庫開發(fā)人員繼續(xù)進(jìn)行實(shí)驗(yàn)，但奇怪的是，他們常常最終選擇使用某種 SQL 解析器。

3、編組是一項(xiàng)耗費(fèi)大量時(shí)間的工作

數(shù)據(jù)庫可以在表中存儲數(shù)據(jù)，而程序員編寫處理對象的代碼。設(shè)計(jì)數(shù)據(jù)驅(qū)動的應(yīng)用程序的大部分工作似乎都是找出從數(shù)據(jù)庫中提取數(shù)據(jù)并將其轉(zhuǎn)換為業(yè)務(wù)邏輯可以處理的對象的最佳方法。然后，必須通過將對象中的數(shù)據(jù)字段轉(zhuǎn)換為SQL upsert（即“update+insert”,“存在則更新，不存在則插入”）來解組數(shù)據(jù)。難道沒有一種方法可以讓數(shù)據(jù)保持隨時(shí)可用的格式嗎?

4、SQL不是實(shí)時(shí)的

最初的SQL數(shù)據(jù)庫是為批處理分析和交互模式而設(shè)計(jì)的。具有長處理管道的流數(shù)據(jù)模型是一個(gè)相對較新的想法，它并不完全匹配。

主要的SQL數(shù)據(jù)庫是在幾十年前設(shè)計(jì)的，當(dāng)時(shí)的模型設(shè)想數(shù)據(jù)庫可以獨(dú)立運(yùn)行，而且可以像某種先知一樣回答查詢。有時(shí)他們反應(yīng)迅速，有時(shí)則不然。這就是批處理的工作方式。

一些最新的應(yīng)用程序要求更好的實(shí)時(shí)性能——不僅僅是為了方便，而且因?yàn)閼?yīng)用程序需要它。在現(xiàn)代的流媒體世界里，像靜坐山間的大師那樣巋然不動是行不通的。   

專為這些市場設(shè)計(jì)的最新數(shù)據(jù)庫非常重視速度和響應(yīng)能力。它們不提供那種復(fù)雜的SQL查詢，因?yàn)檫@種查詢會讓一切都遲滯下來。

5、連接是一個(gè)令人頭疼的問題

關(guān)系數(shù)據(jù)庫的強(qiáng)大之處在于將數(shù)據(jù)分解成更小、更簡潔的表。煩惱也如影隨形。

使用join動態(tài)地重新組裝數(shù)據(jù)通常是作業(yè)中計(jì)算成本最高的部分，因?yàn)閿?shù)據(jù)庫必須處理所有數(shù)據(jù)。當(dāng)數(shù)據(jù)開始超出RAM的容量時(shí)，令人頭疼的事情就開始了。

對于學(xué)習(xí)SQL的人來說，連接可能會令人難以置信地困惑。弄清楚內(nèi)部join和外部join之間的區(qū)別僅僅是個(gè)開始。尋找將多個(gè)join連接在一起的最佳方式會使情況變得更糟。內(nèi)部優(yōu)化器可能會幫上忙，但是當(dāng)數(shù)據(jù)庫管理員要求一個(gè)特別復(fù)雜的組合時(shí)，它們就無能為力了。

6、列是對空間的浪費(fèi)

NoSQL的一個(gè)偉大思想就是讓用戶從列中解脫出來。如果有人想向條目添加新值，他們可以選擇他們想要的任何標(biāo)記或名稱。不需要更新模式來添加新列。

SQL的擁護(hù)者在該模型中只看到混亂。他們喜歡表格自帶的順序，不希望開發(fā)人員即時(shí)添加新字段。他們有一定的道理，但是添加新列可能非常昂貴和耗時(shí)，特別是在大型表格中。將新數(shù)據(jù)放在單獨(dú)的列中并使用join對它們進(jìn)行匹配，無疑會耗費(fèi)更多的時(shí)間，并增加復(fù)雜性。

7、優(yōu)化器只是有時(shí)有用

數(shù)據(jù)庫公司和研究人員已經(jīng)花費(fèi)了大量時(shí)間來開發(fā)出色的優(yōu)化器，這些優(yōu)化器可以分解查詢并找到排序其操作的最佳方式。

收益可能是顯著的，但是優(yōu)化器所能做的是有限的。如果查詢需要一個(gè)特別大或者特別繁復(fù)的響應(yīng)，那么優(yōu)化器不能只是說，“你真的確定嗎?”它必須匯總答案，然后按照指令去做。

有些DBA只有在應(yīng)用程序開始擴(kuò)展時(shí)才知道這一點(diǎn)。早期的優(yōu)化足以處理開發(fā)過程中的測試數(shù)據(jù)集。但在關(guān)鍵時(shí)刻，優(yōu)化器無法從查詢中榨取更多的能量。

8、非規(guī)范化將表視為垃圾

開發(fā)人員經(jīng)常發(fā)現(xiàn)自己陷入了兩難境地：一方面，想要更快的性能，另一方面精打細(xì)算，不想為更大、更昂貴的硬件付費(fèi)。一種常見的解決方案是對表進(jìn)行非規(guī)范化，這樣就不需要復(fù)雜的連接或跨表操作。所有的數(shù)據(jù)都在一個(gè)長矩形中。

這不是一個(gè)糟糕的技術(shù)解決方案，而且它通常會有實(shí)效，因?yàn)榇疟P空間已經(jīng)變得比處理能力便宜。但是非規(guī)范化也拋棄了SQL和關(guān)系數(shù)據(jù)庫理論中最聰明的部分。當(dāng)數(shù)據(jù)庫變成一個(gè)長CSV文件時(shí)，所有這些花哨的數(shù)據(jù)庫功能幾乎都消失了。

9、附加功能會破壞你的數(shù)據(jù)庫 

多年來，開發(fā)人員一直在為SQL添加新特性，其中一些功能非?？帷５坏貌惶岬氖?，這些花哨的功能通常是附加的，可能會導(dǎo)致性能問題。

一些開發(fā)人員警告說，你應(yīng)該特別小心子查詢，因?yàn)樗鼈儠p慢所有操作的速度。另一些人則表示，選擇像公共表表達(dá)式、視圖或窗口這樣的子集會使代碼過于復(fù)雜。代碼的創(chuàng)建者可以閱讀它，但是其他人在試圖保持SQL的所有層和代的清晰性時(shí)都感到頭痛。這就像在看諾蘭的電影，只不過是用代碼寫的。

有些附加功能已經(jīng)妨礙了之前行之有效的做法。窗口函數(shù)的設(shè)計(jì)是為了通過加速計(jì)算結(jié)果(如平均值)來加快基本數(shù)據(jù)分析的速度。但是許多SQL用戶會發(fā)現(xiàn)并使用一些附加的特性。在大多數(shù)情況下，他們會嘗試新功能，然后當(dāng)他們的機(jī)器慢如蝸牛時(shí)才會注意到有些問題。之后，他們會需要一些有經(jīng)驗(yàn)的DBA來解釋發(fā)生了什么以及如何修復(fù)它。

參考鏈接：

https://www.infoworld.com/article/3711272/9-reasons-sql-has-got-to-go.html