現今雲計算的從業人員對NoSQL一詞並不感到陌生,雖然很多技術人員都長期從事HTTP://www.aliyun.com/zixun/aggregation/22.html">關係資料庫的工作, 但現在他們對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並不支援複雜的事務,只支援少量的原子操作,所以不適用於「轉帳」等對事務和一致性要求很高的場合。 這就要求需要一個關係資料庫來對交易進行過高級別的控制。
(責任編輯:蒙遺善)