NoSQL數據庫技術特性解析之文檔數據庫

現今雲計算的從業人員對NoSQL一詞並不感到陌生，雖然很多技術人員都長期從事關系數據庫的工作，但現在他們對NoSQL技術充滿期待。對於企業來說，從關系型數據庫到NoSQL數據庫轉變絕對是個需要深思熟慮的大改變。這涉及的不僅是軟件的變化，更多的是對於數據存儲上觀念性的變化。

CouchDB專家兼作者Bradley Holt認為NoSQL並不是反SQL的運動，為對應的工作選擇最恰當的工具才是正確的模式。

大多數非關系數據庫都具有快速和可伸縮的特性。通過放棄關系存儲模型和架構，關系數據庫便可脫離由緊密結合的架構所帶來對其施加的限制。應用程序也無需再鏈接數據庫內表中的數據。

MongoDB和CouchDB以及RavenDB（RavenDB是基於Mocrosoft .NET Framework編寫的）等文檔數據庫除了某些特定的轉換外，通常都是通過HTTP為其提供數據，然後將數據存儲為JSON（JavaScript Object Notation）格式的文檔，並提供多種語言的API接口。這三款開源的文檔數據庫都將簡潔、速度和可伸縮性作為其設計的重要指標。RavenDB的創建者Ayende Rahien就表示“RavenDB的設計初衷就旨在快速寫入並讀取”。

NoSQL——關系數據庫的有力補充

現今，NoSQL和文檔數據庫成為關系數據庫的有力補充（而非替代品），同時提供了更多的選擇。如果企業准備將數據遷移，那麼選擇NoSQL的重要標准就是要看CAP（Consistency、Availability和Partition Tolerance），也就是我們所說的一致性、可用性和分區容忍性。但CAP原則要求在分布式系統只能選擇一致性、可用性和分區容忍性其中的兩項。所以如果企業認為一致性是重要的那麼關系數據庫理應是優先選擇的對象。

例如在銀行等應用領域，一致性是非常重要的，這要求必須隨時考慮每個數據塊。而CAP原則中的可用性也不容忽視，某些領域的數據可用性要比等待所有交易數據收集齊全更為重要。最後在水平縮放時，分區容忍性對於文檔數據庫顯得尤為關鍵。但MongoDB並不支持復雜的事務，只支持少量的原子操作，所以不適用於“轉帳”等對事務和一致性要求很高的場合。這就要求需要一個關系數據庫來對交易進行過高級別的控制。

文檔數據庫的關鍵特性

RESTful HTTP API

RESTful API設計就是為了消除創建松散耦合服務時的依賴關系，這也正是過去分布式體系結構的缺陷。雖然要映射到一些協議需要依賴於元數據的可用性以及方法等，但REST API的設計目標就是不依賴於任何通信協議。

眾多NoSQL數據庫都可通過RESTful的方式訪問。這樣可以通過URI的方式建立數據庫連接，而查詢和命令則通過HTTP實現。MongoDB和CouchDB都提供了特定語言的API接口，以便編寫和執行查詢、更新。但MongoDB的默認設置仍然是使用TCP與數據庫進行連接。而RavenDB則具備基於.NET的客戶端API，可簡化與數據庫的交互過程。

單個記錄中的相關數據

大多數人都錯誤的認為非關系數據庫是一種包含沒有相對關系結構的記錄的文件。而文檔數據庫中存儲的數據包含形狀數據——具有節點的樹。數據庫中的每個記錄都是以文檔形式存在的。並具備自我描述的功能，而不依賴於任何其他文檔。

示例代碼1：文檔數據庫（MongoDB）中的典型事例

{ 
  "name" : "Jim", 
  "scores" : [ 75, 99, 87.2 ] 
}