[[62599]]

一直以來，人們都認為大數(shù)據(jù)和NoSQL數(shù)據(jù)庫是天作之合，而關(guān)系型數(shù)據(jù)庫則被打上OUT的標簽，但有一位數(shù)據(jù)庫老兵并不這么認為。

在大多數(shù)IT觀察家的眼里，大數(shù)據(jù)通常是指那些規(guī)模大到難以用傳統(tǒng)關(guān)系型數(shù)據(jù)庫處理的數(shù)據(jù)集。雖然今天關(guān)系模型和SQL依然是數(shù)據(jù)庫世界的統(tǒng)治者，但隨著大數(shù)據(jù)時代的到來，越來越多的數(shù)據(jù)庫并非建筑在“關(guān)系”之上，且具有更高的可擴展性。

那么，大數(shù)據(jù)時代關(guān)系型數(shù)據(jù)庫何去何從？最近MySQL開源數(shù)據(jù)庫最初版本的開發(fā)者，以及MySQL社區(qū)開發(fā)分支版本——MariaDB的創(chuàng)始人之一Monty Widenius接受ReadWrite的采訪，他駁斥了大數(shù)據(jù)與SQL數(shù)據(jù)庫水火不容的常見觀點。以下是對Widenius的采訪實錄，摘錄如下：

問：您能NoSQL和大數(shù)據(jù)的歷史嗎？為什么它們會成為人們熱議的話題？

答：所謂的“新NoSQL運動”的起源來自三年前Twitter一位員工的博客，此人在博客中稱MySQL不夠好，他們需要更好的數(shù)據(jù)庫技術(shù)，例如Cassandra。

其實Twitter當時在MySQL上遇到麻煩是因為他們沒有正確使用。奇怪的是，Twitter給出的問題解決方法在Cassandra和MySQL里都能輕松實現(xiàn)。

這篇文章的原文已經(jīng)找不到了，但可以參考這篇隨后的文章“MySQL將被Cassandra替代”。

目前的情況是這樣：

三年過去了，Twitter還在用MySQL存儲它最寶貴的資產(chǎn)——推文。Cassandra最終也沒能取代了MySQL。

NoSQL流行的原因是，與SQL相比，NoSQL非常容易上手，你不需要任何設(shè)計就能開始使用它。但這也是有代價的，很快你就會發(fā)現(xiàn)對數(shù)據(jù)失去了控制（如果你不是足夠小心的話）。

所以，大多數(shù)NoSQL解決方案的優(yōu)點（在MariaDB出現(xiàn)之前）是：

● 快速訪問數(shù)據(jù)（只要你舍得把文件都丟進內(nèi)存）

● 快速復制/多個節(jié)點的數(shù)據(jù)擴展

● 彈性架構(gòu)（可以快速增加新的列）

問：大數(shù)據(jù)（技術(shù)）能幫人們解決什么問題？

更高性能和更靈活的架構(gòu)是推動NoSQL發(fā)展的兩大動力。

問：你個人怎么看待大數(shù)據(jù)，有什么預測嗎？

我覺得大多數(shù)看好NoSQL的用戶都是跟風者。大多數(shù)公司根本沒有像Facebook和Google那么大規(guī)模的數(shù)據(jù)，而且他們其實也根本就支付不起優(yōu)化和持續(xù)開發(fā)數(shù)據(jù)庫所需的專家人力成本。

SQL不會消亡。NoSQL無法取代它。因為幾乎所有人都需要關(guān)系型數(shù)據(jù)庫來管理數(shù)據(jù)。

眼下NoSQL也有其用武之地。我認為未來將更多的是SQL和NoSQL的混合應(yīng)用。

問：為什么人們還在使用NoSQL？主要有哪些原因？

因為NoSQL上手很容易。你甚至不需要學習SQL，使用前也不需要定義數(shù)據(jù)庫架構(gòu)。當然也有一些人使用NoSQL是因為比SQL的擴展性更好。

問：SQL在性能上能超過NoSQL嗎？SQL哪些方面由于NoSQL？

只要數(shù)據(jù)不能載入內(nèi)存，SQL通常性能都超過NoSQL。

同樣的，NoSQL相比SQL還存在很多不足之處，例如大多數(shù)NoSQL方案都是為單一鍵值訪問（single key access）優(yōu)化的。對于更復雜的事情來說，你必須編寫專門的程序，而且性能與SQL無法相比，尤其是那些需要自動響應(yīng)用戶請求的服務(wù)（大多數(shù)網(wǎng)站提供的服務(wù)）

在單機上的性能表現(xiàn)，NoSQL通常都不是SQL的對手。在集群環(huán)境中，當所有數(shù)據(jù)都載入內(nèi)存，NoSQL在鍵值查找的速度上通常會比SQL快。

原文鏈接：http://readwrite.com/2013/01/21/dont-write-off-relational-databases-for-big-data-just-yet