關係型到文件型的跨越

csdn發表於2015-07-14

　　在文件型NoSQL資料庫出現之前，許多開發者一直絞盡腦汁思考，希望能想出更好的處理關係型資料庫技術的方法，如今他們可能要跳出那種思維而另闢蹊徑。本篇將介紹關係型資料庫和分散式文件型資料庫的區別以及在應用開發上的一些建議。

　　1. 為什麼要轉變？

　　人們通常都不願意改變，因為改變總是痛苦的，除非它能顯著解決一些問題。隨著大資料的發展，我們越來越有必要開始對資料模型做出轉變了。換句話說，這種轉變的需求愈發的強烈，因為大資料時代不管是對於資料庫的擴充套件模型還是資料模型都要求極高的靈活性。

　　1.1 擴充套件模型

　　關係型資料庫是一種“縱向擴充套件”的技術，想要擴充套件容量（無論資料儲存還是I/O），都需要更換更大的伺服器。現代應用結構的解決卻是使用“橫向擴充套件”----無需新購買更大的伺服器，只需要在負載均衡器下增加一般的伺服器、虛擬機器或是雲伺服器就可以實現擴充套件。此外，容量在不再需要的時候還可以輕易的縮減。事實上，“橫向擴充套件”在應用邏輯層的使用已經很廣泛了，只是資料庫技術上剛剛趕上而已。

　　1.2資料模型

　　NoSQL“橫向擴充套件”部署方案的優點已經受到了業界的注意，但是同時很多人忽略的是NoSQL資料管理的簡潔，不需要很複雜的操作模式構建，這一點對於資料庫的提升也和擴充套件模型一樣重要。在使用傳統關聯式資料庫時，新增資料前，需要定義操作模式。之後每一條記錄的加入都需要嚴格的按照定義的操作模式進行，比如固定的列數和資料型別。因此，改變那些分割槽關係型資料庫的操作模式，會非常的麻煩。如果你的資料獲取和資料管理需求經常變化，那這種嚴格的模式限制將會成為制約表現的屏障。

　　NoSQL（無論文件型、列式、K-V等等）都是水平擴充套件的，它們都不需要預先定義操作模式、所以也不需要在需求改變時改變操作模式。

　　接下來我就將使用SequoiaDB來介紹文件型NoSQL資料庫技術：

　　2. 資料模型：關係型vs.文件型 

　　下圖就對比了四條記錄在關係型和文件型資料模型下的儲存情況：

關係型到文件型的跨越

　　2.1 關係型資料模型

　　如上所示，關係型資料庫中的每一條記錄儲存都需要遵守一個固定的模式----固定的列數，每一列都是有特定的意義而且規定了資料型別。如果要獲取不同的資料，資料庫的模式就需要重新修改。

　　此外，關係型模型還有一個特點就是“資料庫標準化”，也就是大的表會被壓縮成小的、整合的表，如下圖所示：

關係型到文件型的跨越

　　在上面的例子中，資料庫用來儲存錯誤日誌資訊。每個錯誤記錄（表1中的一行）由3部分組成：錯誤號ERR，錯誤發生的時間TIME，和錯誤發生的資料中心DC。為了避免重複記錄所有的錯誤記錄的資料中心資訊，現在每條錯誤記錄將都指向表2（資料中心資訊）中的對應的地點那一條記錄。這樣就不需要實際儲存具體的DC資訊在表1中，需要使用時只要到對應的表2行獲取就可以了。

　　在關係模型當中，多個表中的不同記錄經常“交錯連線”，一些資料會被多條記錄共享。這樣的好處就是減少了重複資料的出現，但是這樣不好的地方就是一旦其中某一條連結的記錄發生改變，那麼與其相關的記錄和表都會被鎖住以防止非一致性的出現。 ACID事務在關係型資料庫中是很複雜的，因為資料會擴散。即便是單一條記錄，這複雜的共享資料內部關係網的存在，也使得關係型資料在多個伺服器之間的傳遞變得複雜而緩慢，同時讓讀和寫操作的效能變差。

　　當儲存空間昂貴又稀少時，折中的權衡方案是很必要的。然而，如今儲存空間的價格跟40年前相比已經大大的下降了，很多時候計算折中方案已經完全沒有必要。使用更多的儲存空間來換取更好的操作效能，或者是將工作負載分配到多臺機器上，這才是如今應用上更好的解決方案。

　　2.2文件型資料模型

　　使用“文件”這個詞似乎讓人覺得奇怪，但是其實 “文件型資料模型”真的和傳統意義的文字“文件”沒有什麼關係。他不是書、信或者文章，這裡說的“文件”其實是一個資料記錄，這個記錄能夠對包含的資料型別和內容進行“自我描述”。XML文件、HTML文件和JSON 文件就屬於這一類。SequoiaDB就是使用JSON格式的文件型的資料庫，它的儲存的資料是這樣的：

{
“ID”:1,
“NAME”: “SequoiaDB”,
“Tel”: {
       “Office”: “123123”, “Mobile”: “132132132”
}
“Addr”: “China,GZ”
}

