資料點

發行項
07/23/2015

文件資料庫到底是什麼東東？

鄭 Lerman

很有良好，聽說至少到目前為止的 NoSQL 一詞。文件甚至教導如何它下面在 MSDN 雜誌。高度尊重的人很多很棒，而且就是在關聯式資料庫，我想要了解的空間。我大肆相當多的研究和換行我暈頭轉向，pestering 的朋友，這裡我可以共用什麼我學子集的 NoSQL 資料庫稱為「記錄資料庫」。另一個的子集為索引鍵 / 值組的資料庫。Windows Azure 表格儲存體，我在我年 7 月 2010年資料點的專欄中提到的 (msdn.microsoft.com/magazine/ff796231)，為索引鍵 / 值組 NoSQL 存放區的範例。

我應該先提出 NoSQL 的定義。它已成為無所不在，並可能過度利用之條件的位元。這個詞彙用來包含資料儲存機制，不是關聯式使用因此不需要使用 SQL 來存取其資料。在他的部落格文章]"定址 NoSQL 批評」 (bit.ly/rkphh0)，CouchDB 專家和作者韓夢被說他已經聽過「重新定義為 '不僅 SQL。' NoSQL"的人他的重點是這並不是反 SQL 的任何方式移動。我喜歡這個觀點來看，，所以我在工作中使用適當的工具，大 believer。

大多數的資料庫或非關聯性的傘共用共同的目標的速度和擴充性] 底下。藉由中斷遠離關聯式儲存體模型並離開後置的結構描述，這些資料庫沒有緊密結合的結構描述，來聯結資料表間的資料的應用程式的需要放這些工具的限制。

