請教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的分片是相同的,使用者一樣無感。