履帶式/鏟運機的數據庫？

Question

我目前正在研究哪些數據庫用於我正在進行的項目。希望你們能給我一些提示。

該項目是一個自動化的網絡爬蟲，根據用戶的請求檢查網站，在特定情況下抓取數據，並創建完成的日誌文件。

要求：

• 只有幾列幾桌;預定義的列是沒有問題的模型之間
• 沒有過於複雜的關聯
• 巨大的日用量以&時間查詢
• 由於日誌，數據庫將快速增長，並佔用大量的空間
• 應該能比例在多個服務器
• 字段包含大多IDS（INT），字符串（約200-500個字符max）和UNIX時間戳
• 兩種不同類型的服務器將同時讀/寫數據直接向/從它：
  • 一個（/後來更多）軌道應用程序，根據請求提供用戶輸入並顯示結果
  • 一個（/更多）更多的Node.js服務器，用作執行爬行器/刮板。它將有足夠的負載連續運行，並且每秒都會產生數十個數據庫查詢。

我認爲它不會流於圖形數據庫（沒有複雜的關聯），也不是基於內存的鍵/值存儲（太多的數據在緩存持有）。對於我能找到的任何其他類型的數據庫，我仍然處於困境，每個數據庫似乎都有其優點。

那麼，從專業人士的任何意見我應該如何決定？

謝謝。

Answer 1

我將與普京同意你想考慮此方案基於文檔的數據庫。我對MongoDB最爲熟悉。我在這裏使用它的原因如下：

1. 「只有少數幾列的表」的'模式要求'很適合MongoDB的NoSQL性質。
2. 與上述「節點之間不存在過於複雜的關聯」相同 - 您需要決定是選擇嵌套文檔還是使用dbref（我更喜歡前者）
3. 大量的基於時間的數據（和其他擴展需求） - MongoDB通過分片或分區很好地擴展
4. 讀/寫訪問 - 這就是爲什麼我推薦MongoDB比如Hadoop。交互式查詢要求最好通過除Hadoop式存儲以外的其他方式來滿足，因爲此類存儲設計用於批量（而不是交互式查詢）需求。

Answer 2

查看面向文檔的數據庫，如CouchDB或MongoDB。

Answer 3

Google建立了一個名爲「BigTable」的數據庫，用於抓取，索引和搜索相關業務。他們發佈了一篇關於它的文章（如果您有興趣，Google可以爲「BigTable」）。有幾種類似於bigtable的設計的開源實現，其中之一是Hypertable。我們有一篇博客文章，描述了sehrch.com中的人員撰寫的履帶/索引器實現（http://hypertable.com/blog/sehrchcom_a_structured_search_engine_powered_by_hypertable/）。並考慮您的要求：所有這些都得到支持，並且是常見的使用案例。

（免責聲明：我對Hypertable的工作）