什么是 CouchDB？
CouchDB 是一個開源的面向文檔的數據庫管理系統，可以通過 RESTful JavaScript Object Notation (JSON) API 訪問。術語 “Couch” 是 “Cluster Of Unreliable Commodity Hardware” 的首字母縮寫，它反映了 CouchDB 的目標具有高度可伸縮性，提供了高可用性和高可靠性，即使運行在容易出現故障的硬件上也是如此。CouchDB 最初是用 C++ 編寫的，但在 2008 年 4 月，這個項目轉移到 Erlang OTP 平臺進行容錯測試。
CouchDB 可以安裝在大部分 POSIX 系統上，包括 Linux® 和 Mac OS X。盡管目前還不正式支持 Windows®，但現在已經著手編寫 Windows 平臺的非官方二進制安裝程序。CouchDB 可以從源文件安裝，也可以使用包管理器安裝（比如在 Mac OS X 上使用 MacPorts）。
CouchDB 是一個頂級 Apache Software Foundation 開源項目，根據 Apache 許可 V2.0 發布。這個開源許可允許在其他軟件中使用這些源代碼，并根據需要進行修改，但前提是遵從版權需知和免責聲明。與許多其他開源許可一樣，這個許可允許用戶根據需求使用、修改和分發該軟件。不一定由同一個許可包含所有修改，因為我們僅維護一個 Apache 代碼使用許可需知。
回頁首
面向文檔的數據庫和關系數據庫之間的區別
對很多人而言，剛接觸面向文檔數據庫管理系統這個概念時很難理解它，尤其是長期與關系數據庫打交道的人員。這是因為這兩個模型相似的地方很少。
顧名思義，面向文檔數據庫是由一系列自包含的文檔組成的。這意味著相關文檔的所有數據都儲存在該文檔中 — 而不是關系數據庫的關系表中。事實上，面向文檔的數據庫中根本不存在表、行、列或關系。這意味著它們是與模式無關的；不需要在實際使用數據庫之前定義嚴格的模式。如果某個文檔需要添加一個新字段，它僅需包含該字段，從而不影響到數據庫中的其他文檔。因此，文檔不必為沒有值的字段儲存空數據值。
即將推出的書 CouchDB: The Definitive Guide（見 參考資料）使用名片作為 “現實的文檔”，并介紹了與關系數據庫相比，如何在面向文檔的數據庫中描述它。在關系數據庫中，您需要使用 4 個以上的表來儲存這些數據：一個 “Person” 表、一個 “Company” 表、一個 “Contact Details” 表和一個用于儲存名片本身的表。這些表都有嚴格定義的列和鍵，并且使用一系列的連接（join）組裝數據。
雖然這樣做的優勢是每段數據都有一個惟一真實的版本，但這為以后的修改帶來不便。此外，也不能修改其中的記錄以用于不同的環境。例如，一個人可能有傳真號碼，而另一個人沒有。在名片上不應該顯示 “傳真：沒有”，而是忽略任何關于傳真的細節。
在面向文檔的數據庫中，每個名片都儲存在各自的文檔中，并且每個文檔都可以定義它需要使用的字段。因此，對于沒有傳真號碼的人而言，就不需要定義傳真的值，而對于有傳真號碼的人，則根據他們的意愿定義該值。
這兩種數據庫的另一個不同點是惟一標識符的儲存。在關系數據庫中通�？梢允褂弥麈I，它由一個自動遞增特性或序列生成器生成。當然，這些標識符僅相對于所使用的表或數據庫是惟一的 — 其他表或數據庫還可以使用它們。如果同時對不同網絡上的兩個數據庫執行更新操作，這兩個數據庫不會同時準確地獲取下一個惟一標識符。CouchDB 沒有自動遞增或序列特性。相反，它為每個文檔分配一個通用惟一標識符（Universally Unique Identifier，UUID），這就杜絕了其他數據庫意外地選擇相同的惟一標識符的情況。
面向文檔數據庫和關系數據庫的另一個重要區別就是面向文檔數據庫不支持連接。因此 CouchDB 中沒有主鍵和外鍵，沒有基于連接的鍵。這并不意味著不能從 CouchDB 數據庫獲取一組關系數據。一個稱為視圖的特性允許您為沒有在數據庫中定義的文檔創建一種任意關系。這意味著您能夠獲得典型的 SQL 聯合查詢的所有好處，但又不需要在數據庫層預定義它們的關系。
一定要注意，雖然面向文檔數據庫的操作方式不同于關系數據庫，但這并不意味著它們是可以替換的。CouchDB 的目的并不是替換關系數據庫，而是為那些更適合使用面向文檔模型（而不是傳統的關系數據模型）的項目提供一種選擇，比如 wikis、博客和文檔管理系統。
回頁首
CouchDB 是如何工作的？
CouchDB 構建在強大的 B-樹儲存引擎之上。這種引擎負責對 CouchDB 中的數據進行排序，并提供一種能夠在對數均攤時間內執行搜索、插入和刪除操作的機制。CouchDB 將這個引擎用于所有內部數據、文檔和視圖。
因為 CouchDB 數據庫的結構獨立于模式，所以它依賴于使用視圖創建文檔之間的任意關系，以及提供聚合和報告特性。使用 Map/Reduce 計算這些視圖的結果，Map/Reduce 是一種使用分布式計算來處理和生成大型數據集的模型。Map/Reduce 模型由 Google 引入，可分為 Map 和 Reduce 兩個步驟。在 Map 步驟中，由主節點接收文檔并將問題劃分為多個子問題。然后將這些子問題發布給工作節點，由它處理后再將結果返回給主節點。在 Reduce 步驟，主節點接收來自工作節點的結果并合并它們，以獲得能夠解決最初問題的總體結果和答案。
CouchDB 中的 Map/Reduce 特性生成鍵/值對，CouchDB 將它們插入到 B-樹引擎中并根據它們的鍵進行排序。這就能通過鍵進行高效查找，并且提高 B-樹中的操作的性能。此外，這還意味著可以在多個節點上對數據進行分區，而不需要單獨查詢每個節點。
傳統的關系數據庫管理系統有時使用鎖來管理并發性，從而防止其他客戶機訪問某個客戶機正在更新的數據。這就防止多個客戶機同時更改相同的數據，但對于多個客戶機同時使用一個系統的情況，數據庫在確定哪個客戶機應該接收鎖并維護鎖隊列的次序時會遇到困難，這很常見。在 CouchDB 中沒有鎖機制，它使用的是多版本并發性控制（Multiversion concurrency controlMVCC）— 它向每個客戶機提供數據庫的最新版本的快照。這意味著在提交事務之前，其他用戶不能看到更改。許多現代數據庫開始從鎖機制前移到 MVCC，包括 Oracle（V7 之后）和 Microsoft® SQL Server 2005 及更新版本。
文章來源于領測軟件測試網 http://www.k11sc111.com/
