中云網(wǎng)消息 8月29日-30日，以“數(shù)據(jù)重構(gòu)未來”為主題的D-Future七牛數(shù)據(jù)時(shí)代峰會在上海舉行。七牛攜百名創(chuàng)業(yè)明星，技術(shù)大咖匯聚國際時(shí)尚中心，共話數(shù)據(jù)發(fā)展，探討行業(yè)未來!
美圖網(wǎng)高級DBA楊尚剛帶來以”數(shù)據(jù)庫運(yùn)維和性能優(yōu)化之道“為主題的演講，以下是演講實(shí)錄：
楊尚剛：我今天最后一場，我今天主要講的數(shù)據(jù)庫運(yùn)維和性能優(yōu)化的一些東西。
我2011年加入新浪，在新浪待了四年，主要是負(fù)責(zé)新浪微博的一些核心數(shù)據(jù)庫架構(gòu)設(shè)計(jì)，還有新浪數(shù)據(jù)平臺底層軟件優(yōu)化，今年加入了美圖，美圖大家都知道，美圖現(xiàn)在兩款產(chǎn)品，一個(gè)美圖秀秀還有一個(gè)美拍，現(xiàn)在用的人也非常多，這邊我也是負(fù)責(zé)后數(shù)據(jù)存儲的平臺建設(shè)。下面兩張圖比較形象，相當(dāng)于好多人都認(rèn)為從左邊這張圖開始干，理想是右邊，或者是更高級別的人物。
MySQL優(yōu)點(diǎn)使用更簡單，第二個(gè)免費(fèi)。這兩個(gè)是MySQL現(xiàn)在應(yīng)用非常廣泛的原因。第三個(gè)擴(kuò)展性好，當(dāng)然這個(gè)擴(kuò)展性加引號，但是一旦你的規(guī)模達(dá)到上百萬、上千臺的時(shí)候，擴(kuò)展因素打一個(gè)折扣，面臨著一些挑戰(zhàn)。第四個(gè)社區(qū)比較活躍，這個(gè)非常顯然，這也是為什么現(xiàn)在PG沒有比MySQL更廣泛的原因，PG我也承認(rèn)肯定比MySQL要好，但是你的社區(qū)一旦做得不好的話，還是非常不好的，酒香不怕巷子深。社區(qū)活躍是一個(gè)非常重要的點(diǎn)。最后一個(gè)MySQL雖然有非常多的問題，但是在現(xiàn)有的情況下MySQL還是依然能夠滿足我們現(xiàn)在大多數(shù)用戶的需求。
說完它的優(yōu)點(diǎn)再說它的缺點(diǎn)，第一它對復(fù)雜所謂支持不好，MySQL還是挺差的，之前我不知道有沒有人看到，對一個(gè)語句，40條或者200條，肯定是40條快一些，反饋200條快一些這就是MySQL比較坑人的地方。第二對于SQL標(biāo)準(zhǔn)。第三個(gè)大規(guī)模集群方案不成熟，主要是知識面的支持上，官方?jīng)]有一個(gè)很好的支持，還需要很多開元的二次開放才能支持好。下面這幾個(gè)，ID生成器這個(gè)也不是那么重要。這個(gè)和方案相比，還是相對差一些。下面就是Online DDL這也是MySQL比較大的一個(gè)痛點(diǎn)，MySQL就會比較麻煩。下面是HA方案，MySQL沒有一個(gè)非?？煽康姆桨?，很多還需要依賴第三方工具。下面就是備份恢復(fù)這個(gè)也是比較復(fù)雜，展示機(jī)構(gòu)少，這個(gè)時(shí)候比較被動(dòng)，下面就是分支。
下面再說雖然有這么多問題，MySQL還是很受歡迎。第一個(gè)可靠性，第二經(jīng)過大規(guī)模部署的驗(yàn)證，這種都已經(jīng)在線上通過大規(guī)模的生產(chǎn)考驗(yàn)，所以大家都是認(rèn)可的。下面這兩個(gè)是比較支持的，找踩坑，很多技術(shù)都是并不是說它怎么著，還是需要看一下其他人的經(jīng)驗(yàn)。這個(gè)就是DBAlife,比如像各種各樣開發(fā)需求，各種各樣的需求，你還得去滿足。各種各樣需求。下面就是SQL優(yōu)化，也是DBA工作人員很大一部分，下面就是各種救火和故障，你的主庫故障，各種各樣問題，都是需要DBA去介入的。下面就是一些各種業(yè)務(wù)，項(xiàng)目上線，還有日常的溝通。
怎樣能變得不苦呢？DBA涉及到各種更改和創(chuàng)建，它占了很多時(shí)間。如何去解放DBA的雙手，主要是兩個(gè)部分，第一建立數(shù)據(jù)庫開發(fā)規(guī)范，第二個(gè)把固化基本原則到自動(dòng)化審核流程里去，減少DBA的溝通成本和一些重復(fù)工作。
這是數(shù)據(jù)庫開發(fā)規(guī)范，現(xiàn)在網(wǎng)上也有很多，我就不細(xì)說了，說說它的意義，數(shù)據(jù)庫開發(fā)規(guī)范，保證線上的規(guī)模是統(tǒng)一的，是遵守創(chuàng)業(yè)規(guī)范的。這樣對于你后面一些都是非常有好處的。這個(gè)開發(fā)規(guī)范如何去遵守，這個(gè)也是需要DBA去投入經(jīng)歷的，這個(gè)東西，雖然開發(fā)者會去看這個(gè)東西，這個(gè)就需要DBA主動(dòng)去推這個(gè)東西，定期給開發(fā)培訓(xùn)，開發(fā)能夠認(rèn)識到規(guī)范一個(gè)重要性，也能減少DBA后續(xù)運(yùn)維的一個(gè)成本。
這是一個(gè)簡單的規(guī)范示例，主要是一些表情選擇，還有定義，當(dāng)然肯定比這個(gè)復(fù)雜多，如果你把規(guī)范定得很詳細(xì)的話。
DDL自動(dòng)化有三個(gè)部分，建表、審表和改表這都是日常的需求。這是一個(gè)主要流程，提交DDL,首先你系統(tǒng)里面會做一些語法檢測，肯定還是要打回去要重新去改，語法通過，這些動(dòng)作如果沒自動(dòng)化就需要DDL打電話發(fā)郵件，這部分工作就是看它是否符合開發(fā)規(guī)范，剛才提到的自己的選擇，這部分不過的話，也是需要開發(fā)再去修改，開發(fā)修改的話，可以去線上支持。當(dāng)然這里還會設(shè)置關(guān)于操作，比如你去做表還是發(fā)表一些創(chuàng)建的操作，要區(qū)分這個(gè)東西，這個(gè)操作還是盡量讓開發(fā)直接去搞，開發(fā)肯定意識到了操作，如果是的話可能就需要DDL的選擇，做一些提前預(yù)案這些東西。
當(dāng)然剛才提的問題也是DDL的問題，MySQL是內(nèi)部不支持的，960的DDL,很多實(shí)際在生產(chǎn)上用的話，還是有比較大的距離。為什么MySQL會有非常大的問題呢？它需要一個(gè)鎖，一旦你去執(zhí)行這些操作的時(shí)候，都是要組織表，而組織這個(gè)過程中，你不能再往里面寫數(shù)據(jù)。你的業(yè)務(wù)數(shù)據(jù)是不能服務(wù)的，這樣一般產(chǎn)品是不能接受的，所以這個(gè)是MySQL一個(gè)比較大的問題。
當(dāng)然現(xiàn)在也有一些方案，比如像基于FacebookOSC的原理，下面表格主要和做對比，其他兩個(gè)5.6的是不支持的，官方內(nèi)置的這些東西，但是它的問題還是比較多的。包括解決不了DDL延時(shí)問題，還有用了也會有影響。比較多的是基于FacebookOSC的延伸體。
這個(gè)是OSC的原理，還是比較敞亮的。一開始核心是下面部分，調(diào)整塊大小，同步數(shù)據(jù)，根據(jù)覆負(fù)載調(diào)整進(jìn)度，一個(gè)比較核心。后面或者前面都是一些準(zhǔn)備步驟，或者是一些簡單的操作?？匆幌翸ySQL另外一個(gè)，慢日志，如果你要去做的話，很多都要根據(jù)慢日志去做的，如果有一個(gè)系統(tǒng)的話，發(fā)現(xiàn)某一個(gè)你就得去判斷，看一下，有沒有慢日志，這個(gè)基本上是一個(gè)比較常規(guī)的過程。
而這個(gè)里面很多步驟都是可以去自動(dòng)化做掉的，這個(gè)的話，慢日志化系統(tǒng)，根據(jù)慢日志化系統(tǒng)開發(fā)，負(fù)責(zé)業(yè)務(wù)。
這個(gè)算一個(gè)基本系統(tǒng)架構(gòu)，基本上主要依賴這個(gè)是分析MySQL比較好的，分析的結(jié)果也是非常詳細(xì)，報(bào)表也是比較好用。
第二個(gè)Logstash,都可以。第三個(gè)Anemometer,開了一個(gè)系統(tǒng)，右邊這個(gè)圖就是基本的數(shù)據(jù)流程，也是非常簡單，基本上就是數(shù)據(jù)和入庫各種展示。
這個(gè)就是簡單的頁面，最上面是兩個(gè)時(shí)間段的情況。比如昨天某個(gè)時(shí)間，下面框就是它提供的哪些展示，也可以定制。中間這個(gè)根據(jù)IP都可以去調(diào)整。下面是一些展示的過程，一個(gè)例子。這個(gè)就是你點(diǎn)進(jìn)去某一個(gè)，它的變化曲線，在什么時(shí)候比較多都可以看到，包括也可以看到，在這可以直接點(diǎn)出來，它的結(jié)果，不需要再線上去看，掃描或者有沒有都可以在這里面看到。所以說還是比較方便的。
另外一個(gè)的變化就是備份系統(tǒng)，備份系統(tǒng)是做這個(gè)行業(yè)首先要保證的，首先性能不是最重要的，安全是最重要的。所以備份都是最重要的。悲憤意義，很簡單就是我為了數(shù)據(jù)恢復(fù)。下面?zhèn)浞莸姆绞剑琈ySQL備份方式也非常多，沒有官方的一些支持，也是各種各樣，像全量、增量、熱備和冷備，物理和邏輯，延時(shí)，這種方式都是針對不同方式去做的。建立方式，基于熱備加物理是更好的。如果能做出來最好，不能做的話，熱備加物理也可以滿足很多需求。如果你一些非常和核心的業(yè)務(wù)，考慮用組合的方式。
M:這是備份系統(tǒng)數(shù)據(jù)，在新浪做的系統(tǒng)，每年備份數(shù)據(jù)，做7000加次擴(kuò)容，每年要做12加次數(shù)據(jù)恢復(fù)，當(dāng)然這個(gè)東西，實(shí)踐很多開發(fā)不注意，都可能導(dǎo)致不良的后果。數(shù)據(jù)量的話，每日志量每天3TB,數(shù)據(jù)總量在2PB,每天悲憤數(shù)據(jù)量百TB級。
備份優(yōu)化我們主要做下面幾個(gè)部分，第一主主要悲憤策略集中式調(diào)度管理，對格式化都不太好，還有熱備至四，統(tǒng)計(jì)分析，還有校驗(yàn)問題，最后采用分布式文件系統(tǒng)存儲備份。我們當(dāng)時(shí)也調(diào)研過其他的，最終權(quán)利選擇了這種。
當(dāng)然分布式文件系統(tǒng)，之所以要用也是有一些痛點(diǎn)，下面幾點(diǎn)，存儲分配的問題，當(dāng)時(shí)已經(jīng)存儲了六、七十臺左右，你在真的需要存儲管理容量，都需要人工去管理，能自動(dòng)化但是做的不是特別好，還是比較復(fù)雜。NFS這個(gè)還是導(dǎo)致經(jīng)常負(fù)載特別高，備份效率特別低，下面還是存儲集中式管理，最后數(shù)據(jù)可靠性更好，可能會比單點(diǎn)問題會有好處的。
當(dāng)然我們使用分布式系統(tǒng)我們也做了優(yōu)化，第一個(gè)采用Pbzip壓縮比能做到三分之一，降低多副本存儲帶來的存儲成本，第二個(gè)使用壓縮之后，降低網(wǎng)絡(luò)帶寬消耗。最后一個(gè)是erasure的方案調(diào)研，使用這種方案，也都比較成熟。右邊是一個(gè)簡單的架構(gòu)圖。
提到MySQL版本問題，MySQL版本現(xiàn)在是說官方有兩個(gè)一個(gè)社區(qū)版、一個(gè)企業(yè)版，還有其他兩個(gè)，MariaDB版是MySQL去做的。各國內(nèi)來說還是用MySQL社區(qū)版比較多，MySQL企業(yè)版比較少，傳統(tǒng)行業(yè)有錢的可能會選且版。
下面是我的建議，你選MySQL社區(qū)版。但是如果對于大多數(shù)用戶來說，社區(qū)版穩(wěn)定，對于后期的支持肯定會比MySQL企業(yè)版更好一些。最后就是MariaDB在國內(nèi)用的非常少，而且優(yōu)化方向和社區(qū)版還是有一定的差距。
這個(gè)是MySQL主流版本，當(dāng)然之前那些都比較老了，5.0、4.幾現(xiàn)在主流的是5.0.現(xiàn)在主流的就是5.6和5.5,現(xiàn)在一般用5.6就可以了，也是一個(gè)比較穩(wěn)定的版本。5.5的話，是保守用5.5.
下面是MySQL復(fù)制問題，MySQL復(fù)制的話，好多人都會遇到一個(gè)比較坑，MySQL復(fù)制延遲問題和MySQL安全問題。
MySQL復(fù)制采用一些不可靠的投遞，不管有沒有執(zhí)行這些問題都會存在，所以說安全性還有延時(shí)問題被很多人詬病的一個(gè)點(diǎn)。
下面的圖就是它的一個(gè)框架，右面紅框里面就是瓶頸原因，使用或者概念。
這種概念的簡化，現(xiàn)在也有很多了，像第一5.6的方案，5.6也是一個(gè)半成品的方案，也不能解決很多瓶頸，能解決一些特定的瓶頸。二個(gè)以為代表的第三方工具，還有sharding,把你的數(shù)據(jù)弄的更小這也是一個(gè)比較好的方案。
這是5.6和5.7的并行復(fù)制的優(yōu)化，5.6剛才提到一個(gè)比較麻煩的問題，假設(shè)我是一個(gè)，你就不能用了，5.6只能根據(jù)一個(gè)副題復(fù)制，我有十個(gè)我可以取十個(gè)點(diǎn)，這樣只有一個(gè)庫你開不開沒什么區(qū)別。另外一個(gè)5.7說起來比較復(fù)雜，5.7基于，這種方式是可以跳出副題復(fù)制的。它并行率是非常高的，5.7是一個(gè)相對比5.6好很多的并行復(fù)制解決方案。
MySQL除了復(fù)制，下面還有很多，很多人聽說過的幾類，這類似的方案有很多。怎么去選擇？從兩個(gè)方面去考慮，你需不需要支持，比如說如果你哪個(gè)不需要，用MySQL就可以了。如果你對這種需要多點(diǎn)寫入，類似于需要一些MySQL這種方式。對比這個(gè)，做這個(gè)圖可以去選擇，合適的復(fù)制方式。
這個(gè)是半同步，半同步的話，比原生復(fù)制多了一點(diǎn)，從這個(gè)時(shí)間里面可以看出來，上面就是原生，寫到從頭不管了，下面就是半同步，半同步是需要同步其中有一個(gè)同步，是需要返回的，所以安全性比較可靠的。
半同步復(fù)制優(yōu)化在5.6和5.7有很多的，5.6還是一個(gè)同步，5.7可以設(shè)置多個(gè)同步。這樣的話安全性可以更好地去保證。下面就是對半同步更好的優(yōu)化。最后通過改進(jìn)5.6的MySQL提升半同步的性能。
這就是MySQL5.7,這個(gè)是官方提供的多主復(fù)制方案，現(xiàn)在5.7已經(jīng)有了，是可以達(dá)到多組同步復(fù)制化。如果說這個(gè)東西以后能做得好一點(diǎn)的話，會是一個(gè)比較好的方案。
下面是InnoDB的引擎優(yōu)化，ACID也是目前做得比較好的引用，包括一些特性或者變化，或者是MVCC的一些支持都是非常好的。一些主要參數(shù)，主要參數(shù)是跟性能有關(guān)的基本就這幾個(gè)，5.6加了一些，變化不是特別大。這個(gè)圖就是不同redo,這個(gè)圖左邊是redolog5.5限制不能超過4G,這樣的話，在這種壓力的時(shí)候可控還是有的，每一段時(shí)候會刷一次，就會有一次性能對比，大的時(shí)候，刷的頻率就會低很多，就會平穩(wěn)很多。
這個(gè)圖是SSD上的優(yōu)化，這也是不太需要優(yōu)化的。后面這幾點(diǎn)，InnoDB壓縮和cgroup這還是需要的使用單機(jī)多實(shí)例，都是非常有需要的。
這個(gè)是現(xiàn)在MySQL5.6最新5.7版本，它在一些比較重要的參數(shù)上都有一些重要改進(jìn)。說幾個(gè)，第一個(gè)在5.6的時(shí)候還是一樣，5.7已經(jīng)默認(rèn)。這樣安全性會比之前版本黑更好，而且是已經(jīng)默認(rèn)參數(shù)。下面還有一些預(yù)熱這部分也都是默認(rèn)，還有一個(gè)也比較全部改。下面一個(gè)也已經(jīng)改了，這樣數(shù)據(jù)安全性會更好。
下面再說一個(gè)，TokuDB.InnoDB的特點(diǎn)，是一種基于結(jié)構(gòu)，正是因?yàn)檫@個(gè)原因，所以寫入密集場景非常好，并且壓縮都是非常不錯(cuò)，也是原生支持，還是有很多吸引人的地方。下面就是主流分支都支持，官方目前最新版本應(yīng)該是這樣，已經(jīng)默認(rèn)了。
MySQL壓縮的我們做的一個(gè)對比，MySQL有三種。移動(dòng)也是壓縮，它壓縮是用到中間這種方式，右邊圖就是一個(gè)對比，可以看到，壓縮比是最好的黃色的，比另一個(gè)小好一些，好兩到三倍。現(xiàn)在使用的時(shí)候，都會使用這種InnoDB來做，寫字優(yōu)化是非常好的。
這個(gè)就是我們之前做的一個(gè)MySQL寫入性能對比?？梢钥吹缴厦鎺讉€(gè)陡的都是InnoDB,一開始特別高的是另外一個(gè)。很多可以看到InnoDB一開始跟他只明白四、五千，而TokuDB在整個(gè)過程中都是非常穩(wěn)定。
TokuDB有一些問題，還是有不少漏洞，現(xiàn)在版本更新非常快，所以更新面還是要謹(jǐn)慎使用。
最后說一下數(shù)據(jù)庫存儲變遷，近幾年也是變化非?？斓?，還有一個(gè)集中式分布式的演進(jìn)，這個(gè)東西也是一個(gè)過程，不是誰好誰壞的過程，也是一個(gè)相互演進(jìn)的過程。比如像最早的機(jī)械硬盤時(shí)代，從誕生到2001年之前都是在機(jī)械硬盤，機(jī)械硬盤也比較差，前三、四年發(fā)展，來適應(yīng)這種機(jī)械硬盤的讀寫特性，但是隨著互聯(lián)網(wǎng)的發(fā)展，它的瓶頸越來越明顯，當(dāng)時(shí)最多的一個(gè)上面，掛20多以上，全是機(jī)械硬盤，掛20多個(gè)一旦出現(xiàn)一些緩存問題，還是不行，單一性實(shí)在太差。這種性能問題，導(dǎo)致你需要批判，因?yàn)槟阈阅芴螅瑪?shù)據(jù)太小，滿足你業(yè)務(wù)的一個(gè)需求。
后來就是閃存時(shí)代，最早是NAND技術(shù)出現(xiàn)，互聯(lián)網(wǎng)是最新開始吃螃蟹，在2001年的時(shí)候，成本高很多，每GB很高，它的也是非常明顯，有擊敗被的提升。所以說在當(dāng)時(shí)閃存剛剛起步的時(shí)候，主要性還是保持一個(gè)懷疑。后面再往下發(fā)展，混合存儲，閃存還是太貴了，手機(jī)成本節(jié)約，會出現(xiàn)混合存儲，代表性就是用SSD的緩沖來解決這樣一個(gè)問題。你的讀寫最好有比較明顯的熱點(diǎn)，微博這幾年也用過兩年多，當(dāng)然中間還是有很多問題。下面就說到問題，運(yùn)維SSD的壽命還是非常大。
責(zé)任就是現(xiàn)在的時(shí)代，閃存2.0時(shí)代都不是問題，成本低，基本上都采用SSD這種方式。
SSD肯定還會有人懷疑，隨著SSD出現(xiàn)就有問題，SSD壽命會不會有問題，肯定會有問題，有一個(gè)極限，如果你買SSD產(chǎn)品你寫80T都有限制，當(dāng)然這個(gè)東西對你業(yè)務(wù)來說你要算一下能夠扛多少年，你算算能寫好多年，這個(gè)壽命不太需要考慮。第二個(gè)SSD比HDD會不會更可靠，這是非常顯然的，肯定是可靠，因?yàn)樗囊恍﹩栴}，非常容易出現(xiàn)磁盤的損害，非常容易出現(xiàn)，整體比SSD低很多。第三故障率，很快剛才一樣比HDD要好很多，所以現(xiàn)在不用需要懷疑。
為什么要采用善存，因?yàn)檫@種人還是要比機(jī)器貴，人你要算工資，機(jī)械材料便宜。
最后說一下分布式存儲，這個(gè)我們之前也測試過，基于MySQL,我覺得它在未來這幾年也是一個(gè)不錯(cuò)的方向，它對于規(guī)律和數(shù)據(jù)庫的收縮性都是非常有好處的。當(dāng)然它的缺點(diǎn)或者它一個(gè)風(fēng)險(xiǎn)，你發(fā)現(xiàn)它放在一個(gè)里面，當(dāng)然技術(shù)發(fā)展這個(gè)問題肯定會逐漸解決的。
這就是之前好多人問的，我們當(dāng)時(shí)在微博上搞了60億表的問題，當(dāng)然數(shù)據(jù)也是比較核心，數(shù)據(jù)也都是這種粉飾。所以它單表的話，單表的數(shù)在60億以上，原因也有很多。DB比較懶，導(dǎo)致的問題，但是還有一個(gè)想看看極限，到底能到多少。這個(gè)東西其實(shí)不大，確實(shí)是有風(fēng)險(xiǎn)，我們也清楚，一個(gè)單表恢復(fù)，這個(gè)肯定有風(fēng)險(xiǎn)，但是你的方案足夠成熟，其實(shí)也都是可以接受的。這個(gè)東西在你當(dāng)前能解決問題的情況下，沒必要搞一些過于超前的方案。能解決問題的情況下，或者在你能力范疇之內(nèi)，能解決問題，就可以了。
最后就是總結(jié)，你整個(gè)數(shù)據(jù)庫的標(biāo)準(zhǔn)化或者自動(dòng)化，在早期都需要關(guān)注的，第二個(gè)平臺化和服務(wù)化也是做了一個(gè)基礎(chǔ)平臺主要目標(biāo)，優(yōu)化也是無止境的，還有適合自己才是最好的。所以說有時(shí)候拿著錘子不要看所有東西都是釘子，要選擇自己合適的，要選擇自己把控的東西，不要為了嘗試一些新技術(shù)而去嘗試，很多東西都是有成本的。
這是我的微博、微信，有興趣可以加一下。
主持人：到現(xiàn)在時(shí)間過得挺快的，這兩天的全部正式環(huán)節(jié)就到這結(jié)束了，再次謝謝大家支持！還有一些非正式的環(huán)節(jié)，臨時(shí)加上去一個(gè)環(huán)節(jié)是，我這邊除了今天還沒有因?yàn)橐s著回去的嘉賓留下了，我也把七牛輕易不上臺的技術(shù)大牛請過來，我剛在群里說了，有什么問題大家盡管問，現(xiàn)在留下的，從這邊據(jù)說是大數(shù)據(jù)領(lǐng)域最帥的技術(shù)大咖，七牛技術(shù)總監(jiān)陳超大家也聽他演講了，還有CEO,還有攜程等嘉賓，大家有什么問題可以盡管問，咱們多準(zhǔn)備幾個(gè)話筒。