許多文件可用的資料庫，我會把焦點放在兩個最受歡迎，MongoDB (mongodb.org) 和 CouchDB (couchdb.apache.org)，以及 RavenDB (ravendb.net)，可寫入的 microsoft。Net 應用程式，並逐漸成長 esb 中 (請參閱文章「內嵌 RavenDB 入 ASP。NET MVC 3 應用，"這一期)。這會保留高階角度而言，雖然您可以學到的許多詳細個別的資料庫也是讓它們彼此唯一造訪他們的網站。

有幾個 twists (這我會指出此文件中) 的例外狀況，這些資料庫提供他們最常透過 HTTP 的資料、將其資料儲存為 JavaScript 物件標記法 (JSON) 的文件，以多種語言會提供 Api。整體考量是簡單、速度和延展性。同樣重要的是所有的三種開放原始碼專案。

在 [我的研究，我聽說 MongoDB 專家產品的主要考量是效能。CouchDB 專家指到簡單和可靠性 (「我們想要資料庫的 Honda 同步改變")。Ayende Rahien，我能修改 RavenDB，說 RavenDB 的目標是「快速寫入、快速的讀取與世界和平」。這些文件的資料庫都更可以提供比這些音效 bites 所提供的建議。

或者，不是加以取代，關聯式資料庫

「 NoSQL 」及「文件資料庫提供另一種關聯式的資料庫，而不是加以取代。每一個都有它的位置，而且它們都只是提供更多的選項，可供選擇。而是如何選擇嗎？重要的控制鈕是一致性、可用性和磁碟分割容錯 (CAP) theorem。顯示在 [分散式系統工作時，您可以只有其中三個字元的兩個 [供應商可以保證 (C、 A 或 P)，因此您必須選取是重要的。如果一致性是最重要的您就需要使用關聯式資料庫。

一致性會在其中是最重要的保證的常見例子是銀行應用程式，或可能是指執行核子設施。在這些情況下，很重要的每個單一片段資料未必隨時都負責。當有人會提款時，您真正需要知道當您正在看他的帳戶餘額。因此，您可能需要高層級的控制其交易的關聯式資料庫。您會常聽到的詞彙"最終一致性」，或以明示上 RavenDB 站台：「與離線更過時」。在其他網域中，就已足夠最終的一致性。[確定] 它是，如果您要擷取的資料不是以毫秒接精確。

或許，那，就更重要的某些版本的資料是的話，而不是等待的所有交易完成同步處理。這與 A (可用性) cap，可將焦點放在伺服器執行時間。了解您一定可以存取資料庫會優先採用，是一大優勢，資料庫的效能 (也就是文件的資料庫是快速!)。您會發現 p，磁碟分割容錯] 中，也是很重要文件的資料庫中，特別是在水平縮放比例。

RESTful 的 HTTP API--大部分是

NoSQL 資料庫大多可存取 RESTful 的方式，因此您對您的資料庫連線，透過 URI，且查詢和命令 HTTP 呼叫。MongoDB 是例外狀況。其預設值為使用 TCP 進行資料庫互動，雖然也可以使用，至少一個 HTTP API 所示。CouchDB 和 MongoDB 提供語言專用的 Api 可讓您撰寫與執行查詢及更新，而不必擔心直接寫入 HTTP 呼叫。RavenDB 了。NET 用戶端 API，可簡化與資料庫互動。

在單一資料錄的相關的資料

很多人誤以為或非關聯性的資料庫是一般的檔案。儲存文件的資料庫中的文件都可以含有資料的形狀: 與節點的樹狀結構。在資料庫中的每一筆記錄是文件，而且可以是獨立的資料集。這是自我描述，包括其可能是唯一的結構描述-，而且不一定是依存在其他文件上。

以下是典型的範例就是一筆資料錄看起來會像在文件資料庫 (我就會偷中表示學生 MongoDB 教學課程的範例)：

{
  "name" : "Jim",
  "scores" : [ 75, 99, 87.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."
}

這些都是字串資料、數字與陣列的簡單結構。您也可以內嵌更複雜的文件結構，如本例張貼的部落格內容的物件中的物件：

{
  "BlogPostTitle”: “LINQ Queries and RavenDB”,
  "Date":"\/Date(1266953391687+0200)\/",
  "Content":”Querying RavenDB is very familiar for .NET developers who are already
    using LINQ for other purposes”,
  "Comments":[
             {
             "CommentorName":"Julie",
             "Date":"\/Date(1266952919510+0200)\/",
             "Text":"Thanks for using something I already know how to
               work with!",
             "UserId":"users/203907"             
             },
  ]
}

唯一索引鍵

所有資料庫需要金鑰。如果您沒有提供一項，它們會在內部為您建立一個。索引鍵是不可或缺的索引，資料庫的能力，但是您自己的網域可能會需要知道索引鍵。在部落格張貼上例中，請注意沒有"使用者/203907"的參考這是 RavenDB 會運用機碼值的方式，並可讓您定義文件之間的關聯性。

JSON 格式的儲存體

什麼所有這些範例記錄有共通點是他們所使用 JSON 來儲存資料。 CouchDB 和 RavenDB (和其他許多) 事實上其資料儲存在 JSON。 MongoDB 會使用稱為二進位 (BSON) JSON，能夠執行二進位序列化的 JSON 還是有些差異。 BSON 是內部表示的資料，因此程式設計的觀點而言，您不應該注意到任何差異。

JSON 簡單容易轉置成 JSON 的物件結構的幾乎所有的語言。因此，您可以定義應用程式中的物件，並將它們儲存在資料庫中直接。這讓開發人員需要不斷地轉譯資料庫結構描述和物件類別/結構描述時，用於物件關聯的對應程式 (ORM)。

全文檢索搜尋引擎-例如，Lucene (lucene.apache.org)，也就是 RavenDB 的依賴，提供高效能搜尋此文字為基礎的資料。

請注意在部落格張貼範例中的日期。 JSON 沒有日期類型，但每一個資料庫提供方法來解譯來自您正在撰寫程式碼在無論使用何種語言的日期型別。如果簽出的資料型別和慣例清單 MongoDB BSON api (bit.ly/o87Gnx)，您會看到新增日期型別，以及一些其他實質 JSON 中可用的。

儲存和擷取單一的單位的相關的資料，可以有很大的效能和可調整性優點。資料庫不必移竊取四處尋找資料通常關聯的成員，因為它是通通加起來。

型別的集合

當與資料庫互動，怎麼應用程式知道一個項目是學生、另一個是一本書和另一個是部落格文章？資料庫使用一種概念的集合。其他文件，不論其結構描述與特定的集合有關聯-比方說，學生集合-可以擷取時要求從這個集合中的資料。它也不是使用欄位來表示型別不正常的情況。這只會使搜尋更加容易，但是仍需留待您的應用程式，來強制執行哪些應該和不應該移成集合。

無結構描述的資料庫

"student"說明更早版本會包含其本身的結構描述。每一筆記錄會負責自己的結構描述，即使是包含在單一資料庫或集合項目。和一個學生資料錄並不一定符合另一個的學生資料錄。當然，您的軟體必須配合任何差異。您可以只使用這樣的彈性，為了提高效率。比方說，為什麼儲存 null 值？屬性，例如「 most_repeated 類別」沒有任何值時，您可以依下列方式：

"name" : "Jim",
"scores" : [ 75, 99, 87.2 ]
"name" : "Julie",
"scores" : [ 50, 40, 65 ],
"most_repeated_class" : "Time Management 101"

是，維吉尼亞州，我們支援交易

每個資料庫都提供某種程度的交易支援-比其他自找苦-但都不一樣具備豐富，為達成關聯式資料庫中。我將委託給其文件，並可讓您待處理的其他參考資料。

資料庫與網域導向開發的文件

其中一個網域導向開發的核心概念與模型使用彙總的根網域。在規劃您的網域類別 (這可能會成為您的資料庫中的文件)，您可以尋找較多的資料通常獨立 (比方說，它的明細項目的訂單)，並把重點放在可作為個別的資料結構。在採購系統中，您將可能也有 [客戶] 和 [產品。但可能存取訂單，而不需要它的客戶資訊，以及產品可能會使用不需要使用它的訂貨主檔的存取。這表示雖然您可以找到許多的機會，將不會排除需要或功能，可透過外部索引鍵，在某些情況下加入資料的獨立的資料結構 (例如，與其行項目順序)]。

每一個資料庫提供不同的模式，可用，以及哪些使用者有大部分的成功與指引。例如，MongoDB 文件談的卻是一種模式稱為陣列的祖，因此可加快存取相關的資料時加入文件。

巡覽關聯性的顧慮結合的重複資料的關聯式資料庫中的 sin。若要確保這正規化的資料庫。 NoSQL 資料庫，尤其分散式的在工作時取消正規化的資料是好用又可接受。

查詢和更新

每個資料庫都附有 Api 來查詢及更新。雖然它們可能不屬於核心 API，透過附加元件提供多種語言的 Api。一樣。NET Framework 項目設定為文件資料庫的世界，RavenDB 使用 LINQ 查詢 — 很棒的助益。NET 開發人員。

其他查詢是根據預先定義的檢視，並呼叫對應/減少的模式而定。這個程序的對應部分搭配使用資料夾檢視中，不同資料庫之間的對應的責任。地圖也可讓散佈到多個處理器處理的查詢資料庫。減少使用的地圖查詢 (或如果您已發佈的查詢) 的結果，並將結果傳回給用戶端的彙總資料。

地圖/降低是一種模式，以及各種不同的資料庫有它們自己的實作。楊心瑋何看法提供有趣的比較方式 RavenDB 和 CouchDB 會執行對應/降低，在 bit.ly/94OCME。

雖然 CouchDB 會要求您透過預先定義的對應減少檢視中，MongoDB (也會使用檢視表和對應/減少) 查詢還額外地提供進行臨機操作查詢的能力。 RavenDB 的查詢，可以將預先定義的索引，但也支援臨機操作查詢，而且會讓您根據實際的執行階段查詢會自動建立索引。大多數的情況下，不過，將移離已知的結構描述與關聯式性質 SQL 資料庫時，能夠執行臨機操作查詢是您遺失的功能。而只要能緊密控制的查詢，文件的資料庫可保證其快速的效能。

資料庫大革命

有， NoSQL 傘下，有許多或非關聯性的資料庫。而且，現在門已經開啟，它人心敬請期待同仁查看可用，而且它們如何改善它就會夢見。我認為 RavenDB 是一個很好的範例，如此，您可以監看方式 Rahien 發展資料庫他夢如何使其更會繼續，或成為使用者所想到了這一點。

我相信這些資料庫的相關 intrigue 是受感染。我一定很期待進一步 digging，並進一步瞭解。但即使我已看過三種有趣很難選擇其中之一，因為目前，我正在解決好奇心問題並不是真實的商業問題，而關聯式資料庫之中合適的大小，我目前的專案之此 Libra。

鄭 Lerman 是 Microsoft 類似 MVP。NET 的指導和顧問居住在 Vermont 的山上去。您可以找到她在資料存取和其他 Microsoft 呈現。NET 主題，在使用者群組和世界各地的會議。在她部落格thedatafarm.com/blog是高度讚賞的活頁簿，「程式設計 Entity Framework 」 (O'Reilly 媒體，2010年) 的作者。她按照在 Twitter twitter.com/julielerman。

因為有到下列的技術專家來檢閱這份文件： Ted Neward 和Savas Parastatidis

資料點