NoSQL或RDBMS用於審計數據

Question

我知道在該主題中提出了類似的問題，但我仍然沒有看到任何完全包含我所有請求的人。

我會開始說我只有RDBMS的經驗，所以我很抱歉，如果我得到關於NoSQL的任何錯誤。

我正在創建一個可以容納大量審計日誌（大約1TB）的數據庫。

我使用它：

1. 快速數據寫入（審計日誌的巨量寫入所有的時間）

2. 搜索 - 進行了審計數據搜索（搜索行動由某個用戶在某個時間或某個動作...數據庫應支持搜索任何'列'非常快）

3. 分析&報告 - 生成每日，每週，每月報告數據（這些都在一瞬間預定義。如果他們更有活力，它影響的解決方案，我應該選擇？）

可靠性，可擴展性（故障切換，或任何類似的功能支持）（如果我增長到1TB以上到2TB，10TB或100TB - 是否有任何解決方案不能支持這一數據量？），當然性能（在我指定的用例中）對我來說非常重要。

我知道RDBMS，這將是我開始的簡單方法，但我真的擔心，過了一段時間，數據庫根本無法跟上節奏。

我的問題是我應該選擇一個RDBMS或NoSQL解決方案，爲什麼？如果NoSQL解決方案因爲它們如此不同，您認爲哪些解決方案符合我的需求？

Answer 1

通常在這裏沒有正確或錯誤的答案。

快速數據寫入，無論哪種解決方案都可以，儘管您沒有說每秒存儲多少音量。兩種解決方案都有一些需要注意的事項。

搜索（非常快）所有列。對於較小的體積，比如說幾百Gb，那麼任何一種解決方案都會好（假設熟練的人將它們放在一起）。你實際上並沒有說你的搜索速度有多快，所以如果每分鐘多次這個考慮就變得更重要。快速搜索通常會減慢快速編寫大量數據的能力，因爲需要更新搜索所需的索引。

審計記錄通常具有時間分量，因此搜索時間受到限制，例如最近7天內的搜索，與搜索所有記錄相比，搜索次數會顯着加快。

舉報。當你達到100TB時，你需要一些真正的技巧或者大的預算來獲得快速的報告。對於靜態報告，您最終可能會創建一個程序來同時生成多個報告以節省I/O。動態報告將是一個棘手的問題。

我的看法？既然你知道RDBMS，我會以此爲開始，並提供解決方案。這會讓你花時間學習你將遇到的真正問題（沒有任何過早的優化，許多人都熱衷於此）。在此初始時間段內，您可以開始選擇nosql解決方案並進行學習。我假設你想要運行你自己的硬件/數據庫，如果你想使用雲類型解決方案，那麼馬上去找他們。