關係型到文檔型的跨越：顛覆你對數據庫數據模型的認識

1.簡介

在文檔型NoSQL數據庫出現以前，許多開發者一直絞盡腦汁思考，但願能想出更好的處理關係型數據庫技術的方法，現在他們可能要跳出那種思惟而另闢蹊徑。本篇白皮書將介紹關係型數據庫和分佈式文檔型數據庫的區別以及在應用開發上的一些建議。

2.爲何要轉變？
人們一般都不肯意改變，由於改變老是痛苦的，除非它能顯著解決一些問題。隨着大數據的發展，咱們愈來愈有必要開始對數據模型作出轉變了。換句話說，這種轉變的需求愈發的強烈，由於大數據時代無論是對於數據庫的擴展模型仍是數據模型都要求極高的靈活性。
2.1 擴展模型
關係型數據庫是一種「縱向擴展」的技術，想要擴展容量（不管數據存儲仍是I/O），都須要更換更大的服務器。現代應用結構的解決倒是使用「橫向擴展」----無需新購買更大的服務器，只須要在負載均衡器下增長通常的服務器、虛擬機或是雲服務器就能夠實現擴展。此外，容量在再也不須要的時候還能夠輕易的縮減。事實上，「橫向擴展」在應用邏輯層的使用已經很普遍了，只是數據庫技術上剛剛遇上而已。
2.2 數據模型
NoSQL「橫向擴展」部署方案的優勢已經受到了業界的注意，可是同時不少人忽略的是NoSQL數據管理的簡潔，不須要很複雜的操做模式構建，這一點對於數據庫的提高也和擴展模型同樣重要。在使用傳統關係數據庫時，添加數據前，須要定義操做模式。以後每一條記錄的加入都須要嚴格的按照定義的操做模式進行，好比固定的列數和數據類型。所以，改變那些分區關係型數據庫的操做模式，會很是的麻煩。若是你的數據獲取和數據管理需求常常變化，那這種嚴格的模式限制將會成爲制約表現的屏障。
NoSQL（不管文檔型、列式、K-V等等）都是水平擴展的，它們都不須要預先定義操做模式、因此也不須要在需求改變時改變操做模式。接下來我就將使用SequoiaDB來介紹文檔型NoSQL數據庫技術。

3.數據模型: 關係型vs.文檔型
下圖就對比了四條記錄在關係型和文檔型數據模型下的存儲狀況：

3.1 關係型數據模型
如上所示，關係型數據庫中的每一條記錄存儲都須要遵照一個固定的模式----固定的列數，每一列都是有特定的意義並且規定了數據類型。若是要獲取不一樣的數據，數據庫的模式就須要從新修改。
此外，關係型模型還有一個特色就是「數據庫標準化」，也就是大的表會被壓縮成小的、整合的表，以下圖所示：

在上面的例子中，數據庫用來存儲錯誤日誌信息。每一個錯誤記錄（表1中的一行）由3部分組成：錯誤號ERR，錯誤發生的時間TIME，和錯誤發生的數據中心DC。爲了不重複記錄全部的錯誤記錄的數據中心信息，如今每條錯誤記錄將都指向表2（數據中心信息）中的對應的地點那一條記錄。這樣就不須要實際存儲具體的DC信息在表1中，須要使用時只要到對應的表2行獲取就能夠了。
在關係模型當中，多個表中的不一樣記錄常常「交錯鏈接」，一些數據會被多條記錄共享。這樣的好處就是減小了重複數據的出現，可是這樣很差的地方就是一旦其中某一條連接的記錄發生改變，那麼與其相關的記錄和表都會被鎖住以防止非一致性的出現。 ACID事務在關係型數據庫中是很複雜的，由於數據會擴散。即使是單一條記錄，這複雜的共享數據內部關係網的存在，也使得關係型數據在多個服務器之間的傳遞變得複雜而緩慢，同時讓讀和寫操做的性能變差。
當存儲空間昂貴又稀少時，折中的權衡方案是很必要的。然而，現在存儲空間的價格跟40年前相比已經大大的降低了，不少時候計算折中方案已經徹底沒有必要。使用更多的存儲空間來換取更好的操做性能，或者是將工做負載分配到多臺機器上，這纔是現在應用上更好的解決方案。
3.2 文檔型數據模型
使用「文檔」這個詞彷佛讓人以爲奇怪，可是其實 「文檔型數據模型」真的和傳統意義的文字「文檔」沒有什麼關係。他不是書、信或者文章，這裏說的「文檔」實際上是一個數據記錄，這個記錄可以對包含的數據類型和內容進行「自我描述」。XML文檔、HTML文檔和JSON 文檔就屬於這一類。SequoiaDB就是使用JSON格式的文檔型的數據庫，它的存儲的數據是這樣的：

能夠看到，數據是不規則的，每一條記錄包含了全部的有關「SequoiaDB」的信息而沒有任何外部的引用，這條記錄就是「自包含」的。這就使得記錄很容易徹底移動到其餘服務器，由於這條記錄的全部信息都包含在裏面了，不須要考慮還有信息在別的表沒有一塊兒遷移走。同時，由於在移動過程當中，只有被移動的那一條記錄（文檔）須要操做而不像關係型中每一個有聯繫的表都須要鎖住來保證一致性，這樣一來ACID的保證就會變得更快速，讀寫的速度也會有很大的提高。

