MongoDB 一個基於分佈式文件存儲的數據庫 (一)
MongoDB[2]
是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。他支持的數據結構非常鬆散，是類似json的bson格式，因此可以存儲比較複雜的數據類型。Mongo最大的特點是他支持的查詢語言非常強大，其語法有點類似於面向對象的查詢語言，幾乎可以實現類似關係數據庫單表查詢的絕大部分功能，而且還支持對數據建立索引。[3]
一、MongoDB介紹
1.1 歷史
在2007年的後期，Dwight Merriman，艾略特霍洛維茨和他們的團隊決定開發一個在線的網站服務。該服務的目的是爲開發、託管和自動伸縮網絡提供一個平臺。應用程序，與谷歌應用引擎或微軟Azure等產品有很大的合作。很快他們認識到沒有任何開放源碼數據庫平臺適合於服務的需求。我們覺得很多現有的數據庫並沒有真正的“雲計算”原則它們具有:彈性、可伸縮性和……易於管理，但也易於使用。
1.2 MongoDB的設計原則
1.2.1 高速、可擴展性和敏捷性
設計團隊在設計MongoDB時的目標是創建一個快速、大規模可擴展的數據庫，和容易使用。爲了在分區數據庫中實現速度和水平的可伸縮性，上限定理，一致性和事務支持必須被妥協。因此,每這個定理,MongoDB提供了高可用性、可伸縮性和分區，以達到一致性和事務性的成本。支持。在實際操作中，這意味着，MongoDB不是使用表和行，而是使用文檔來實現它。靈活、可伸縮、快。
1.2.2 非關係型方法
傳統的RDBMS平臺使用擴展方法提供可伸縮性，這需要更快的服務器提高性能。RDBMS系統中的下列問題導致了MongoDB和其他NoSQL的原因數據庫是按照設計的方式設計的:
● 爲了進行擴展，RDBMS數據庫需要將可用的數據連接起來或者更多的系統來報告結果。這是很難做到的RDBMS系統在所有數據可用時都被設計成可以工作的一起計算。因此，數據必須可用於單個處理的位置。
● 在多個主動活動服務器的情況下，當兩者都得到更新時在確定哪個更新是正確的方面，多個源是一個挑戰。
● 當應用程序試圖從第二個服務器讀取數據和信息時已經在第一個服務器上進行了更新，但是還沒有與第二個服務器同步服務器，返回的信息可能已經過時了。
MongoDB團隊決定採用一種非關係型的方法來解決這些問題。作爲MongoDB將其數據存儲在BSON文檔中，其中所有相關數據都放在一起，這意味着一切都在一個地方。MongoDB中的查詢基於文檔中的鍵，所以文檔可以跨多個服務器傳播。查詢每個服務器意味着它將檢查自己的一組文檔並返回結果。這支持線性可伸縮性和提高性能。
MongoDB有一個主次複製，其中主接受寫請求。如果編寫性能需要改進，然後可以使用分片;這將跨多個數據分割機器並使這些多臺機器能夠更新數據集的不同部分。切分是在MongoDB自動;隨着更多的機器被添加，數據被自動地分發。
1.2.3 基於JSON的文檔存儲
MongoDB使用基於json的(JavaScript對象標記)文檔存儲爲數據。JSON / BSON提供一個無模式的模型，它在數據庫設計方面提供了靈活性。與RDBMSs不同，更改可以對模式進行無縫的處理。
該設計還通過提供相關數據的分組來實現高性能。在內部，讓它易於搜索。
JSON文檔包含實際的數據，並且與SQL中的一行相當。然而,形成鮮明對比RDBMS行，文檔可以有動態模式。這意味着集合中的文檔可以不同的字段或結構，或公共字段可以有不同類型的數據。
一個文檔以鍵值對的形式包含數據。讓我們用一個例子來理解這個問題:
正如前面提到的，鍵和值是成對出現的。文檔中一個鍵的值可以是空的。在上面的示例中，文檔有三個鍵，即“Name”、“Phone”和“傳真”。“傳真”鍵
沒有價值。
1.2.4 性能和功能對比
爲了使MongoDB具有高性能和快速的特性，RDBMS中常用的一些特性系統在MongoDB中是不可用的。MongoDB是一種面向文檔的DBMS，數據存儲在其中文檔。它不支持連接，也不具有完全通用的事務。然而,它確實爲輔助索引提供支持，它允許用戶查詢使用查詢文檔，並且提供支持每個文檔級別的原子更新。它提供了一個副本集，這是主從的一種形式具有自動故障轉移的複製，並且具有內置的水平擴展。
1.2.5 隨處都能運行數據庫
主要的設計決策之一是能夠從任何地方運行數據庫，這意味着它應該能夠在服務器、虛擬機、甚至雲計算上運行，使用“按你付費”的服務。的語言
用於實現MongoDB的是C++，它使MongoDB能夠實現這一目標。10 gen網站爲不同的操作系統平臺提供二進制文件，使MongoDB能夠在幾乎任何類型的機器上運行。
下面是MongoDB與SQL的不同之處。
1。MongoDB使用文檔來存儲它的數據，它提供了一個靈活的模式(相同集合中的文檔可以有不同的字段)。這使用戶能夠存儲嵌套或多值字段，如數組、散列等。相反，RDBMS系統提供一個固定的模式，其中列的值應該具有類似的數據類型。同樣，在單元格中存儲數組或嵌套值是不可能的。
2。MongoDB沒有提供對連接操作的支持，比如SQL。但是，它使用戶能夠將所有相關的數據存儲在一個文檔中，避免在外圍使用連接。它有一個解決這個問題的方法。我們將在後面的章節中更詳細地討論這個問題。
3。MongoDB不像SQL那樣提供對事務的支持。但是，它保證了文檔級別的原子性。另外，它使用隔離操作符隔離影響多個文檔的寫操作，但它確實如此
二、MongoDB的數據結構
2.1 數據模型
MongoDB是一個基於文檔的數據庫系統，其中有文檔可以有一個靈活的模式。這意味着集合中的文檔可以有不同(或相同)集的字段。這在處理數據時提供了更大的靈活性
在本章中，您將探索MongoDB的靈活數據模型。哪裏有需要,我們將與RDBMS系統相比，演示了這種方法的區別。
MongoDB部署可以有許多數據庫。每個數據庫都是一組集合。集合類似於SQL中的表的概念;然而,他們是無模式。每個集合都可以有多個文檔。可以將文檔看作是SQL中的一行。圖4-1描述了MongoDB數據庫模型。
在RDBMS系統中，因爲每個列的表結構和數據類型都是固定的，所以可以只在列中添加特定數據類型的數據。在MongoDB中，集合是文檔的集合將數據存儲爲鍵-值對。
讓我們以一個示例來理解數據是如何存儲在文檔中的。下面的文檔包含以下內容用戶的姓名和電話號碼:
動態模式意味着同一集合中的文檔可以具有相同或不同的集合在字段或結構中，甚至公共字段都可以在文檔中存儲不同類型的值。有數據存儲在一個集合的文檔中的方式是不嚴格的。
因此，一個集合的文檔可以有完全不同的模式。它會落到應用程序來存儲一個特定集合中的文檔或多個集合。
1.2.1 JSON和BSON
MongoDB是一個基於文檔的數據庫。它使用二進制JSON存儲數據。
在本節中，您將瞭解JSON和二進制-JSON(BSON)。JSON代表JavaScript對象符號。在當今的現代Web(以及XML)中，它是用於數據交換的標準。的格式是人類和機器可讀的。這不僅是交換數據的好方法，也是存儲數據的好方法。
所有的基本數據類型(例如字符串、數字、布爾值和數組)都是由JSON支持的。
下面的代碼顯示了JSON文檔的樣子:
JSON使您可以將所有相關的信息集中在一個地方，這提供了優秀的信息的性能。它還使文檔的更新成爲獨立的。它是無模式。
MongoDB以二進制編碼的格式存儲JSON文檔。這被稱爲“BSON”。BSON數據模型是JSON數據模型的擴展形式。MongoDB的一個BSON文檔的實現是快速的、可實現的，並且是輕量級的。它支持在其他數組中嵌入數組和對象，並允許MongoDB進入對象內部在頂級和嵌套的BSON鍵上構建索引並匹配對象。
1.2.2 標識符（_id）
您已經看到MongoDB將數據存儲在文檔中。文檔是由鍵值對組成的。儘管可以將文檔與RDBMS中的一行進行比較，但與一行不同，文檔具有靈活的模式。一個鍵，它僅僅是一個標籤，可以粗略地與RDBMS中的列名相比較。使用一個關鍵用於從文檔中查詢數據。因此，就像RDBMS主鍵(用於惟一地標識每個鍵行)，您需要有一個鍵，它惟一地標識一個集合中的每個文檔。這被稱爲在MongoDB
_id。
如果您沒有顯式地爲鍵指定任何值，那麼將自動生成一個惟一的值並由MongoDB分配給它。這個鍵值是不可變的，除了數組之外，它可以是任何數據類型。
1.2.3 固定集合
您現在已經精通了集合和文檔。讓我們來討論一種特殊的集合叫做a限制收集
MongoDB有一個限制集合的概念。這意味着它將文檔存儲在集合中在插入的順序。當集合達到其極限時，文檔將從集合中刪除。在FIFO(首先是，先出)訂單。這意味着，最近插入的文檔將首先被刪除。
這對於需要自動維護插入順序的用例來說是很好的，並且需要在固定大小的情況下刪除記錄。一個這樣的用例是自動生成的日誌文件在一定大小後截斷。
2.2 多態模式
由於您已經熟悉MongoDB數據結構的無模式特性，現在讓我們來探索一下多態模式和用例。
多態模式是一個模式，其中一個集合擁有不同類型或模式的文檔。這個模式的一個很好的例子是一個名爲Users的集合。一些用戶文檔可能會有額外的傳真數字或電子郵件地址，而其他人可能只有電話號碼，但所有這些文檔都是共存的在相同的用戶集合中。這個模式通常被稱爲多態模式。
1.2.1 面向對象編程
面向對象編程使您可以使用繼承來讓類共享數據和行爲。它還允許在父類中定義函數，這些函數可以在子類中被覆蓋，這樣就可以在不同的環境下，函數是不同的。換句話說，您可以使用相同的函數名來操作除了父類，子元素和父類都是不同的。這特性被稱爲多態性。
在本例中，需求是具有一個模式，其中包括所有相關的對象集合層次結構中的對象可以組合在一起，也可以被相同的檢索。
讓我們考慮一個例子。假設您有一個允許用戶上傳和共享的應用程序不同的內容類型，如HTML頁面、文檔、圖像、視頻等等。在上述所有內容類型中都是常見的(例如名稱、ID、作者、上傳日期，以及時間)，不是所有的字段都是相同的。例如，在圖像的情況下，你有一個二進制字段圖像內容，而HTML頁面有一個大的文本字段來存放HTML內容。
在此場景中，可以使用MongoDB多態模式，其中所有內容節點類型都可以使用存儲在相同的集合中，例如LoadContent，並且每個文檔只有相關的字段。
這個模式不僅允許您將具有不同結構的相關數據存儲在相同的結構中集合，它也簡化了查詢。相同的集合可以用於執行常見的查詢諸如獲取某個特定日期和時間上上傳到的所有內容以及特定字段的查詢等字段例如查找大小大於X
MB的圖像。因此，面向對象編程是擁有多態模式的用例之一。是有意義的。
1.2.2 模式演化
當您使用數據庫時，您需要考慮的最重要的考慮事項之一因爲模式的演化(例如，模式對正在運行的應用程序的影響)。設計應該在某種程度上對應用程序進行最小或不影響，這意味着沒有或最小限度停機時間、不或非常小的代碼更改等等。
通常情況下，模式演化是通過執行一個遷移腳本來實現的，該腳本將數據庫模式從舊版本升級到新版本。如果數據庫不在生產環境中，腳本可以簡單地刪除和重新使用數據庫。但是，如果數據庫位於生產環境中，並且包含實時數據，那麼遷移腳本將是複雜的，因爲需要保存數據。腳本應該考慮這個問題。儘管MongoDB提供了一個更新選項，可用於更新集合中的所有文檔結構，如果有一個字段的新添加，請想象如果在集合中有數千個文檔，那麼做這件事的影響。它將非常緩慢，並且會對底層應用程序的性能產生負面影響。這樣做的一種方法是將新結構添加到新文檔中，並將這些文檔添加到集合中，然後在應用程序仍在運行時逐漸將其遷移到後臺。這是許多用例中的一個，其中多態模式將是有利的。
About Me：
Github地址：https://github.com/noseparte
Email：[email protected] 有java與hadoop相關的技術問題，可以發私信與我交流。
NPM地址：https://www.npmjs.com/~noseparte
個人網站 ： http://www.noseparte.com/ Copyright © 2017 noseparte