一、MongoDB等NoSQL數(shù)據(jù)庫不能完全取代關系型數(shù)據(jù)庫的原因

1、不支持ACID事務

NoSQL數(shù)據(jù)庫不直接支持關系模型，也不支持ACID（Atomicity，Consistency，Isolation，Durability） 事務，不適合強數(shù)據(jù)一致性和事務性要求高的場景。

2、查詢能力有限

NoSQL數(shù)據(jù)庫通常是面向列、文檔等的存儲方式，無法像關系型數(shù)據(jù)庫那樣使用復雜的SQL查詢語言進行數(shù)據(jù)查詢和分析，查詢能力有限。

3、專業(yè)人員短缺

NoSQL數(shù)據(jù)庫的應用程序一般需要特殊編程技能和數(shù)據(jù)庫管理經(jīng)驗，相比關系型數(shù)據(jù)庫運維人員的數(shù)量比較稀缺。

4、穩(wěn)定性和可靠性問題

NoSQL數(shù)據(jù)庫相對于成熟的關系型數(shù)據(jù)庫來說有一定的不穩(wěn)定性和可靠性問題。

二、NoSQL數(shù)據(jù)庫介紹

1、簡介

NoSQL，泛指非關系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關系數(shù)據(jù)庫在處理web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，出現(xiàn)了很多難以克服的問題，而非關系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)，特別是大數(shù)據(jù)應用難題。

2、基本含義

NoSQL最常見的解釋是“non-relational”， “Not Only SQL”也被很多人接受。NoSQL僅僅是一個概念，泛指非關系型的數(shù)據(jù)庫，區(qū)別于關系數(shù)據(jù)庫，它們不保證關系數(shù)據(jù)的ACID特性。NoSQL是一項全新的數(shù)據(jù)庫革命性運動，其擁護者們提倡運用非關系型的數(shù)據(jù)存儲，相對于鋪天蓋地的關系型數(shù)據(jù)庫運用，這一概念無疑是一種全新的思維的注入。

NoSQL有如下優(yōu)點：易擴展，NoSQL數(shù)據(jù)庫種類繁多，但是一個共同的特點都是去掉關系數(shù)據(jù)庫的關系型特性。數(shù)據(jù)之間無關系，這樣就非常容易擴展。無形之間也在架構的層面上帶來了可擴展的能力。大數(shù)據(jù)量，高性能，NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)異。這得益于它的無關系性，數(shù)據(jù)庫的結構簡單。

3、分類

鍵值（Key-Value）存儲數(shù)據(jù)庫：這一類數(shù)據(jù)庫主要會使用到一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數(shù)據(jù)。Key-value模型對于IT系統(tǒng)來說的優(yōu)勢在于簡單、易部署。但是如果數(shù)據(jù)庫管理員（DBA）只對部分值進行查詢或更新的時候，Key-value就顯得效率低下了。舉例如：Tokyo Cabinet/Tyrant，Redis，Voldemort，Oracle BDB。列存儲數(shù)據(jù)庫：這部分數(shù)據(jù)庫通常是用來應對分布式存儲的海量數(shù)據(jù)。鍵仍然存在，但是它們的特點是指向了多個列。這些列是由列家族來安排的。如：Cassandra，HBase，Riak。文檔型數(shù)據(jù)庫：文檔型數(shù)據(jù)庫的靈感是來自于Lotus Notes辦公軟件的，而且它同名列前茅種鍵值存儲相類似。該類型的數(shù)據(jù)模型是版本化的文檔，半結構化的文檔以特定的格式存儲，比如JSON。文檔型數(shù)據(jù)庫可以看作是鍵值數(shù)據(jù)庫的升級版，允許之間嵌套鍵值，在處理網(wǎng)頁等復雜數(shù)據(jù)時，文檔型數(shù)據(jù)庫比傳統(tǒng)鍵值數(shù)據(jù)庫的查詢效率更高。如：CouchDB，MongoDb。國內也有文檔型數(shù)據(jù)庫SequoiaDB，已經(jīng)開源。圖形（Graph）數(shù)據(jù)庫：圖形結構的數(shù)據(jù)庫同其他行列以及剛性結構的SQL數(shù)據(jù)庫不同，它是使用靈活的圖形模型，并且能夠擴展到多個服務器上。NoSQL數(shù)據(jù)庫沒有標準的查詢語言（SQL），因此進行數(shù)據(jù)庫查詢需要制定數(shù)據(jù)模型。許多NoSQL數(shù)據(jù)庫都有REST式的數(shù)據(jù)接口或者查詢API。如：Neo4J，InfoGrid，Infinite Graph。

4、特點

對于NoSQL并沒有一個明確的范圍和定義，但是他們都普遍存在下面一些共同特征：

