把握數據庫發展趨勢 DBA應如何避免「踩坑」?

在DTCC 2019大會上，阿里雲智能數據庫產品事業部高級產品專家蕭少聰作了題爲《如何構建雲時代DBA的知識體系》的演講，進行雲時代之後，IT行業各工種的職責都在發生變化，雲數據庫使得平常DBA管理實現更多的自動化，大大提升平常管理效率，同時也對於企業總體投資產出能夠更快得到成效。面對雲數據庫的發展趨勢，DBA應如何避免「踩坑」呢？本文就爲你們揭曉答案。

專家簡介：蕭少聰（花名：鐵庵），阿里雲智能數據庫產品事業部高級產品專家，PostgreSQL中國社區常委。

直播回放

連接：https://yq.aliyun.com/live/1046

議題PPT下載，戳這裏！

https://yq.aliyun.com/download/3562

本文將主要圍繞如下四個方面進行分享：

1. 管理模式的變化
2. 雲數據庫VS.自建數據庫
3. 雲DBA知識體系構成
4. 如何成爲優秀的雲DBA

1、管理模式的變化

對於數據庫技術而言，「雲」已經成爲你們沒法忽視的技術趨勢。在Gartner 2018年的數據庫魔力四象限裏面，雲計算數據庫廠商已經佔LEADERS及VISIONARIES領域的絕對比例，這也表明了業界對於雲的承認。

那麼，雲和傳統架構有什麼不一樣呢？對於傳統數據庫系統而言，須要搭建不少的硬件，鏈接不少的網線，在本身搭建的私有云裏面可能會有一些虛擬化或者容器化的架構，再往上對於DBA而言其實須要的就是一個數據庫，須要可以鏈接進去進行操做。固然了，在傳統架構下，DBA可以對數據庫有更多的操做和配置，可是在雲上可能只會提供一部分數據庫配置文件的修改權限，並不會容許修改所有配置，這是由於云爲DBA提供的是SLA，也就是說雲數據庫提供的是服務。針對於服務而言，不太可能容許DBA去對操做系統進行改變，由於這樣可能會破壞HA，所以會有一些限制，可是對於數據庫操做而言，依舊是經過一個端口就鏈接進去的。

除了數據庫架構設計以外，傳統架構和雲架構在作安裝配置的時候也會有所不一樣。在傳統架構下，DBA須要去規劃數據庫全部的一切，包括操做系統、硬件以及各類安裝準備以及驗收、切換等一系列演練。在雲架構之下，總體的配置、安裝以及部署是不須要DBA敲各類命令或者安裝各類業務系統的，操做系統、參數優化以及總體的HA只須要在雲控制檯上點擊幾下就能夠配置完成，不管使用阿里的公共雲仍是私有云都是這樣的狀態。這些就是在管理模式方面或者在系統建立過程當中已經可以看到的變化。

2、雲數據庫VS.自建數據庫

有不少人存在這樣一個疑問。那就是「雲數據庫和自建數據庫有哪些區別？」。這裏首先澄清一個概念，在阿里巴巴看來，真正雲託管的數據庫纔是雲數據庫，而若是隻是使用ECS雲服務器來自行搭建的數據庫並不算是真正的雲數據庫。

實際上，雲數據庫最終提供的是一個服務，其包括了系統的可靠性、可用性、安全、備份等一系列的東西，當創建完雲數據庫這些都是配置完成的，無需DBA進行二次配置。固然，若是DBA有本身配置的需求，阿里雲所提供的雲數據庫服務也會提供API接口進行調配，或者也能夠經過阿里雲的管理平臺進行操做，而不像傳統狀況下須要很是高的數據庫初始建設費用。

成本模式的變遷

對於成本而言，傳統狀況下本身建設數據中心須要規劃好將來3到5年到底須要多少資源，因此成本是一次性提供的。此外，對於DBA而言，通常將其分爲業務DBA和運維DBA，前者爲數據庫業務解決問題，發揮功用，後者純粹地負責運維工做，好比安裝、部署、按期進行各類類型的巡檢。將來，運維DBA會由於雲架構的體現慢慢地減小，而業務DBA卻不會消亡，所以DBA應該更加關注於企業在作什麼業務，數據架構應該如何優化，幫助企業改變自己的運營狀態。

以往成本的開支，一會兒就是一臺服務器，可是現在在雲上或者互聯網上有不少的創業公司，所謂的「獨角獸」就是從很小規模開始起步，忽然之間變成很大。當這些創業公司小的時候或許並不須要購買一臺服務器，經過雲架構，就能夠從很小開始，逐漸彈性上去，這樣的彈性能力使得IT實現資源的釋放。若是今天還在使用傳統的數據庫服務器購買方式，而競爭對手或許就可以將節省下來的資金用於技術人員或者業務上去，由於沒有了固定資產初期的開銷，對於創業公司而言，其運行的資金鍊也會更加健康，發展的速度也會更快。

