**資料庫的有效性取決於幾個問題:

1. 讀取終端數
2. 寫入量
3. 讀取量
4. 資料量
5. 同步機器數
   X. 預算**
   當然無論是怎樣的資料庫的使用, 最後還是預算來決定一切, 甚至有些瓶頸是只靠機器是做不到的, 或者是有些邏輯上是必須選擇犧牲的, 以及是靠有效性來決定商業邏輯或使用者行為來改變資料流程.

通常可以調整資料庫的方法如下:

0. 商業邏輯(使用者)的製訂
1. 演算法流程
2. 程式語言的選擇
3. 程式的寫作
4. 資料庫的選擇
5. 資料庫的設定
6. 機器的選擇
7. 機器的設定

但這篇講的是實作面, 所以我來講一個經驗才對:

這是一個 Data warehouse 的設計, 希望在最低的預算能夠儲至少 10億 筆的歷史資料, 這歷史資料在某方面是種 Log, 但因為可能會有 Rollback 的可能性, Log 也會跟著 Rollback, 且必須不只儲存一份, 計算的時候每次最多只會抓 1 億筆的資料不會全部都抓.

資料來源不只一個, 通常會有 5~10 個 Storage Database 去整到 Data Warehouse, 幸運的事是這個 Table 是有 Increamental Primary Key 來依時間做 Serial 序號, 因此在某方面可以設計各自一套 Dataware House 各自運作, 其流程如下:

1. 用 Counter 來讀 Array 決定要去那個 DB 去抓資料回來.
2. 檢查 DW 此 Target DB 的最後一筆資料.
3. 建立連線選擇此最後一筆資料的序號依序往後抓, 然後儲存.
4. 結束連線, 增加 Counter, 回到第一項.

這看起來是相當簡單, 因為即使有多個 Data Warehouse, 尤於是每一個 DW 都是獨立運作, 不會有太大的問題, 且加上這個 Primary Key 是數字遞增, 且每一個 DB 都有編號來做 Index, 原本是設想一天在 20~50 萬筆的匯入, 在 SLA 定義只要存半年的情況下, 只要依月做 Rotate 就很足夠了.

但在 99.9% 以上都不會有問題, 但因為這在 Failover 中會有不一致的情型下會做 Mapping, 此時就非常有趣了.

當發生 Fail Over 時, Dispatcher 會跟 DW 說那些資料會有 Reschedule 要重 Mapping 或那些資料要刪除, 此時 Dispatcher 只要跟任何一台 Data Warehouse 說有那些工作, 此時 Data Warehouse 就記錄起來, 然後啟動一隻程式去執行, 問題是 Dispather 無法知道所有的 DW 的存在, 也沒必要, 幸而 DW 知道所有 DW 的存在, 他只要定時去看 Fail Over Log, 然後把自己不存在的 Log 抓回來, 然後照做一次.

1. 去所有其他 DW 看 Failover Log 有沒有新增, 若有的話全部抓回來.
2. 把新增的 Log 照須要執行的動作跑一遍, 完成同步.

上面這個流程我們會發現一點:

1. 因為若都是 Incremenatl 的資料, 我們可以把資料庫本身就當 Binary Log, 直接複製 Replication 就好.
2. 當發生須要更新的或刪除的時候, 我們就變成要把這動作產生像 Binary Log 的資料庫, 然後所有的資料庫都要做一次, 就可以達到同步.

上面的實作是靠 Runtime 與 Storage Database 為 Pgsql, 是用 Transaction Log 的方式, 因為量不大不會造成問題, Failover 的資料庫是存在 memcache 的 NOSQL, 用的是 Key Value 的方式達到速率可以很快, Data Warehouse 則是 MySQL, 用的只是一般的 MyISAM Engine, 所以可以存取大量, 但須要兩台來確保安全.

有時我很難想像若這機制不是這樣做, 而是要用一個大型的 Data Warehouse 來做到, 幾乎是不太可能, 即使花上幾百萬也很容易碰到瓶頸, 但上面這樣大約不超過百萬就可以做到, 只是付出的代價就是程式設計師的能力.

雖然最後我們還是會討論 TCO Total Cost of Ownership, 在這例子最大的問題是 SLA 的 ThroughtPut, 其實要達到就很不容易了, 這反而是第一要務.

所以最後我們還是看目標的商業邏輯來決定一個 High Availability 要如何設計.