No-SQL正淘汰SQL?

上周，朋友給我轉(zhuǎn)發(fā)了某成功企業(yè)家的郵件，里面宣稱“SQL已經(jīng)過時了”。

該企業(yè)家聲稱，MongoDB和Redis 這樣受歡迎的 No-SQL 數(shù)據(jù)庫，會慢慢地將基于SQL的數(shù)據(jù)庫淘汰。因此，身為數(shù)據(jù)科學(xué)家，學(xué)習(xí)SQL是“抱殘守缺”

看到他的郵件我非常震驚，他是怎么得出這么離譜的結(jié)論的?但這也令我好奇......別人會不會也這樣誤解了呢?該企業(yè)家有大量擁躉，他本人也直言不諱：新的數(shù)據(jù)科學(xué)家收到建議別再學(xué)習(xí)SQL了嗎?

可能其他人也認(rèn)為SQL正在被淘汰，在此，我想公開向該企業(yè)家作出回應(yīng)。

在從事數(shù)據(jù)科學(xué)的職業(yè)生涯里，學(xué)習(xí)SQL非常有必要。No-SQL無法撼動學(xué)習(xí)SQL的意義。

基本上，有兩個理由可以保證SQL在未來幾十年都不會過時。

理由1：No-SQL數(shù)據(jù)庫不會取代Presto、Redshift、BigQuery等分析數(shù)據(jù)庫

不論應(yīng)用程序使用的是MySQL這樣的SQL后端，還是像MongoDB那樣的No-SQL后端，該后端中的數(shù)據(jù)最終都會被加載到專門的分析數(shù)據(jù)庫中，比如Redshift、Snowflake、BigQuery或 Presto。

公司為什么把數(shù)據(jù)轉(zhuǎn)移到Redshift這樣的專欄存儲中?因?yàn)閷诖鎯δ芨斓剡\(yùn)行分析查詢，不論是NoSQL還是像MySQL這樣的行存儲數(shù)據(jù)庫。事實(shí)上，我敢打賭，專欄存儲數(shù)據(jù)庫的普及速度與NoSQL數(shù)據(jù)庫一樣快。

因此，像NoSQL以及其他數(shù)據(jù)庫還有匹配的應(yīng)用程序，它們的技術(shù)通常與數(shù)據(jù)科學(xué)家無關(guān)，因?yàn)樗麄儾皇褂脭?shù)據(jù)庫應(yīng)用程序。當(dāng)然也有一些例外，將在后文討論。

理由2：NOSQL數(shù)據(jù)庫的優(yōu)勢并非不支持SQL語言

事實(shí)證明，如果支持基于SQL的查詢引擎是有意義的，那么No-SQL存儲可以實(shí)現(xiàn)它。類似地，SQL數(shù)據(jù)庫也可以支持NoSQL查詢語言，但是它們選擇不支持。

那么，為什么專欄存儲數(shù)據(jù)庫有意選擇提供SQL接口呢?

他們做出這樣的選擇，是因?yàn)镾QL語言在表達(dá)數(shù)據(jù)操作指令上非常強(qiáng)大。

以一個簡單的查詢?yōu)槔荖oSQL數(shù)據(jù)庫下MongoDB的計算集合中的文檔數(shù)量。

注意：MongoDB中的文檔類似于行，而集合則類似于表。

db.sales.aggregate( [  
{  
$group: {  
_id: null,  
count: { $sum: 1 }  
}  
}  
] ) 

將其與等效SQL進(jìn)行比較。

select count(1) from sales 

顯而易見，對于想要提取數(shù)據(jù)的人來說，SQL語言是更好的選擇。NoSQL數(shù)據(jù)庫支持不同的語言，因?yàn)樵跀?shù)據(jù)庫接口的應(yīng)用程序庫方面，正確構(gòu)造SQL比較困難。

前文提到過，應(yīng)用程序數(shù)據(jù)庫的技術(shù)與數(shù)據(jù)科學(xué)家無關(guān)，但是這一規(guī)則有一些例外。我的第一家公司實(shí)際上沒有像Redshift那樣的分析數(shù)據(jù)庫，所以必須直接查詢應(yīng)用程序的數(shù)據(jù)庫。更準(zhǔn)確地說，是在查詢應(yīng)用程序數(shù)據(jù)庫的讀副本。

該公司的應(yīng)用程序還使用了No-SQL數(shù)據(jù)庫Redis，而且不止一次我需要直接從Redis提取數(shù)據(jù)，所以確實(shí)需要學(xué)習(xí)Redis的NoSQL API的一些組件。

因此，在主要應(yīng)用程序?qū)ｉT使用NoSQL數(shù)據(jù)庫的環(huán)境中，學(xué)習(xí)哪種SQL可能都無關(guān)緊要。但在非常罕見情況下，隨著公司的成長，他們幾乎肯定會投資建立一個支持SQL的分欄存儲分析數(shù)據(jù)庫。