　　可以看到，資料是不規則的，每一條記錄包含了所有的有關“SequoiaDB”的資訊而沒有任何外部的引用，這條記錄就是“自包含”的。這就使得記錄很容易完全移動到其他伺服器，因為這條記錄的所有資訊都包含在裡面了，不需要考慮還有資訊在別的表沒有一起遷移走。同時，因為在移動過程中，只有被移動的那一條記錄（文件）需要操作而不像關係型中每個有聯絡的表都需要鎖住來保證一致性，這樣一來ACID的保證就會變得更快速，讀寫的速度也會有很大的提升。

　　3. 文件型資料模型的應用

　　你可能需要一段時間去忘記以前的習慣，不過不要害怕，瞭解其他方面的知識可以讓你更充分的利用你已經學會的知識，不管怎麼樣最能解決問題的才是最好的。瞭解了不同的方法，你才可以選擇最適合的！

　　3.1 模型

　　在應用中，資料物件是核心的部分-----也是模型檢視控制器（MVC）中的模型層。當分析一款應用時，現在你可以先把目光停在物件關係對映層（ORM）上。與其將不同的模型定製成為不同的表和行，不如都用JSON格式儲存成文件形式吧，每個JSON文件都有唯一的id方便查詢。

　　3.2 鍵

　　在文件型資料庫中，每個JSON文件的ID就是它唯一的鍵，這也大致相當於關係型資料庫中的主鍵。通常ID在一個資料庫“集合”中是唯一的（NoSQL中，類似RDBMS的“表”的分類結構有很多種，如SequoiaDB的集合Collection或者是Couchbase的bucket）。

　　一些NoSQL資料庫會用ID排序，那麼相近ID的資料自然更容易被檢索到，經常需要一起呼叫的資料放在一起可以大大提升處理的速度。

　　3.3 靈活性

　　如今的社交網站越來越普及，而隨著使用者量不斷壯大，每個使用者的使用方式或者是釋出的內容型別都不盡相同。有人會發布風景照片、有人釋出對時事的評論還有人分享音樂表達心情。面對如此大量而多樣性的資料，如果使用關係型模型，就需要不斷你的修改資料操作模式，這樣，可能會引起系統負載的大大提升，同時也會大大增加處理的時間。

　　這時，文件型模型儲存就凸顯其優點了，面對複雜多變的資料，使用文件型模型就直接保留了原有資料的樣貌，不需要另外建立新的表新的操作模式來處理，這樣不僅儲存直接快速，再過後呼叫時，也可以做到“整存整取”，不需要關係型模型那樣再到各種連結的表上取出需要顯示的記錄。在RDBMS中，需要儘可能的標準化資料。而在NoSQL中，則是可以儘可能的對資料“去標準化”。

　　3.4 併發性

　　接著上一個例子，在社交網路當中，使用者的操作量很大，許多人每天會花很多的時間泡在社交網路之中。使用傳統關係資料模型時，例如，兩個使用者的釋出資訊同時連結到了“地點”，那麼其中一個人回頭修改自己的釋出時，因為連結到了“地點”表，系統為了保證一致性就會把“地點”表鎖住不讓其他使用者同時提出修改，這時另外的使用者暫時就沒辦法操作“地點”表了。

　　如果使用文件型模型，每個人的釋出就是獨立的一個“文件”，這一個文件檔案就包含了這一條釋出的所有資訊。因為這種“自包含”的特性，不同的使用者修改資料只需要修改自己的文件而不會影響別人的操作。這樣就實現了高的併發性！

　　4. 結論

　　關係型資料模型的複雜查詢操作，倚賴的是資料庫模式的嚴格一致，資料的標準化以及資料的合併。在過去的40年中，關係型模型和查詢技術已經發展成熟也被眾多的開發者所熟悉。

　　但是，應用、使用者和基礎的特點的變化使得應用開發者和架構師開始選擇“NoSQL”這種非關係型的資料庫技術，許多觀點認為分散式文件資料庫技術在很多方面都要勝過RDBMS：

  • 它可以輕鬆的通過普通機器、虛擬機器或者雲例項來實現近乎無上限的水平擴充套件。
  • 新增資料是他不需要嚴格的資料庫操作模式，因此在修改資料型別時自然也不需要修改資料庫模式。
  • 多樣化的資料模型能更好的的支援複雜資料的建模、儲存和查詢。

　　雖然，資料的去結構化可能會使用到更多的空間，但隨著儲存空間價格的不斷下降，儲存空間和讀寫速度的比重勢必將越來越像追求速度一方傾斜，而由此帶來的高效能、可擴充套件性以及靈活的資料結構等優點又將大大提升應用的各方面效能表現。

　　SequoiaDB的資料模型就是以JSON格式儲存的文件型模型，所以SequoiaDB具備了文件型和NoSQL資料庫的資料靈活性和高可擴充套件性。SequoiaDB的文件型資料模型不僅簡化了資料存取的過程，也大大的提升了資料的靈活性。在應用中不僅免去了設計模式這個麻煩的環節，還能很好的適應大資料時代高併發、實時性和分散式的要求。

　　作者簡介：李方舟（Ark），目前在國產開源新型分散式資料庫公司工作，大資料行業的新行者，喜歡研究開源，關注行業動態。

相關文章