**在高有效性 High Availability 中, 最大的問題不是一些對外的設備, 最大的問題是在資料庫的能力, 這問題有幾個原因:

1. 資料庫在 Replication 中須要很大的資源.
2. 資料通常一直在累積, 累積到一定的量時就有儲存與效率的問題.
3. 在 Runtime Database 時要負責 Process Control, 若發生 Lock 時會很麻煩.
4. 資料庫對於一致性與完整性要求很高時, 又要有效率的問題就須要很高的預算.
5. 程式設計師把太多的工作丟給 DBMS (Database Management System) 去做, 造成效率瓶頸.
6. 資料庫分流必然須要 Replication, 也須要很大的成本與邏輯上的不同, 程式也須要修改.

這些都是造成資料庫 Database 在 HA 中最大的挑戰.**
但無論如何, 現在還是有一些新的 Solution 解決方案:

1. NoSQL 的開發能夠讓資料庫依照不同的使用去做選擇.
2. 資料庫都被包在 JSON 或 XML over HTTP 等 API 去使用, 因此可以依不同的狀況去分流與 Cache 快取.
3. 搜尋的資料庫也都被專化, 這個最吃資源的使用可以分開.
4. AJAX 等讓使用者透過 Partial Refresh 部份更新對效能的要求可以降低一些.
5. Queuing System 的使用讓資料庫的使用可以在之前先做排隊.
6. 最後現在許多資料庫都已經都內建 Cluster 了.

這邊我不太想提大家都已經知道的 Database High Availability 的作法, 大家也可以猜得出來我第三篇會寫一本書介, 因此直接去看那本書就很足夠了, 而我是想寫沒有的東西, 就是現在被一些實作慢慢認同的異質資料庫的問題.

現在資料庫的設計我們都會去依照使用行為去做區分:

1. 讀多寫少, 但更新要求不高. (如討論區)
2. 讀多寫少, 但必須讀到最新資料. (如交易內容)
3. 只寫很少讀. (如 Log 記錄)
4. 讀多寫多, 但更新要求不高. (對談記錄)
5. 讀多寫多, 更新要求高, 但可以丟棄. (如 Runtime Prcoess Control)
6. 讀寫可以依來源去做區分. (每分支部的資料)
7. 量很大, 但效率要求不高. (歷史資料)
8. 讀寫量與效率都很重要. (對資料庫使用無法掌控)

上面八種資料庫的使用方式, 除了第八種外, 幾乎都有不同的設計, 事實上還有一個更有趣的問題在:

1. 有很多表 Table , 但每個表的資料量不大.
2. 表不多, 但每一個表的資料量 (Rows) 都很大.

這都會讓資料庫的設定 (Config) 有很大的差異, 所以一個高有效性或效能調校的分析師, 對於資料庫以及程式設計必須要有一定程度的熟悉, 以現在的觀點而言, 不太可能有一個資料庫, 一個工具, 在一定的條件 (資源或預算) 是最佳解的, 事實上若會只選一種資料庫的, 唯一原因是 : "政治因素", 不然就是 DBA 太懶了, 當然這是以一定成本的考量, 若預算足夠找要找人外包就一切解決.

若是所有專用的應用都要用專用的資料庫就太累了, 例如計數器事實上也有專用的資料庫, 或是少量單一檔案的也有其資料庫, 只是若太複雜的話的確管理的便利性及管理就會受考驗, 人力也是另一種成本.

但好的管理者本來就應該有這能力去區分其差異性, 並知道選擇的時機, 或者是不選擇的原因, 不能說不須要就不用知道, 因為善用每一種資料庫的優缺點是必要的.

雖然是資料庫種類越多管理成本越高, 當然出問題機會也變高, 到最後也只是選則兩三種資料庫, 畢竟每一種資料庫都做備援或備份, 就太累了.