看板
[ Database ]
討論串[SQL ] 大量LOG記錄架構選擇
共 5 篇文章
內容預覽:
1. 大量LOG寫入,最常用的方式是檔案檔紀錄,採sequence write.. 2. LOG資料量不大,可採用NOSQL. 記住不要建索引,要有insert 1TB資料,資料庫會使用1.4TB的心理準備(看你怎麼存). 3. Log 查詢 DB, 只存Meta DATA. Input -> mi
(還有91個字)
內容預覽:
用回的好了... 你的做法很好,但是我建議可以全部放在同一個Log檔案. 每天log rotate一次並且壓縮. 編碼可以用. user_id, metric1, metric2, ..... 這樣的好處是你的App不用開太多檔案. 再來就是也比較方便將來分析統計. csv(或是tsv)的好處是很多
(還有91個字)
內容預覽:
不知道你的Log是什麼樣的Log. 使用者行為?. 還有你打算怎麼查詢?. 通常這種Log或是稱為Raw Log. 不太適合放在資料庫太久. 頂多一週了不起. 你應該可以把他從Raw Log轉成Aggregated Data. 例如如果你想提供查pageview. 可以根據你想查詢的分類每個小時算個
(還有439個字)
內容預覽:
資料庫名稱:MSSQL / MYSQL. 資料庫版本:2014 / 5.5.22. 內容/問題描述:. 其實還在架構選擇中. 就是目前有個需求是要記錄每個USER每秒產生的一筆LOG. 如果是這樣. worst case 就是一個user 一天要產出86400筆記錄. 有1000個user 的話不就
(還有198個字)