526
技術社區[雲棲]
最流行的高性能關係型數據庫是如何在雲端打造的
2017雲棲大會POLARDB專場，阿裏雲資深技術專家林曉斌帶來最流行的高性能關係型數據庫是如何在雲端打造的演講。本文主要從數據庫雲服務目標開始說起，又介紹了經典模式痛點，接著提出了下一代數據庫需要解決的問題和方案，最後做了簡要總結。
以下是精彩內容整理：
數據庫雲服務的目標
做雲數據庫的目標，讓DBA創造更大的價值，不僅阿裏巴巴自己的DBA，還有客戶的DBA，以及沒有DBA的公司，擔負DBA責任的開發人員，讓這些人能夠更加省心，這是我們做雲數據庫的目標。
基於這個目標有五個指標，包括可用性、可靠性、安全性、可擴展性和可診斷性。
按重要性來說，要從安全性說起。安全包含了兩點，一是數據本身的安全，一是對於數據泄露的安全。在安全上我們做了很多工作，比如現在允許用戶通過配置，讓數據落地後是加密的，也就是說你不用擔心數據被拷走的問題。我們還有這樣的設置，現在阿裏雲的業務人員無法訪問數據庫，讓用戶在前台授權才可以做到，通過這種方式提升它的安全性。
在可靠性上常做備份恢複到任意時間點的功能。用戶出現誤刪數據庫，或者把表改錯了，我們會提供恢複到任意時間點的功能。
常見擴展性其實很好理解，就是通過圖表。當我們自己在內部維護，剛開始近千個實例，後來發現實例數和DBA的數目呈比例了，阿裏雲有10萬多個實例，但沒有1萬多個DBA，隻有四五個。中間有一段鎮痛，怎麼讓實例數增長的情況下，運維人員不要線性的增加，可診斷性也是體現雲服務是不是成熟的標誌。
經典模式
公有雲上大量的實例都是雙節點結構。從2015年開始，我們就默認改為semisync，甚至很多公司，包括一些友商默認還是用異步模式。如果把它設成最安全的模式就會比較吃虧，用戶要找兩個雲廠商做測試。在阿裏雲，數據的準確性、可靠性是第一位的，所以在2015年後，我們把默認改為雙節點，保證數據不丟。
都有哪些痛點呢？比如分鍾級擴容，包括電商也會碰到這樣的問題，很多小的電商在雲上做，用戶不用告訴我們的。去年“雙11”的時候，我們運維團隊的要求是“雙11”那天要做到零幹預，前幾年已經做到零故障了。有一個公有雲的用戶，也是一個電商網站，他沒有告訴我們，等到他們說準備半年的掛了，他們買了兩個很小的實例，“雙11”之前也沒有壓測，那一天壓力一上來馬上打爆，臨時加機器已經來不及了，數據量又大，我們從2個節點擴到8個節點，花了20個小時的時間把擴容做起來，最終幫助他們把東西賣出去。分鍾級擴容，後麵慢慢是一個剛需。
超大容量，遷移數據第一步就是備份。一旦發起備份，看上去備份在內庫備，意味著這時候是隱含的單點係統，主庫不敢掛。我們的需求是備份肯定要做，但是要讓備份最快的做，而且最好做的不影響其它。成本來說也是用戶的痛點。
下一代數據庫需要解決的問題
從研發的角度以及數據庫本身發展角度來說，還需要解決哪些問題？比如：
- 硬件紅利，其實數據庫這幾年來，尤其是MySQL在過去20幾年來的發展，它還是沒有真正把硬件紅利榨幹。好像一些新的數據庫，NewSQL數據庫，把小量企業變成大批量企業，讀也是這樣。很多硬件已經不再是RDS瓶頸了，這時候數據庫應該考慮反過來，盡量多的把隨機寫變成數據寫，還有備份要吃帶寬，備份是整個拷走。整個設計理念就是按照機械硬盤在做，雖然慢慢在改進，但改進量還不夠多。
我們數據庫怎麼用好現在的硬件紅利？最近推出的POLARDB，數據係統是從網絡取過來的，數據從網絡取過來不從本地拷反而慢，怎麼做到性能翻倍呢？POLARDB底層存儲已經做到網絡上讀取的性能，目前已經達到和本地一樣快，而且還有空間，以後就會超過。它是一個網絡集群，它的LBS和帶寬不再受限了，信息越多越細節，對終端用戶的體驗就越好。有更多的信息可以參考，用戶的體驗就更好，我們怎麼通過硬件紅利體現數據庫的能力更加擴大，再讓用戶利用數據體現到他們的產品，讓終端用戶提升用戶體驗，這是我們需要解決的問題。
- HTAP，現在我們說的MySQL一般是做事務，甚至比較長的一段時間，MySQL做什麼最好是當天利用，越簡單應用，越不容易出BUG。越簡單，意味著需要別的能力時，就需要拿別的係統補充。把MySQL當KV用當然可以，我現在要一個複雜的交易，需要找另外一個係統過來做，這個係統專門做交易，接下來要做數據分析，又拉一個係統過來做，結果發現一份數據要從好多地方開始大量的數據同步，以前做數據同步還可以，現在都是分鍾級別了，這是一個矛盾，越來越大。數據越來越大，一個要分析的快，一個是數據量變大，拷起來快。最好能把係統放在一起，哪裏寫就在哪裏讀，這樣就很好了。
- 智能服務，阿裏很多基礎運維DBA越來越少了，以前DBA要搬機器，現在已經沒有這個需求了，後來要經驗豐富，意味著不容易在雲上擴展。其實很難要求一個創業公司裏有一個經驗豐富的數據庫專家，我們怎麼讓用戶擁有數據庫專家，如果隻有一個客戶，支撐起來比較容易，當我們有10萬個客戶時，需要考慮怎麼讓一個智能係統幫助我們服務。
解決方案
POLARDB
怎麼解決痛點呢？POLARDB基本的想法是這樣的，數據和存儲分離，計算和存儲分離。圖上一個節點，主庫、讀庫、遠程訪問數據，解決分鍾級擴容。以前我們怕別人拷數據，現在不用怕了，找一個機器把進程開起來就可以了。本地磁盤大小和備份時間的限製容量，以前一個數據有三份拷貝，備份都是分片備的，不會對係統造成很大的衝擊。
HybridDB
現在數據量的問題解決了，就是拷貝，如果隻有POLARDB一個單點，分析這個問題還是沒有解決，它還是偏向事務的係統。我們有HybirdDB，數據可以直接在這裏讀取，算完給用戶。列後引擎可以認為用戶獨立入口，當用戶來使用時隻看到這個點，語句可能不一樣。分析類語句有定製語法，兼容hadoop的語句。
CloudDBA
由於磁盤老化，做DBA用戶和你說語句慢了，我們看看語句是不是錯了，表結構對不對，需要查很久才能懷疑到硬件壞了。另外就是網絡，網絡有很多層，我們會花好多時間在這個事情上。鏈路上做了全鏈路監控，從客戶端到服務端，每個節點都采集，先寫後讀，他認為這個事情是並行的，是兩個語句寫下去的，用戶根本查不出來的。現場ID不一樣，說明是從不同現場發下來的。以審計日誌為基礎，我們現在做的POLARDB，已經開始做公測，後麵用戶可以自己在入口上升係統。我們把問題暴露出來，並不是所有問題用戶都需要關注，有了完整係統之後，希望把係統的能力覆蓋給客戶。
總結
我們想讓所有公司DBA卸掉繁重機械的工作，以前是搬機器裝實例，大家已經過了這個時代了。下一步要做什麼事情？擴容、縮容，大促容災等體係設計，這些不是體現DBA的價值的，真正體現DBA價值的能力是他們對公司業務的了解，DBA風頭最盛的是Oracle時代，因為Oracle很穩定，他們做業務的架構師。希望阿裏雲數據庫讓我們自己做到Oracle那樣的能力，讓DBA業務人員可以擺脫低端的工作，了解公司業務，成為業務架構師，創造更大的價值。
最後更新：2017-10-27 19:33:38