ORACLE物化視圖怎么解決CMS數(shù)據(jù)同步與來不及的DATA PIPLELINE

這篇文章給大家介紹ORACLE物化視圖怎么解決CMS數(shù)據(jù)同步與來不及的DATA PIPLELINE，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

為啥要牽扯僅DataPiple Line, 因為如果有DataPipe Line,我下面的故事就不用寫了。所以一項新技術(shù)和軟件的開發(fā)可以解決不少頭疼的問題。那下面就先來看看問題。

人有多少想法，其實就有能滿足你需求的東西，例如Dta Pipleline ,它能解決的問題我現(xiàn)在就能想到幾個

1 異構(gòu)數(shù)據(jù)庫的灰度發(fā)布，更換數(shù)據(jù)庫系統(tǒng)的麻煩事就可以通過這個數(shù)據(jù)管道系統(tǒng)解決。

2 大數(shù)據(jù)的實時分析。

3 數(shù)據(jù)同步與單庫對多庫數(shù)據(jù)下發(fā)，并能解決可能出現(xiàn)的性能問題。

4 生產(chǎn)庫到測試庫的數(shù)據(jù)脫敏與數(shù)據(jù)實時同步

當(dāng)然還有他本身的功能，數(shù)據(jù)管道。

故事是開始最近由于要拆分原有ORACLE數(shù)據(jù)庫的部分功能，到MYSQL上，需要數(shù)據(jù)同步，數(shù)據(jù)庫同步方法很多，但找到一個合適的確不容易，不是技術(shù)上困難，而是方法太多，可能會有選擇恐懼癥。而且我發(fā)現(xiàn)一個問題，就是怎么想都是簡單的事情，到真做的時候，就變得不那么單純了，各種問題出現(xiàn)，其實干了這么多年，大風(fēng)浪還是見過的，所以一直不敢說，這個沒問題，那個很一般，這個一定能行（當(dāng)然打氣，鼓勵別人或自己的時候，還是要說的）。

任何一項技術(shù)的使用其實都要根據(jù)業(yè)務(wù)來決定，單純從技術(shù)出發(fā)的方式來決定某項技術(shù)的使用，嗯......    這次的任務(wù)的一開始其實想的很簡單，就是使用Kettle 來進行數(shù)據(jù)的抽取從ORACLE 到 MYSQL ，而問題既不在KETTLE 也不在數(shù)據(jù)庫的層面，問題的發(fā)生還是在非技術(shù)的層面，問題的在對CMS 系統(tǒng)的某些表的數(shù)據(jù)更改的觸發(fā)點還不清楚，而如果以不清楚的方式來面對如何撰寫相關(guān)的提取語句，則這樣的結(jié)果就會引起一個關(guān)聯(lián)的效應(yīng)， 1 由于抽取數(shù)據(jù)的變化點無法找到，所以提取數(shù)據(jù)的點就無法找到，2 無法找到點，則就無法進行SQL語句的增量的提取 3 無法增量提取數(shù)據(jù)，開發(fā)的同學(xué)就無法獲取正確的數(shù)據(jù) 4  無法有正確的數(shù)據(jù)則整個項目就要出現(xiàn)問題， 連鎖反應(yīng)。

解決問題從來不缺技術(shù)的方案，而是缺靠譜的和穩(wěn)定的方案，所以一個方案的出臺，尤其是一個沒有嘗試過的方案，則困難的程度和失敗的可能性都是有的。我們一定要找到一個能從，業(yè)務(wù)，開發(fā)，運維，三方能都承受和認(rèn)可的方案來進行方案的確定。

既然是某些取數(shù)的點和數(shù)據(jù)的變化還吃不準(zhǔn)，怎么通過技術(shù)的手段讓變化能被捕捉到，方法很多。

最近我們在開始測試 DATA  PIPLELINE  如果通過DATA PIPLELINE 來做這個數(shù)據(jù)同步方案，其實事情將變得簡單的多，首先是從底層來進行數(shù)據(jù)的抽取，同時也能定期的進行刷新等等，所以O(shè)RACLE 到 MYSQL 數(shù)據(jù)的流就像打開水龍頭那么簡單，數(shù)據(jù)和水一樣要來就來，要關(guān)就關(guān)。當(dāng)然有了DATAPIPLE LINE 我們的KETTLE 一大部分的功能都可以不再使用。

但好事其實都需要等，項目不會等，目前的需求還是得傳統(tǒng)的方式獲得變化的數(shù)據(jù)，并且在一個時間點，這就想到了 物化視圖，通過物化視圖  ON DEMAND  + 時間點的方式，我們就可以很方便的知道我們關(guān)切的表在一天當(dāng)中數(shù)據(jù)的變化情況。

說道物化視圖，ORACLE 還是傳統(tǒng)數(shù)據(jù)庫里面最強悍的，其他的都沒有ORACLE 來的功能多，方式多，所以各個數(shù)據(jù)庫其實也應(yīng)該學(xué)習(xí)，SQL SERVER 就在2016 搞出了一個 temporal Table,  雖然可以搞定部分問題，但本身對并發(fā)時的事務(wù)的BUG 也絕對夠繁忙的系統(tǒng)喝一壺。

話歸整體ORACLE 怎么能滿足我們本次KETTLE 的數(shù)據(jù)物理的方式提取方式。

首先CMS 系統(tǒng)所在的ORACLE 需要將需要復(fù)制的表，建立物化視圖，并且建立物化視圖的日志。并且要求是表和物化視圖都應(yīng)該有 primary  key，否則就要考慮其他的方法了。

貌似問題好像解決了，但其實出其不意的問題就在你覺得沒有問題的時候發(fā)生了。

我們是通過 MLOG$_CMS_TEST  里面的ID

來進行判斷數(shù)據(jù)是否為增量。

那問題就來了，

問題

1 數(shù)據(jù)在操作過程中，會有 I U D 三類的操作，但如果是D 則這條數(shù)據(jù)應(yīng)該是被清除了，所以我們在復(fù)制的過程中，應(yīng)該從我們的復(fù)制的語句中剔除這個ID。

2  那解決這個問題就用下面的語句，直接將已經(jīng)刪除的記錄濾除，存在的只有 insert 和 update 兩種語句，那問題貌似解決了，其實呢

 3 實際上，沒有，如果這時我在插入數(shù)據(jù)，因為按照主鍵的方式，則我還插入原來的已經(jīng)刪除的主鍵，則上面的語句就會出錯，因為新插入的數(shù)據(jù)被過濾了。

所以忽略業(yè)務(wù)的方案都不大是一個穩(wěn)重的方案，這里假設(shè)刪除的數(shù)據(jù)不會再會補，并且也不會按照原來的主鍵進行插入。那上面的方案就不會有問題，否則還有漏洞。

最后，我還是期待用新技術(shù)來將某些業(yè)務(wù)中問題解決掉，快速，安全，穩(wěn)定，例如我期待的 Data Pipleline 能增加 postgresql 目的端的功能，則那些期待從Oracle ,sql server ,轉(zhuǎn)移到Postgresql 的項目人員的頭發(fā)還能茂盛更長一段時間。

關(guān)于ORACLE物化視圖怎么解決CMS數(shù)據(jù)同步與來不及的DATA PIPLELINE就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。