使用一個Oracle MySQL的理念

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

  資料庫分久必合合久必分。

    20年前我們沒什麼人說架構，但是現在幾乎是個人就說架構。為什麼呢？因為從前是單機，而現在是多機。比如分庫 或者分表。或者分散式。

   這裡再次說一下，分庫分表不是分散式。分散式是一個庫，分庫分表是多個庫。分散式是由分散式資料庫來完成事務和鎖。分庫分表是應用自己來實現事務和鎖。  另外分庫相對容易，分表就比較難做。分庫和分表是兩回事。

    微服務和中臺是導致資料庫分庫的主要因素。但是這裡要提一下分庫不見得是要把資料庫分在很多不同機器上。比如這也是分庫。

這個也是

所以說分庫，可以分，但是沒說一定要多臺機器呀。一個上面也可做很多database庫。

     每次說到這個我會面對一堆質疑，就是10個子系統，10個庫。那麼就要用10臺機器安裝資料庫。我們之前說了分庫不是分散式。那麼10個庫之間的事務和鎖就要需要第三方來保障或者根本沒保障。那這個一致性就比較慘不忍睹，即使有一個很好的控制，要知道所有的互動在網路上消耗了大部分。

     所以我的觀點：單套是最好的架構。比如Oracle的RAC，以及MySQL的MGR和國產資料庫TiDB 等等分散式資料庫都是一套 。因為要高可用嘛。如果不要高可用，我認為單機是最好的架構。

     這裡必須說質疑單機壞了怎麼辦？我幹了快20年，單機除了自己做實驗各種破壞性的把底層檔案全部刪除起不來的，還沒有遇到過資料庫自己執行著然後起不來的。我相信也有，但是更多的情況是應用寫的太差把資料庫搞得當機的。如果說比例那麼破壞性的如果是1，那麼應用導致的我估計說是1000萬也不過分。比例大概是1000萬比1. 根據這個比例我覺得重要精力還是花在更容易出問題的點上。畢竟現如今的硬體質量槓槓的，再加上RAID10，硬碟壞50%也還行。

      這裡也有人說10個庫一個當機（就是應用寫的差），不影響其他9個啊。其他還能用。問題是10個如果是獨立事件的，那麼自然是這樣的。但是如果是有緊耦合或者前後關係的。比如會員庫故障，無法登入了，後面的事情都別做了。  訂單庫故障，就算能登入，今天也別幹了。

    這裡我還說一點但凡這種場景下一個能當機，放心，其他幾個也會當機。所以資料庫越來越多，因為把資料不停的分散，降低表的資料量，從而提升全表查詢的時間。時間短了，鎖短了，CPU少了。但是這一切就是頭痛醫頭腳痛醫腳，越來越差。很多人問我A和B庫能不能和在一起？我就問你們有開發規範嗎？如果有能執行嗎？能執行的話就放在一起。沒有規範或者不能執行規範就別放在一起。

     開發規範能解決這些問題嗎？

     能！

    絕大多數故障99.9%都是效能問題導致的。如果你看過我星辰大海的那幾篇公眾號文章就知道了，單機足以支援你的業務。如果不能支援你的業務，那麼你應該已經是財務自由的人或者是年薪百萬的人。因為你的體量已經很大很大了。

    我以前看到過這樣一個案例：

整合是大量節約成本的。

       還是回到那個讓人揪心的問題。和在一起故障怎麼辦？答案還是一樣，有規範嗎？我們高鐵16節車廂，1000人總有吧？出了溫州那次意外就沒怎麼出過事故。你能說1000多人有風險？反過來說兩座的跑車，酒駕車毀人亡的多了去了。要是胡來怎麼都不行！

就算是高可用也不是用來解決效能問題的，那是防止意外的。