單機是最好的架構之二資料同步

自己原文公眾號： https://mp.weixin.qq.com/s/cULhj5HFhYvjINZrDfjOoQ

這篇我主要是針對分庫分表、微服務和煙囪建設等說的。

      我以前做公安行業的，人車管控。比如一輛車開過一個路口或者一個路段，被監控裝置抓拍。那就是一條資料（含圖片）。早期資料不多併發不高的時候我們圖片是存資料庫的。每秒100的併發寫入問題不大。後期資料也多了平臺也大了，為了緩解資料庫壓力，圖片另外存，url連線存在資料庫中。每秒上千寫入問題也不大。連快取都不用，單機穩穩的。每個專案資料10億級別起，最大的專案單表100億，資料庫容量可大100TB。以前我一直覺得我這個可以了。但是有一次平安公司的說他們核心庫，一級庫，300TB。果然天外有天。以上主要為了說明單機資料庫足以應付絕大多數應用場景。

      那如果不是單機呢？煙囪建設不是不可以，大家井水不犯河水。不過一旦設計到各個資料庫說要做彙總，或者資料做互動，這就麻煩了。假設ABCDE五個專案每個專案至少用了一個資料庫。這些資料庫所承載的業務有上下游或者前後關係。A要給B一些，也不知道B有沒有，開發一個程式一股腦兒給幾萬資料到B，B系統要一個個核對。C要向A要資料（和之前A給B不一樣），C怕少要了，就請求了更大範圍的。  D要彙總資料，但是怎麼知道ABC上的資料呢？用etl去select。

      問題來了，怎麼知道資料新增的呢？需要新增資料有時間戳。對於沒有時間戳的系統就要進行改造。找得到人還有希望，找不到開發方或者這個是採購來的產品無法改造就麻煩了。如果資料只是增加還好說，更多的是資料修改，一個表的10個欄位改了1個，D首先要知道哪些是改了的，然後要把這些資料拿過來再對比才能知道哪個變了。其實如果在原始資料庫上其實不關心修改之前是什麼樣子，只關注當前狀態。但是etl就不知道。而且etl不能實時（每秒一次）獲取，必須定時，否則ABC系統受不了。最可怕的事情還沒說，那就是有時候源端還有可能del。這etl根本找不到了。

     如果說都是同構比如說Oracle，還有辦法，最簡單的是dblink+物化檢視。定時重新整理。優點：                   缺點：

資料一致性可以保證；                   不宜過多表

準實時；                                       不宜太頻繁，不建議小於1min

免費；                                           建立好以後源端不能加欄位，否則要重做

資料不用去做對比；                       大表建立物化檢視時間較長

相對etl壓力較低                            長時間中斷物化檢視，可能要重建

       有些資料庫沒有dblink以上就沒法做，但是可以透過其他方式比如mysql和pg都有歸檔日誌，解析這些歸檔日誌就可以做到。但是異構資料庫太多了需要全部都去處理。還有SQLSERVER db2等等。

      我最近嘗試OGG的功能，最早OGG是隻能oracle到oracle。現在的ogg的架構是：

實測了一下，源庫MYSQL5.7  MySQL8  Oracle19C（PDB ）模式。目標端Oracle19C（PDB）模式。

目標端使用Oracle的原因

MySQL5.7 雖然自帶快取，但是寫操作後快取失效.下圖是5.7

MySQL 8 進一步定位MySQL作為OLTP系統，取消了快取結果集。MySQL單機版基本放棄分析功能。只有雲版支援OLAP。（大家可以去看看甲骨文雲版的MYSQL最近一直在推）分析場景不推薦使用MySQL8。下圖是8

Oracle 單表億級別資料，分析在秒以下。實時計算，沒有快取。主要是因為她是行列混存。應用透明。

業內所有資料同步方案都存在瑕疵， OGG 方案是所有方案中最透明（業內使用人最多，可以較好的獲得支援和定位問題），中間過程一目瞭然。