物化檢視實現的特殊資料複製(r11筆記第42天)

  今天開發同事碰到一個有些複雜的資料複製需求，想讓我幫忙看看能否實現，當然猛一聽需求是不可能實現的。不過還是耐著性子和他們討論了一下，不過我想了下，似乎還是有改進的餘地，也算是撥雲見霧吧。

  目前有一個表做了拆分，即分庫分表。在統計業務中還是需要把資料整合起來查詢。大體就是下面的架構方式。

源端是一些分庫，存在一些不同的使用者，裡面存放著相同結構的表。資料根據拆分規則進入不同的分庫。

目標端是統計業務所用，沒有使用OGG,而直接使用物化檢視的方式做了資料重新整理複製，當然目標端由此就有了相同數量的物化檢視，為了讓應用端查取方便，於是建立了一個同名的檢視，這樣就達到了一個基本的資料拆分到整合的過程。

但是資料有一些問題。假設表中存在下面的欄位，那麼其中一個欄位modify_date就是資料記錄的修改時間戳。

應用端可以根據這個時間戳來進行資料的統計分析，而且目前來看只有增加和部分修改，沒有刪除操作，但是恰恰不如意的是，這個欄位因為不同產品的期望，目前是可為空的，而對於統計業務來說又是必須的。

對於統計業務來說，不會可以關注精確的時分秒，精確到日即可。於是我們就有了一些討論。

開發同學

有個疑惑，BI這邊是今天取昨天的增量資料，假設今天取資料的時候出錯了，過了幾天我想修復歷史資料，還能知道前天增加了哪些資料嗎？

goldengate也是使用主鍵嗎

DBA:

這是兩個問題，如果取數的時候出錯了，按照目前的資料一致性，那麼剩下沒有應用到的資料是肯定不會應用到目標庫的，所以資料層面的修復是平滑的。 

第二個是檢視之前增加的歷史資料，Oracle有些輔助功能可以實現，不過得看你的需求，不一定能完全實現。

開發同學：

就像現在這個資料，很多modify_date是空的，我們就很想知道2008年01月01日的增量資料

就是每一天的增量，好實現嗎？

DBA：

你說的增量是新增的還是修改的也算，新增的那就簡單了，可以用分割槽，如果是修改的，這個還比較麻煩。

那樣得確認一點

比如1月1日 新增了100條資料

1月5日，新增了200條資料，

同是修改了1月1日的2條資料。

那這兩條資料是算在1月1日還是算在1月5日。

開發同學：

恩·是這個問題，算1月5日的

因為BI這邊會按這個時間建分割槽，雖然1月1日的分割槽裡也有這條資料，但是不會導致丟失，這邊可以取最新的使用

DBA:

對，按照時間建分割槽，分割槽設定上做一些特定的設定，可以的。(其實就是開啟row movement,可以跨分割槽更新)

但是想起來思路是通，但是這就有兩個大問題需要解決了。目標是物化檢視重新整理，因為物化檢視是隻讀的，如何修改modify_date的值就是個大問題。

如何得到這些增量變化的資料，目前來看，時間的部分只能依賴於系統時間了。但是增量的資料如何鑑別，我一個設想就是根據modify_date來分割槽。

這樣一來，架構方式就是如下的形式：

根據分割槽的方式，資料就能夠區分開來了。但是增量的資料如何鑑別，這是個很實際的問題，這個時候我們就可以聯絡一些更具體的資訊了，那就是物化檢視日誌，在源端，每個表開啟增量重新整理，必然要建立一個物化檢視日誌，這個物化檢視日誌裡面的資料說不上完整，但是有主鍵ID和基本的時間戳，這就夠了。我們可以在增量重新整理之前得到一個基本的id列表，然後關聯分割槽的方式修改資料為系統時間，這樣一來，資料就會從預設分割槽流動到指定的分割槽中。後續供統計分析所用。

看起來不大可能的需求還是有一些的應用場景，估且算是一個特殊的重新整理場景吧。

個人微信公眾號如下，歡迎掃描關注。