在大型數據庫中實現性能和可伸縮性之間的適當平衡

Question

我試圖確定哪個數據庫模型最能支持概率記錄比較。具體來說，我有大約2000萬個由各種屬性（名稱，類型，作者，所有者等）定義的文檔。文本屬性支配數據集，但仍有大量圖像。閱讀操作是最重要的可見性能，但我預計每週將插入大約20,000個新文檔。幸運的是，插入速度根本無關緊要，我很樂意將傳入的文檔排隊以進行受控處理。

數據庫查詢將最通常採取以下形式：

• Find documents containing at least five sentences that reference someone who'a a member of the military
• Predict whether User A will comment on a specific document written by User B, given User A's entire comment history
• Predict an author for Document X by comparing vocabulary, word ordering, sentence structure, and concept flow

我首先想到的是使用一個簡單的document store喜歡，喜歡MongoDB，因爲每個文件不一定包含相同的數據。然而，複雜的查詢有效地將其降級​​到文件系統包裝器，因爲我無法構造一個能夠產生我想要的結果的查詢。因此，這種方法讓我步入整個數據庫並分別處理每個文件。儘管文檔商店橫向擴展性好，但這裏並沒有實現好處。

這使我意識到，我的粒度不在文檔級別，而是實體關係水平。因此，graph databases似乎是合乎邏輯的選擇，因爲它們便於將句子中的每個單詞與下一個單詞，下一個段落，當前段落，詞類等相關聯。圖形數據庫限制了數據複製，增加了統計聚類的速度，水平，等等。不幸的是，確保查詢的明確答案仍然需要遍歷整個圖。即使如此，索引將有助於表現。

我也評估過關係數據庫的使用，這些數據庫在設計正確時（即避免不必要的規範化）非常有效。關係數據庫擅長查找由用戶A創作的所有文檔，但在結構性比較（涉及昂貴的聯接）時失敗。關係數據庫還有效地強制約束（主鍵，外鍵，唯一性等） - 一些NoSQL解決方案所面臨的任務。

考慮以上列出的要求之後，是否有結合了關係模型的「正確性」任何數據庫模型（即，域的高效耗盡）與圖形數據庫的靈活性？

Answer 1

這不是一個真正的答案，只是一個討論。

您正在談論的數據庫是一個大型數據庫。您沒有提及這些文檔的性質，但報紙文章通常在2-3k範圍內，因此您正在談論數百GB的原始數據。

如果查詢性能是一個問題，那麼您正在談論一個龐大而相當昂貴的系統。

您的要求也相當複雜，不太可能是開箱即用的。我會想到一個混合動力系統。將文檔元數據存儲在關係數據庫系統中，以便用簡單的查詢快速訪問它們。您可以將文檔本身作爲斑點存儲在數據庫中。

您的一些要求可以通過在關係數據庫中添加文本來滿足。所以，使用倒排索引技術簡單搜索是可行的。這將處理您的三種情況中的第一種。

其他兩個更具挑戰性。第三種（「預測作者」）可能可以通過一個並行系統來處理，該系統存儲作者信息，並在加載時從文檔中總結出來。那麼這是一個使用簡單的統計分析（樸素貝葉斯，任何人？）比較文檔和作者的問題。

中間一個很棘手，但它表明管理文檔評論的另一個組件。根據音量，這可能很容易或很難。

最後，需求如何變化？你真的知道系統應該做什麼嗎？或者一旦你啓動並運行，功能會有根本的不同？