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

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

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

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

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

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

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

文檔數據庫的關鍵特性

RESTful HTTP API

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

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

單個記錄中的相關數據

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

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

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

示例代碼2 CouchDB示例

{
  "Subject": "I like Plankton"  
  "Author": "Rusty"  
  "PostedDate": "5/23/2006"  
  "Tags": ["plankton", "baseball", "decisions"]
  "Body": "I decided today that I don't like baseball. I like plankton."
}