3、雲DBA知識體系構成

隨着數據庫技術的發展，企業對於DBA的需求也不斷提升。從對於OLTP這樣的SQL數據庫和NoSQL數據的掌握，進一步演進，爲了解決性能問題可能須要Key-Value緩存數據庫，以後創建OLAP數據倉庫，再以後實現大數據離線分析。

而對於初創公司而言，就會發如今最開始可能三兩臺機器就搞定了，只須要一個兼職的DBA。

進一步當開始使用Key-Value緩存數據庫以後，業務愈來愈重，單臺服務器沒法搞定，須要實現HA。此時就比較困難了，所以須要一個比較神奇的DBA，須要DBA什麼都懂。

當企業進一步發展到更大的時候，可能不只僅須要解決一套系統的問題，可能須要解決多套系統的問題。此時可能須要一個DBA團隊，分工會變得更爲細緻，不只有專業的DBA，還應該有頂尖的架構級別DBA來解決總體問題。

更進一步，可能須要作數據倉庫和大數據，那麼整個DBA團隊的分工就會更加明細。

在企業的實際運行過程當中，DBA須要作大量的工做，有的時候甚至是操做系統的各類細節都須要瞭解清楚才能將數據庫調優好。

雲數據庫的理論基礎

而當進入雲數據庫時代，須要看到的是另一種景象。這裏有一些雲計算的新名詞，好比Region地域、AZ可用區、VPC以及VSwith等，這些都是雲DBA須要瞭解和掌握的。從數據庫的角度來看，雲數據庫的確出現了不少新名詞，可是數據庫基礎理論依然是不變的，依然會有實例、高可用、分佈式、SQL、ACID和CAP等理論。

運維簡化：自動化部署

以往都會說須要部署一個主備集羣，而今天若是想要部署主備集羣也會在一個IDC中心進行部署。若是想要部署跨IDC的主備集羣，在傳統架構下每每須要購買光纖、光纜，而且須要肯定光纖、光纜的延遲狀況，判斷其所形成的延遲是否可以接受。而在雲數據庫架構之下，這些信息都不須要進行管理，所須要管理的就是在購買雲數據庫時進行選擇，好比選擇跨中心的主備就能夠直接創建起來，所以這種複雜架構的構建並不須要本身來規劃，能夠節省DBA去作傳統底層業務處理的時間。

運維簡化：跨地域部署及切換

除了對於傳統架構比較容易的同一個城市跨AZ以外，其實若是想要實現跨省就會變得很是複雜了。然而，在雲上就會變得很是容易，若是想要實現跨Region的搭建就能夠利用阿里雲上的DTS工具將數據拉過去，須要進行數據複製的時候纔會收費，平時不用的時候甚至能夠直接將其關閉掉。

當搭建了跨Region的數據中心以後，後面就會有更多的事情。好比到底敢不敢進行主備切換，以往作主備切換的時候都須要配置一大堆的DNS，本身寫不少腳本作確認，而在雲架構底下，只須要經過一個按鈕就能夠實現。所以，你們必定要清楚，做爲雲DBA應該去學習哪些東西，同時須要放棄哪些東西的學習。所以當有云架構以後，DBA能夠將重心放到學習如何優化SQL以及各類不一樣的數據庫特性以及它們之間的組合架構如何解決業務上的問題，而底層的業務架構能夠交給雲去作。

運維簡化：按期全/增量備份

在雲上面，若是須要作按期增量備份也僅僅須要點擊幾個按鈕進行構建便可。

運維簡化：恢復到時間點

不管針對於哪一個數據庫，阿里雲的服務均可以作到任意時間點的秒級恢復。這一功能並不僅是爲了幫助用戶找回數據，不少用戶的DBA和開發的互動愈來愈頻繁，若是開發收到某個時間段系統運行較慢的反饋，就能夠直接克隆一個那個時間段的新實例出來，而且只須要按需購買便可，克隆出來實例調試完程序以後直接將其關閉掉便可，一切的成本都在DBA的掌握之中。

運維簡化：按需橫向擴展

