請教LOG設計架構問題
-
Q: 請教LOG設計架構問題
存放 LOG 的資料量預期會很大(例:每分鐘10萬筆)，而且資料需要一直保存，想請教大家實務面怎麼設計會比較好
1. 存放同一個 Collection，例如: log
2. 拆分成多個 Collection 以年為單位，例如: log_2017、log_2018
3. 拆分成多個 Collection 以月為單位，例如: log_201703、log_201704
4. 拆分成多個 Collection 以天為單位，例如: log_20170301、log_20170302
5. 拆分成多個 Collection 以小時為單位，例如: log_2017030101、log_2017030102
-
我覺得拆分比較好，
除了 1 以外都可以像 MYSQL 有 Partition 設計，
可以把 table 切分成多個小檔案儲存，就跟拆分類似
不過我不知道 MongoDB 有沒有類似的，可能要請高手回答了
-
我找到 MongoDB 類似 Partition 的做法
https://docs.mongodb.com/v3.4/core/sharding-data-partitioning/
這樣是不是代表不需要手動拆分? 誰有用過的經驗嗎?
-
看起來是可以像mysql一樣直接設定切割邏輯，不過沒用過，等真正用過的人來解答。
-
短信平台之前對發送Log的做法是採取以天為單位的，一天的發送量大約是10萬~30萬不等
-
想請教以天為單位的話，開發上有遇到什麼狀況嗎? 例如: 想統計整個月的 log是不是會比較麻煩
以目前的需求每分鐘10萬筆的話，似乎切成小時為單位查詢起來效率會比較好，缺點是使用者介面上查詢條件比較受限
-
會選擇用mongoDB就是希望要在同一個collection~
分表放是RDBMS的解決方案之一，MongoDB的選擇是作"分片"，這作法對使用者無感~
如果是Log的話，長期不會再使用的數據可以考慮刪掉，或是指定轉移到特別的幾台分片保存~
-
用RDBMS也不需要分表喔，使用上面有人提到的partition做法，所有log放在同一個表中，但後端儲存自動切成不同的partition，其實應該就是跟MongoDB的分片是相同的，使用者一樣無感。
