數(shù)據(jù)庫高可用方案PK：選擇Oracle還是MySQL？

作者：楊建榮

關于Oracle和MySQL的高可用方案，其實一直想要總結了，今天分為幾個系列簡單說說。通過這樣的對比，會對兩種數(shù)據(jù)庫架構設計上的細節(jié)差異有一個基本的認識。

高可用方案概覽

Oracle有一套很成熟的高可用解決方案MAA。用我在OOW上的ppt來看，這個方案自9i開始，到今年已經(jīng)有16個年頭了。

如果從技術架構的角度來看，部署的分布圖類似下面的形式，中間有遠距離的數(shù)據(jù)傳輸，可以通過中間的節(jié)點來轉換，中間這個節(jié)點很特別，是不存數(shù)據(jù)的，只是保持一個內(nèi)存結構，同步數(shù)據(jù)。

這種擴展方式簡直是酸爽，在一些跨數(shù)據(jù)中心的場景，允許一定延遲的情況下還是有用武之地。比如你需要從北美讀數(shù)據(jù)，可以從北美推送數(shù)據(jù)庫到香港或者新加坡，再推送到北京。有了這種方式就很容易擴展。當然在實時交易中還是存在一些瓶頸和缺陷。

展望和后續(xù)補充

如果拋開具體的數(shù)據(jù)庫，整體來說數(shù)據(jù)量和業(yè)務量到達一定程度都會碰到一系列的問題。這些都是痛點也是難點，常見的問題如下：

單臺服務器無法承載已有的壓力

數(shù)據(jù)庫單表容量越來越大

大量的讀寫需求無法平衡

資源如果擴容，應用改動較大

資源的負載沒法拆分，或者不易拆分

這時就需要擴展，就需要匹配的解決方案，比如中間件的方案，有的解決了一些通用的問題，有些側重于某一方面。比如需要考慮sharding來分片，讀寫分離來做分擔讀寫壓力，前端海量訪問可以通過大量的水平擴展來分擔。

從這個角度來說，MySQL是以架構和規(guī)模取勝，通過業(yè)務拆分和架構拆分能夠實現(xiàn)線性擴展。而Oracle的擴展性雖然沒有那么好，但從架構和業(yè)務層面來說也能做，這個后續(xù)有機會再細細說一說，可以擬一篇分布式方面的文章。

小結

簡單總結一下，高可用的方案選擇很多，各家有各家的需求，能定制的定制，能開源的開源。大道至簡，只要滿足了需求，系統(tǒng)穩(wěn)定不背鍋，那就是最好的方案。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。