DBA對於數據庫的橫向擴展也會作不少動做，傳統的方式經過只讀實例能夠作相應的擴展，同時還有像阿里雲的DRDS分佈式數據庫分片的運行方案，也可以比較容易地搭建出來，進一步地還能夠走向PolarDB，經過分佈式的一寫多讀來簡化業務規則。將來，DBA須要重點關注的點在於何時使用什麼樣的架構。舉例而言，若是須要解決某個大促時間段大量的讀請求問題，應該經過只讀實例來實現。而若是老舊業務徹底能夠基於互聯網改寫，就能夠選擇直接經過DRDS作整個系統的分庫分表操做。若是須要很是強的與關係型數據庫一致性的業務，而且與此同時數據量很是大，可能須要選擇PolarDB的架構，所以DBA須要對於不一樣的數據庫架構以及其背後原理有本身的理解。

運維簡化：自動讀寫分離
阿里雲數據庫幫助用戶實現了讀寫分離，DBA不須要再進行應用程序上的業務改寫，好比對於讀寫分離的設置均可以實現自動化。經過對於請求的分析來判斷應該分發到讀實例仍是寫實例。

以上這些都是雲數據庫可以提供的能力，你們會發現以往的管理模型已經都覆蓋到了。將來運維方面的DBA工做可能減輕，所以DBA應該跳到業務方向上進行發展。

4、如何成爲優秀的雲DBA

在雲數據庫的背景下，DBA是否還須要學習每一部分的數據庫管理知識呢？由於人的時間是有限的，將來除非真的要作相似於阿里雲的總體管控系統時須要深刻底層進行分析，而若是不是，那麼這些數據庫管理就能夠交給雲管控平臺來實現。可是數據庫優化卻須要DBA知道和掌握，這裏並非指修改哪些參數可以優化成什麼樣子，由於這些在雲平臺上就已經配置好了，可是DBA須要知道的是針對於某個數據庫，什麼樣的索引對它更加有效，表與表之間的關係應該如何創建才能使得數據庫性能更好。

雲數據庫提供了不少的集羣架構，也並不必定須要所有學習。不管是單節點、雙節點仍是三節點，經過阿里雲均可以實現一鍵式部署。所以做爲DBA更加須要瞭解不一樣的數據庫實例之間應該如何進行互動，從而產生對業務有效的架構方案和規劃方案，這正是DBA須要深刻思考的，而不是天天都在備份服務器，部署數據庫，檢修各類硬件。

雲服務支持邊界

基於雲的運行環境，雲數據庫服務和DBA的邊界會發生改變。資源調度、基礎優化、平臺能力以及準確輸出都是由雲來提供的，而企業的DBA須要作這樣幾件事情：對於表結構須要花費更多的時間來規劃，定義本身企業的SQL標準來規範開發模型，對於SQL以及結構進行優化來提高業務性能。此外，DBA不只應該關注於數據庫，實際上也應該作企業成本的控制，經過不一樣的數據模型組合來解決不一樣的業務問題，也須要了解雲數據庫日誌的不一樣，並經過故障檢測自查或者發起服務需求。

性能問題甄別

對於雲DBA而言，若是出現了數據庫性能問題應該怎麼作呢？其實任何的雲廠商都會有本身成熟的一整套監控以及性能分析方案，好比阿里雲的方案就源自於阿里巴巴內部的經驗，可以幫助DBA發現故障並提供解決方案，使用起來很是方便。

雲服務支持邊界

此外，阿里雲也提供了一種能力，就是阿里雲後端的DBA會幫助用戶解決數據庫相關的問題。以往狀況下，若是數據庫出現了問題，須要打電話給服務商來約時間解決，存在必定的延遲。而今天在阿里雲上面，DBA隨時能夠進入。而且阿里雲還提供了安全保障，具備完善的受權機制，只有用戶受權阿里雲的DBA訪問用戶數據庫或者進行服務的時候，阿里雲的DBA纔有權限爲用戶提供服務，而若是沒有獲得受權，阿里雲的DBA是不可以進入的。

高危SQL預防

阿里巴巴具備本身的一整套數據庫開發規範，而用戶的DBA也能夠本身定義一套數據庫開發規範，好比能夠定義某一個字段是否能夠以某種方式編寫，這樣就從系統設計和規範的層面避免爛SQL進入系統，進而形成系統故障。

跨雲管理

今天，阿里雲自己在運營雲，而其實阿里雲也會提供跨雲的管理工具。不管用戶使用的是哪裏的雲，只要管理的是MySQL、MongoDB、Redis數據庫都會提供HDM工具來協助用戶管理跨雲數據庫。

總結一下，雲數據庫帶來了標準化部署、自動化運維、按需擴容以及工具化調優等優點。對於企業而言，不要再讓DBA爲部署和備份等瑣碎的運維工做所纏繞了，他們應該將精力投入到優化架構、寫好SQL以及作好數據庫的總體構造上，進而爲企業輸出核心技術生產力。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。