在開發Web應用程序時，您將使用Graph數據庫還是使用Document數據庫？

Question

我正在開發一個使用Rails的基於Web的應用程序。我在使用圖形數據庫（如InfoGrid）或文檔數據庫（如MongoDB）之間爭論不休。

我的應用程序需要存儲一小部分數據（如URL）和非常大的數據集（如虛擬機）。這些數據將被綁定到單個用戶。

我有興趣學習關於Graph或Document數據庫的人們的經驗，以及他們爲什麼會使用任一選項。

謝謝

Answer 1

，我不覺得有足夠的與兩個世界經歷了正確和完全回答你的問題，但是我用了一段時間的文檔數據庫這裏有一些個人的提示。

文檔數據庫基於鍵，值和靜態視圖的概念，對於查找一組具有特定值的文檔非常酷。

他們不概念化文件之間的關係。因此，如果您的軟件必須提供高級的「查詢」，其中選擇標準對幾種「文檔類型」起作用，或者您只需使用多個元素執行選擇，則[鍵，值]概念不合適。

也有一些其他的情況下，文檔數據庫是不合適的：在「分頁」表呈現大型數據集，幾列排序是哪裏的演出是低和磁盤空間使用是巨大案例之一。

因此，在許多情況下，您將不得不執行「服務器端」處理以獲取部分內容，並使用rails或任何其他基於ruby的框架，您可能會遇到性能問題。

圖數據庫基於tripplestore的概念，這意味着它們也概念化實體之間的關係。

該圖可以使用關係（和實體角色）遍歷，並且在跨關係結構化數據執行搜索時可能更方便。

因爲我沒有圖形數據庫的經驗，我不知道圖形數據庫是否可以很容易地查詢/遍歷幾個標準，但是如果一個建議的讀者有這樣的信息，我真的很感謝這樣的例子查詢/遍歷。

目前，我正在閱讀有關InfoGrid並試圖弄清楚，如果這樣的數據庫可以通過方便的，以一個非常大的數據集執行復雜的要求，關係包括....

從我可以讀，InfoGrah應被視爲能夠搜索/挖掘來自多個來源（商店）的數據聯合者，這些來源也可以是Mongo等NoSQL數據庫。

至極意味着你可以使用一個蒙戈商店進行數據檢索更新和InfoGraph和也許做足了大量的CPU和磁盤的，當涉及到複雜的搜索中的NoSQL數據庫中。

當然，如果您的應用程序只是在數據庫中存儲大量龐大的二進制文件，並且您只需執行簡單的密鑰查詢並檢索結果，那麼它看起來有點「過度」。在那個數據庫中，mongo或沙發等nosql數據庫可能會很方便。

希望一些這有助於;）

Answer 2

當邊緣連接相關的文檔，你會得到一個淺或深圖？我認爲，在決定graphdbs和documentdbs之間時，這個問題的答案很重要。請參閱Jim Webber的Square Pegs and Round Holes in the NOSQL World，瞭解這方面的想法。