database - school - nosql用途




為什麼我應該使用基於文檔的數據庫而不是關係數據庫? (4)

為什麼我應該使用像CouchDB這樣的基於文檔的數據庫,而不是使用關係數據庫。 在基於文檔的數據庫比關係數據庫更適合的地方是否有典型的應用程序或域?


CouchDB(來自他們的website

  • 文檔數據庫服務器,可通過RESTful JSON API訪問。 通常,關係數據庫不能通過REST服務簡單訪問,但需要更複雜的SQL API。 通常這些API(JDBC,ODBC等)非常複雜。 REST很簡單。

  • 具有平面地址空間的Ad-hoc和無模式。 關係數據庫有復雜的,固定的模式。 您可以定義表格,列,索引,序列,視圖和其他內容。 沙發不需要這種複雜,昂貴,脆弱的高級計劃。

  • 分佈式,具有強大的增量複製和雙向衝突檢測和管理功能。 一些SQL商業產品提供這個功能。 由於SQL API和固定模式,這是複雜的,困難的和昂貴的。 對於沙發,它看起來簡單而便宜。

  • 支持查詢和索引功能,具有一個使用Javascript作為查詢語言的面向表格的報表引擎。 SQL和關係數據庫也是如此。 這裡沒有新東西。

所以。 為什麼CouchDB?

  • REST比JDBC或ODBC更簡單。
  • 沒有Schema比Schema簡單。
  • 分佈的方式看起來簡單而便宜。

可能你不應該:-)

第二個最明顯的答案是,如果你的數據不是關係型的,你應該使用它。 這通常表現為沒有簡單的方法將數據描述為一組列。 一個很好的例子就是您實際存儲紙質文檔的數據庫,例如掃描辦公室郵件。 數據是掃描的PDF,並且您有一些始終存在的元數據(掃描文檔類型,掃描文檔類型)和大量可能的元數據字段(客戶編號,供應商編號,訂單編號,保存文件直到, OCR全文等)。 通常情況下,您事先不知道您將在未來兩年內添加哪些元數據字段。 像CouchDB這樣的數據比關係型數據庫更好。

我個人也喜歡這樣一個事實,即除了HTTP客戶端之外,我不需要任何CouchDB客戶端庫,現在幾乎所有的編程語言都包含它。

可能最不明顯的答案是:如果您使用RDBMS感覺不到任何痛苦,請繼續使用它。 如果你總是需要為RDBMS工作以完成工作,那麼面向文檔的數據庫可能值得一看。

欲了解更詳細的清單,請查看Richard Jones的這篇文章


想到快速應用程序開發。

當我不斷發展我的模式時,我經常因為必須在MySQL / SQLite中維護模式而感到沮喪。 雖然我還沒有用CouchDB做過多的工作,但我確實很喜歡在RAD過程中演變架構的簡單性。

您可能不想使用非關係數據庫的情況是當您有很多多對多關係時; 我還沒有想到如何在這些類型的關係中創建好的MapReduce函數,特別是如果您需要在加入關係中使用元數據。 我不確定,但我不認為CouchDB Map函數可以調用他們自己的數據庫查詢,因為這可能會導致無限循環。


用於愚蠢地存儲和提供其他服務器數據。

在過去的幾個星期裡,我一直在玩一個lifestream應用程序,用於輪詢我的feed(美味,flickr,github,twitter ...)並將它們存儲在couchdb中。 couchdb的美妙之處在於它可以讓原始數據保持原有結構,無需額外開銷。 我為每個文檔添加了一個'class'字段,存儲了源服務器,並為每個源代碼編寫了一個javascript呈現類。

一般來說,無論何時您的服務器與另一台服務器進行通信,無模式存儲都是最好的,因為您無法控制模式。 作為獎勵,couchdb使用服務器和客戶端的本機協議 - 用於表示的JSON和用於傳輸的HTTP REST。





non-relational-database