贊助廠商

娛樂城推薦

首頁

刊登資訊

  • 刊登者:匿名
  • 時間:2021-06-02 18:10:01

尚未解答資料庫- 正規化的時機點

資料庫- 正規化的時機點

各位先進們好
我手邊有一個資料庫, 資料的層級比較多, 切成數個表單1對多的關係

比如
Tier1: ~700 rows
Tier2: Tier1 per row x 800 ~ 560k rows
Tier3-1,3-2,3-3: Tier2 per row x 20 ~ 各自1.1M rows

平常探勘資料是著重在 Tier1大約取5~8個rows, 再往下join, 拉出資料進行探勘

其中
Tier3-1的表大致有1個欄位會變動, 其它8個欄位有相依
Tier3-2的表有2個欄位會變動, 其它4個欄位有相依
Tier3-3的表只有1個欄位, 但是週期性重覆, 也就是內容是有限的集合

我在考慮是不是做了正規化會讓整個儲存的效率變好
但是有幾個問題查了資料之後還是沒有解決, 還請先進們幫忙解惑

這個資料平台的資料是從binary的檔案stream來的

CaseA.
如果要正規化, 是stream的時候就要先做正規化嗎?
但streaming的過程中,
資料一卡車來的時候並不知道原先資料庫有哪些已存在的項目

比如說Tier3-3
使用了composition key(含Tier1, Tier2的index)以方便data slicing,
從Mega rows中要找出數千行有關的資料效率還不錯.
單一個資料欄位可能出現log1, log2, log3,..... log10 (都是很長的log)
寫成下面的樣子
rowN index1, index2, log1
rowN+1 index1, index2, log2
原表正規化為
rowN index1, index2, result1
rowN+1 index1, index2, result2
產生一個新表
result1 log1
result2 log2

data streaming的過程中可能會出現新的log11, log12...等等
不常見但隨時間推進有可能發生

有幾個做法:

1. data streaming的程式不要動, 按照原樣倒進Tier3-3的表
然後把Tier3-3正規化做成 Tier3-3-1(原表正規化), 與Tier3-3-2(新表記log)
再把Tier3-3清空
Tier3-3就改為新進資料的暫存區

2. data streaming的程式也要動,
程式必需要參照已有的Tier3-3-2內容, 把新加入的資料拆表之後,
再各自匯入Tier3-3-1與Tier3-3-2
(這樣每次匯入都會有幾千行的log, 都要進行比對不是也很耗時嗎?)


實務上的正規化是做在資料匯入之前, 還是匯入之後才做二次清洗呢?

這個binary的data其實有4個層級,
index的工作都是stream時加上去的
如果正規化也要做在stream裡, import的工作似乎就太複雜了
要做index, 還要跟現存的資料進行比對,
把新型態的資料補充進去, 再移除相關的column
原本方式是: stream data -> DB connection -> append
新的方式是:
DB connection -> get Tier3-3-2 --> stream data --> compare
--> normalize --> append

還是資料已經有大略的架構, 能倒進去就倒進去, 正規化是有API在幫忙處理的?

我目前是使用sqlite3在做小規模的資料分析, 資料庫大概70GB左右
覺得最麻煩的就是Tier1對應到不定長度的Tier2, Tier2也有不定長度的Tier3組合.
在資料量最多的Tier3有Normalize的可能性

如果我這樣的data slicing不是很好的做法. 也歡迎鞭笞指教, 感謝.

--

0個答案 資料庫- 正規化的時機點

其他問題

友站連結