易擴展：NoSQL數(shù)據(jù)庫種類繁多，但是一個共同的特點都是去掉關系數(shù)據(jù)庫的關系型特性。數(shù)據(jù)之間無關系，這樣就非常容易擴展。無形之間，在架構的層面上帶來了可擴展的能力。大數(shù)據(jù)量，高性能：NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)異。這得益于它的無關系性，數(shù)據(jù)庫的結構簡單。一般MySQL使用Query Cache。NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說性能就要高很多。靈活的數(shù)據(jù)模型：NoSQL無須事先為要存儲的數(shù)據(jù)建立字段，隨時可以存儲自定義的數(shù)據(jù)格式。而在關系數(shù)據(jù)庫里，增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表，增加字段簡直就是——個噩夢。這點在大數(shù)據(jù)量的Web 2.0時代尤其明顯。高可用：NoSQL在不太影響性能的情況，就可以方便地實現(xiàn)高可用的架構。比如Cassandra、HBase模型，通過復制模型也能實現(xiàn)高可用。

5、體系框架

NoSQL框架體系NosoL整體框架分為四層，由下至上分為數(shù)據(jù)持久層（data persistence）、整體分布層（data distribution model）、數(shù)據(jù)邏輯模型層（data logical model）、和接口層（interface），層次之間相輔相成，協(xié)調工作。

數(shù)據(jù)持久層定義了數(shù)據(jù)的存儲形式，主要包括基于內存、基于硬盤、內存和硬盤接口、訂制可拔插四種形式?；趦却嫘问降臄?shù)據(jù)存取速度非?？?，但可能會造成數(shù)據(jù)丟失?；谟脖P的數(shù)據(jù)存儲可能保存很久，但存取速度較基于內存形式的慢。內存和硬盤相結合的形式，結合了前兩種形式的優(yōu)點，既保證了速度，又保證了數(shù)據(jù)不丟失。訂制可拔插則保證了數(shù)據(jù)存取具有較高的靈活性。

數(shù)據(jù)分布層定義了數(shù)據(jù)是如何分布的，相對于關系型數(shù)據(jù)庫，NoSQL可選的機制比較多，主要有三種形式：一是CAP支持，可用于水平擴展。二是多數(shù)據(jù)中心支持，可以保證在橫跨多數(shù)據(jù)中心是也能夠平穩(wěn)運行。三是動態(tài)部署支持，可以在運行著的集群中動態(tài)地添加或刪除節(jié)點。

數(shù)據(jù)邏輯層表述了數(shù)據(jù)的邏輯表現(xiàn)形式，與關系型數(shù)據(jù)庫相比，NoSQL在邏輯表現(xiàn)形式上相當靈活，主要有四種形式：一是鍵值模型，這種模型在表現(xiàn)形式上比較單一，但卻有很強的擴展性。二是列式模型，這種模型相比于鍵值模型能夠支持較為復雜的數(shù)據(jù)，但擴展性相對較差。三是文檔模型，這種模型對于復雜數(shù)據(jù)的支持和擴展性都有很大優(yōu)勢。四是圖模型，這種模型的使用場景不多，通常是基于圖數(shù)據(jù)結構的數(shù)據(jù)定制的。

接口層為上層應用提供了方便的數(shù)據(jù)調用接口，提供的選擇遠多于關系型數(shù)據(jù)庫。接口層提供了五種選擇：Rest，Thrift，Map/Reduce，Get/Put，特定語言API，使得應用程序和數(shù)據(jù)庫的交互更加方便。

NoSQL分層架構并不代表每個產(chǎn)品在每一層只有一種選擇。相反，這種分層設計提供了很大的靈活性和兼容性，每種數(shù)據(jù)庫在不同層面可以支持多種特性。

6、適用場景

NoSQL數(shù)據(jù)庫在以下的這幾種情況下比較適用：

數(shù)據(jù)模型比較簡單需要靈活性更強的IT系統(tǒng)對數(shù)據(jù)庫性能要求較高不需要高度的數(shù)據(jù)一致性對于給定key，比較容易映射復雜值的環(huán)境

延伸閱讀1：數(shù)據(jù)庫軟件MongoDB

MongoDB是一個介于關系數(shù)據(jù)庫和非關系數(shù)據(jù)庫之間的產(chǎn)品，是非關系數(shù)據(jù)庫中功能最豐富，最像關系數(shù)據(jù)庫的。它支持的數(shù)據(jù)結構非常松散，是類似Json的Bjson格式，因此可以存儲比較復雜的數(shù)據(jù)類型。MongoDB最大的特點是它支持的查詢語言非常強大，其語法有點類似于面向對象的查詢語言，幾乎可以實現(xiàn)類似關系數(shù)據(jù)庫單表查詢的絕大部分功能，還支持為數(shù)據(jù)建立索引。它的特點是高性能、易部署、易使用、存儲數(shù)據(jù)非常方便。