4.文檔型數據模型的應用
你可能須要一段時間去忘記之前的習慣，不過不要懼怕，瞭解其餘方面的知識可讓你更充分的利用你已經學會的知識，無論怎麼樣最能解決問題的纔是最好的。瞭解了不一樣的方法，你才能夠選擇最適合的！
4.1模型
在應用中，數據對象是核心的部分-----也是模型視圖控制器（MVC）中的模型層。當分析一款應用時，如今你能夠先把目光停在對象關係映射層（ORM）上。與其將不一樣的模型定製成爲不一樣的表和行，不如都用JSON格式存儲成文檔形式吧，每一個JSON文檔都有惟一的id方便查找。
4.2 鍵
在文檔型數據庫中，每一個JSON文檔的ID就是它惟一的鍵，這也大體至關於關係型數據庫中的主鍵。一般ID在一個數據庫「集合」中是惟一的（NoSQL中，相似RDBMS的「表」的分類結構有不少種，如SequoiaDB的集合Collection或者是Couchbase的bucket）。一些NoSQL數據庫會用ID排序，那麼相近ID的數據天然更容易被檢索到，常常須要一塊兒調用的數據放在一塊兒能夠大大提高處理的速度。
4.3 靈活性
現在的社交網站愈來愈普及，而隨着用戶量不斷壯大，每一個用戶的使用方式或者是發佈的內容類型都不盡相同。有人會發布風景照片、有人發佈對時事的評論還有人分享音樂表達心情。面對如此大量而多樣性的數據，若是使用關係型模型，就須要不斷你的修改數據操做模式，這樣，可能會引發系統負載的大大提高，同時也會大大增長處理的時間。
這時，文檔型模型存儲就凸顯其優勢了，面對複雜多變的數據，使用文檔型模型就直接保留了原有數據的樣貌，不須要另外建立新的表新的操做模式來處理，這樣不只存儲直接快速，再事後調用時，也能夠作到「整存整取」，不須要關係型模型那樣再到各類連接的表上取出須要顯示的記錄。在RDBMS中，須要儘量的標準化數據。而在NoSQL中，則是能夠儘量的對數據「去標準化」。
4.4 併發性
接着上一個例子，在社交網絡當中，用戶的操做量很大，許多人天天會花不少的時間泡在社交網絡之中。使用傳統關係數據模型時，例如，兩個用戶的發佈信息同時連接到了「地點」，那麼其中一我的回頭修改本身的發佈時，由於連接到了「地點」表，系統爲了保證一致性就會把「地點」表鎖住不讓其餘用戶同時提出修改，這時另外的用戶暫時就沒辦法操做「地點」表了。
若是使用文檔型模型，每一個人的發佈就是獨立的一個「文檔」，這一個文檔文件就包含了這一條發佈的全部信息。由於這種「自包含」的特性，不一樣的用戶修改數據只須要修改本身的文檔而不會影響別人的操做。這樣就實現了高的併發性！

5. 結論

關係型數據模型的複雜查詢操做，倚賴的是數據庫模式的嚴格一致，數據的標準化以及數據的合併。在過去的40年中，關係型模型和查詢技術已經發展成熟也被衆多的開發者所熟悉。
可是，應用、用戶和基礎的特色的變化使得應用開發者和架構師開始選擇「NoSQL」這種非關係型的數據庫技術，許多觀點認爲分佈式文檔數據庫技術在不少方面都要賽過RDBMS：
它能夠輕鬆的經過普通機器、虛擬機或者雲實例來實現近乎無上限的水平擴展。
添加數據是他不須要嚴格的數據庫操做模式，所以在修改數據類型時天然也不須要修改數據庫模式。
多樣化的數據模型能更好的的支持複雜數據的建模、存儲和查詢。
雖然，數據的去結構化可能會使用到更多的空間，但隨着存儲空間價格的不斷降低，存儲空間和讀寫速度的比重勢必將愈來愈像追求速度一方傾斜，而由此帶來的高性能、可擴展性以及靈活的數據結構等優勢又將大大提高應用的各方面性能表現。
SequoiaDB的數據模型就是以JSON格式存儲的文檔型模型，因此SequoiaDB具有了文檔型和NoSQL數據庫的數據靈活性和高可擴展性。SequoiaDB的文檔型數據模型不只簡化了數據存取的過程，也大大的提高了數據的靈活性。在應用中不只免去了設計模式這個麻煩的環節，還能很好的適應大數據時代高併發、實時性和分佈式的要求。

6. 關於SequoiaDB

SequoiaDB 做爲 NoSQL 數據庫，從新設計了數據的管理方式，並推進了大數據行業的發展。SequoiaDB 數據模型的設計，使用戶可以更加敏捷地開發易擴展的系統架構。SequoiaDB 支持多種類型的應用，提供了良好的用戶體驗，加速產品發佈時間，並下降企業的運營成本。

• 2014年12月18日發佈