如何規劃、建設你的數據庫架構

引言

　　昨天和剛入行就帶個人老領導相約北京酒吧，4年師徒情，7年未見，從老公司境況到老熟人的現狀，到如今的工做，將來的發展。從當下的技術到新技術的展望，聊到數據庫架構，我說我如今仍是在作傳統的數據庫架構，而老領導滿心的分佈式，好像不是分佈式都是比較LOW了，這裏面依然存在着這樣一個問題，什麼是「分佈式」，由於每一個人說的都不同，理解的也都不同。

 　　而分佈式又是怎樣一步一步演變的，不一樣狀況下又該如何設計規劃本身的架構，文章篇幅有限內容太多，這裏只能粗淺的說一說啦。

------------------本文純屬我的觀點，若有錯誤、不足望指教----------------

 

架構的演變

　　架構演變必定是根據當時要求的場景、壓力下性能的須要、安全性、連續性的要求、技術的發展.....

　　我把架構的發展分爲大概4個階段：

　　1.單機模式

　　

 　　IT建設初期，高速建設階段，你們要作的只有一件事，我須要什麼構建什麼，我須要ERP我買軟件，須要HIS買HIS，這個時期按需構建大量的系統基本在這個時期產生，固然那個時候也沒什麼高可用的要求。

　　2.雙機熱備 和 鏡像

　　　　

　　基本是20年前的技術了，在高速構建後，一堆的系統運行中，用戶發現咱們的核心業務若是壞掉業務受影響，停機幾個小時作恢復 這是沒法接受的，那麼雙機熱備或鏡像，Active-Standby的模式出現，這樣一臺機器工做，一臺備用壞了在短期能夠接管業務，形成的損失會低不少！

　　那麼問題也很明顯，備機資源浪費，依賴存儲，數據仍是單點，成本較高。產品也不少：RoseHA/RoseMirrorHA、NEC ExpressCluster、微軟MSCS、Symantec VCS、Legato、RHCS 太多太多了。

　　隨後爲了解決數據單點的問題有出現了 存儲的主備，存儲的雙活這廠商也太多了，這裏就不介紹了

　　　　

 

　　基本上傳統企業依然停留在第一和第二階段，也就是要麼單機，要麼雙機熱備

 

　　3.節點多活 

　　     

　　隨着業務量愈來愈大，數據量不斷飈升，系統高效性的矛盾顯現出來，系統卡慢、報表、接口業務沒法分離OLAP OLTP業務混合致使系統鎖狀況嚴重，資源消耗極其龐大，光靠升級硬件已經沒法知足要求，橫向擴展已經成爲大勢所趨。

　　同時切換時間、備機沒法啓動的問題也困擾着用戶。

　　那麼節點多活，多臺機器同時對外提供訪問的技術登上舞臺，表明的ORACLE RAC、微軟ALWAYSON 、MOEBIUS集羣

　　多活的兩種模式也是從第二帶架構的演變

　　oracle rac 把雙機熱備的輔助節點變的能夠訪問，關鍵點數據在多節點內存中的調配

　　Microsoft awo、Moebius 則是把鏡像的輔助節點變的能夠訪問，關鍵點數據多節點同步

　　這樣橫向擴展來分擔壓力，而且能夠在業務上進行分離。

　　 4.分佈式架構 

 　　

 　　分佈式架構真的不知道從何提及，概念太大，每一個人理解的都不同，只能意會不能言傳：

　　好比說一份數據分開存成多份

　　好比說拆分，水平拆分、垂直拆分、分庫、分表、分業務

　　好比說....

　　其實說到底就是在第三代橫向擴展也沒法知足的狀況下，繼續「拆」，根據不一樣需求各類「拆」，拆到什麼樣呢？ 你們都知道能夠說最慢的環節在數據庫，傳統的作法複雜語句，大存儲過程運行很是慢，那咱們就把這些拆到表數據量足夠小、語句足夠簡單、業務粒度小、訪問壓力盡可能的小！

　　這樣細化的設計一切爲業務服務，也是精細化設計產物，但這也存在一個問題，傳統企業在缺乏高端人才，人力的狀況下根本沒法作到。如今的互聯網公司爲業務的須要同時對IT團隊的大力建設，這是傳統企業根本沒法達到的。

　　

　　固然若是有第五代那也許能夠說是雲，將來業務一切的技術都是雲端，雲端看不見摸不到，傳統行業人迴歸業務，而IT 建設與管理也必然由專業的人作專業的事兒。

 

　　我的總結的架構演變，主架構演變不包含其餘輔助技術，僅供參考

　　

其餘技術漫談

 　　在這四代架構之間也有不少技術出現，主要以數據複製、存儲同步爲表明，如DG、OGG、LOGSHIPPING、Replication等等，這些都是不一樣場景下的數據複製，讓一個副本變成多個，基本目的在於副本讀或者本/異災備，而這些技術也在不一樣的場景中扮演這重要的角色，每種技術都有本身的優缺點，不能一律而論。

　　

 

　　固然這裏面還包含如今所謂的虛擬化、超融合、存儲雙活，這些技術首先不是數據庫自己技術，在不少企業所謂數據庫的高可用中扮演着擦邊球的角色，虛擬化、超融合、存儲雙活都有本身適用的場景，而說到數據庫的架構，這些方案只是基礎架構層面。

　　

如何選架構

• 　　選架構

　　首先你該選的是幾代架構？

　　四代架構是按照業務不斷細分，以冗餘 和 拆分、細化爲主線大致過程

　　二代冗餘

　　

　　三代粗拆分

　　

　　四代細拆分

　　

 

 

 

　　固然這是隻是大概的意思，實際中拆分的場景，條件，擴展性一系列複雜的過程。

 

　　 我曾經無數次遇到幾十G的庫 幾百併發的應用就要規劃分片，領導最求高大上，底下技術人員叫苦。

• 　　構建

　　構建中主要是對建構的細節瞭解和熟練，這和企業的人員配置有很大的關係，傳統企業中不少在架構方案中選擇第三方產品？這是爲何，構建須要專業的人，而企業最少的就是這部分人，而維護管理，責任劃分也是不得不考慮的事情。

　　固然架構越複雜投入的經歷也就越大，這也不是一個架構師能夠主導的事情。

• 　　維護

　　維護纔是關鍵，業務變更後的靈活性、壓力下的擴展性、出問題的排查、技術力量的支持，一系列漫長的過程開始了.....

 

題外篇

　　本身在傳統行業玩的過久了，寫這片文章的過程當中也和PingCAP 聯合創始人& CTO 黃東旭，聊了一些將來技術的發展，tidb作的風聲水起，對將來數據庫你們都是未知，但隨着技術的不斷涌現更牛的架構，更牛的理念也必將一一實現。

　　好比依靠智能化的機制集羣自我修復，性能自提高，架構自適應等等

總結

 　　架構方案是幾代不重要，重要的是適合本身的業務，保證穩定、安全、高效、持續，單機適合簡單業務，沒有那麼高的安全性、連續性依然能夠，雙機熱備能夠保障基本的高可用，節點多活的集羣適合業務壓力較大簡單粗暴的分離和壓力分擔，至於分佈式若是企業有能力有資源，業務壓力龐大天然會考慮，但在我接觸的客戶中太多認爲本身業務只能經過分佈式方案構建，可是其實只是簡單優化+三代多活，讀寫分離負載均衡便可知足。

　　因此根據本身業務評估最爲重要，一個好的架構規劃，不但解決現有問題節省成本，更會避免步子太大激進帶來的沒必要要損失。