美圖網(wǎng)楊尚剛：數(shù)據(jù)庫運維和性能優(yōu)化之路

互聯(lián)網(wǎng)IDC圈9月2日報道，8月29日-30日在上海國際時尚中心舉行的D-Future數(shù)據(jù)時代峰會是七牛為大家?guī)淼囊粓鰯?shù)據(jù)盛筵，匯聚了業(yè)界領(lǐng)袖、行業(yè)專家，他們將從產(chǎn)業(yè)的角度和技術(shù)的角度來解讀數(shù)據(jù)從何而來，數(shù)據(jù)如何應(yīng)用，數(shù)據(jù)重新構(gòu)未來。

創(chuàng)新互聯(lián)公司是一家專業(yè)提供馬龍企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、成都網(wǎng)站設(shè)計、H5建站、小程序制作等業(yè)務(wù)。10年已為馬龍眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站建設(shè)公司優(yōu)惠進行中。

數(shù)據(jù)庫優(yōu)化是一個很大的問題，迄今為止一直困擾著所有的數(shù)據(jù)庫管理員和程序員。會上美圖網(wǎng)的楊尚剛跟大家分享了數(shù)據(jù)庫運維和性能優(yōu)化方面的內(nèi)容。

楊尚剛

以下是楊尚剛演講內(nèi)容（根據(jù)速記整理）：

楊尚剛：我今天最后一場，我今天主要講的數(shù)據(jù)庫運維和性能優(yōu)化的一些東西。下面是我的微博，有興趣可以加一下。

我2011年加入新浪，在新浪待了四年，主要是負責新浪微博的一些核心數(shù)據(jù)庫架構(gòu)設(shè)計，還有新浪數(shù)據(jù)平臺底層軟件優(yōu)化，今年加入了美圖，美圖大家都知道，美圖現(xiàn)在兩款產(chǎn)品，一個美圖秀秀還有一個美拍，現(xiàn)在用的人也非常多，這邊我也是負責后數(shù)據(jù)存儲的平臺建設(shè)。下面兩張圖比較形象，相當于好多人都認為從左邊這張圖開始干，理想是右邊，或者是更高級別的人物。

MySQL優(yōu)點使用更簡單，第二個免費。這兩個是MySQL現(xiàn)在應(yīng)用非常廣泛的原因。第三個擴展性好，當然這個擴展性加引號，但是一旦你的規(guī)模達到上百萬、上千臺的時候，擴展因素打一個折扣，面臨著一些挑戰(zhàn)。第四個社區(qū)比較活躍，這個非常顯然，這也是為什么現(xiàn)在PG沒有比MySQL更廣泛的原因，PG我也承認肯定比MySQL要好，但是你的社區(qū)一旦做得不好的話，還是非常不好的，酒香不怕巷子深。社區(qū)活躍是一個非常重要的點。最后一個MySQL雖然有非常多的問題，但是在現(xiàn)有的情況下MySQL還是依然能夠滿足我們現(xiàn)在大多數(shù)用戶的需求。

說完它的優(yōu)點再說它的缺點，第一它對復(fù)雜所謂支持不好，MySQL還是挺差的，之前我不知道有沒有人看到，對一個語句，40條或者200條，肯定是40條快一些，反饋200條快一些這就是MySQL比較坑人的地方。第二對于SQL標準。第三個大規(guī)模集群方案不成熟，主要是知識面的支持上，官方?jīng)]有一個很好的支持，還需要很多開元的二次開放才能支持好。下面這幾個，ID生成器這個也不是那么重要。這個和方案相比，還是相對差一些。下面就是Online DDL這也是MySQL比較大的一個痛點，MySQL就會比較麻煩。下面是HA方案，MySQL沒有一個非常可靠的方案，很多還需要依賴第三方工具。下面就是備份恢復(fù)這個也是比較復(fù)雜，展示機構(gòu)少，這個時候比較被動，下面就是分支。

下面再說雖然有這么多問題，MySQL還是很受歡迎。第一個可靠性，第二經(jīng)過大規(guī)模部署的驗證，這種都已經(jīng)在線上通過大規(guī)模的生產(chǎn)考驗，所以大家都是認可的。下面這兩個是比較支持的，找踩坑，很多技術(shù)都是并不是說它怎么著，還是需要看一下其他人的經(jīng)驗。這個就是DBAlife，比如像各種各樣開發(fā)需求，各種各樣的需求，你還得去滿足。各種各樣需求。下面就是SQL優(yōu)化，也是DBA工作人員很大一部分，下面就是各種救火和故障，你的主庫故障，各種各樣問題，都是需要DBA去介入的。下面就是一些各種業(yè)務(wù)，項目上線，還有日常的溝通。

怎樣能變得不苦呢？DBA涉及到各種更改和創(chuàng)建，它占了很多時間。如何去解放DBA的雙手，主要是兩個部分，第一建立數(shù)據(jù)庫開發(fā)規(guī)范，第二個把固化基本原則到自動化審核流程里去，減少DBA的溝通成本和一些重復(fù)工作。

這是數(shù)據(jù)庫開發(fā)規(guī)范，現(xiàn)在網(wǎng)上也有很多，我就不細說了，說說它的意義，數(shù)據(jù)庫開發(fā)規(guī)范，保證線上的規(guī)模是統(tǒng)一的，是遵守創(chuàng)業(yè)規(guī)范的。這樣對于你后面一些都是非常有好處的。這個開發(fā)規(guī)范如何去遵守，這個也是需要DBA去投入經(jīng)歷的，這個東西，雖然開發(fā)者會去看這個東西，這個就需要DBA主動去推這個東西，定期給開發(fā)培訓(xùn)，開發(fā)能夠認識到規(guī)范一個重要性，也能減少DBA后續(xù)運維的一個成本。

這是一個簡單的規(guī)范示例，主要是一些表情選擇，還有定義，當然肯定比這個復(fù)雜多，如果你把規(guī)范定得很詳細的話。

DDL自動化有三個部分，建表、審表和改表這都是日常的需求。這是一個主要流程，提交DDL，首先你系統(tǒng)里面會做一些語法檢測，肯定還是要打回去要重新去改，語法通過，這些動作如果沒自動化就需要DDL打電話發(fā)郵件，這部分工作就是看它是否符合開發(fā)規(guī)范，剛才提到的自己的選擇，這部分不過的話，也是需要開發(fā)再去修改，開發(fā)修改的話，可以去線上支持。當然這里還會設(shè)置關(guān)于操作，比如你去做表還是發(fā)表一些創(chuàng)建的操作，要區(qū)分這個東西，這個操作還是盡量讓開發(fā)直接去搞，開發(fā)肯定意識到了操作，如果是的話可能就需要DDL的選擇，做一些提前預(yù)案這些東西。

當然剛才提的問題也是DDL的問題，MySQL是內(nèi)部不支持的，960的DDL，很多實際在生產(chǎn)上用的話，還是有比較大的距離。為什么MySQL會有非常大的問題呢？它需要一個鎖，一旦你去執(zhí)行這些操作的時候，都是要組織表，而組織這個過程中，你不能再往里面寫數(shù)據(jù)。你的業(yè)務(wù)數(shù)據(jù)是不能服務(wù)的，這樣一般產(chǎn)品是不能接受的，所以這個是MySQL一個比較大的問題。

當然現(xiàn)在也有一些方案，比如像基于FacebookOSC的原理，下面表格主要和做對比，其他兩個5.6的是不支持的，官方內(nèi)置的這些東西，但是它的問題還是比較多的。包括解決不了DDL延時問題，還有用了也會有影響。比較多的是基于FacebookOSC的延伸體。

這個是OSC的原理，還是比較敞亮的。一開始核心是下面部分，調(diào)整塊大小，同步數(shù)據(jù)，根據(jù)覆負載調(diào)整進度，一個比較核心。后面或者前面都是一些準備步驟，或者是一些簡單的操作?？匆幌翸ySQL另外一個，慢日志，如果你要去做的話，很多都要根據(jù)慢日志去做的，如果有一個系統(tǒng)的話，發(fā)現(xiàn)某一個你就得去判斷，看一下，有沒有慢日志，這個基本上是一個比較常規(guī)的過程。

而這個里面很多步驟都是可以去自動化做掉的，這個的話，慢日志化系統(tǒng)，根據(jù)慢日志化系統(tǒng)開發(fā)，負責業(yè)務(wù)。

這個算一個基本系統(tǒng)架構(gòu)，基本上主要依賴這個是分析MySQL比較好的，分析的結(jié)果也是非常詳細，報表也是比較好用。

第二個Logstash，都可以。第三個Anemometer，開了一個系統(tǒng)，右邊這個圖就是基本的數(shù)據(jù)流程，也是非常簡單，基本上就是數(shù)據(jù)和入庫各種展示。

這個就是簡單的頁面，最上面是兩個時間段的情況。比如昨天某個時間，下面框就是它提供的哪些展示，也可以定制。中間這個根據(jù)IP都可以去調(diào)整。下面是一些展示的過程，一個例子。這個就是你點進去某一個，它的變化曲線，在什么時候比較多都可以看到，包括也可以看到，在這可以直接點出來，它的結(jié)果，不需要再線上去看，掃描或者有沒有都可以在這里面看到。所以說還是比較方便的。

另外一個的變化就是備份系統(tǒng)，備份系統(tǒng)是做這個行業(yè)首先要保證的，首先性能不是最重要的，安全是最重要的。所以備份都是最重要的。悲憤意義，很簡單就是我為了數(shù)據(jù)恢復(fù)。下面?zhèn)浞莸姆绞剑琈ySQL備份方式也非常多，沒有官方的一些支持，也是各種各樣，像全量、增量、熱備和冷備，物理和邏輯，延時，這種方式都是針對不同方式去做的。建立方式，基于熱備加物理是更好的。如果能做出來最好，不能做的話，熱備加物理也可以滿足很多需求。如果你一些非常和核心的業(yè)務(wù)，考慮用組合的方式。

M：這是備份系統(tǒng)數(shù)據(jù)，在新浪做的系統(tǒng)，每年備份數(shù)據(jù)，做7000加次擴容，每年要做12加次數(shù)據(jù)恢復(fù)，當然這個東西，實踐很多開發(fā)不注意，都可能導(dǎo)致不良的后果。數(shù)據(jù)量的話，每日志量每天3TB，數(shù)據(jù)總量在2PB，每天悲憤數(shù)據(jù)量百TB級。

備份優(yōu)化我們主要做下面幾個部分，第一主主要悲憤策略集中式調(diào)度管理，對格式化都不太好，還有熱備至四，統(tǒng)計分析，還有校驗問題，最后采用分布式文件系統(tǒng)存儲備份。我們當時也調(diào)研過其他的，最終權(quán)利選擇了這種。

當然分布式文件系統(tǒng)，之所以要用也是有一些痛點，下面幾點，存儲分配的問題，當時已經(jīng)存儲了六、七十臺左右，你在真的需要存儲管理容量，都需要人工去管理，能自動化但是做的不是特別好，還是比較復(fù)雜。NFS這個還是導(dǎo)致經(jīng)常負載特別高，備份效率特別低，下面還是存儲集中式管理，最后數(shù)據(jù)可靠性更好，可能會比單點問題會有好處的。

當然我們使用分布式系統(tǒng)我們也做了優(yōu)化，第一個采用Pbzip壓縮比能做到三分之一，降低多副本存儲帶來的存儲成本，第二個使用壓縮之后，降低網(wǎng)絡(luò)帶寬消耗。最后一個是erasure的方案調(diào)研，使用這種方案，也都比較成熟。右邊是一個簡單的架構(gòu)圖。

提到MySQL版本問題，MySQL版本現(xiàn)在是說官方有兩個一個社區(qū)版、一個企業(yè)版，還有其他兩個，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ū)版還是有一定的差距。

這個是MySQL主流版本，當然之前那些都比較老了，5.0、4.幾現(xiàn)在主流的是5.0。現(xiàn)在主流的就是5.6和5.5，現(xiàn)在一般用5.6就可以了，也是一個比較穩(wěn)定的版本。5.5的話，是保守用5.5。

下面是MySQL復(fù)制問題，MySQL復(fù)制的話，好多人都會遇到一個比較坑，MySQL復(fù)制延遲問題和MySQL安全問題。

MySQL復(fù)制采用一些不可靠的投遞，不管有沒有執(zhí)行這些問題都會存在，所以說安全性還有延時問題被很多人詬病的一個點。

下面的圖就是它的一個框架，右面紅框里面就是瓶頸原因，使用或者概念。

這種概念的簡化，現(xiàn)在也有很多了，像第一5.6的方案，5.6也是一個半成品的方案，也不能解決很多瓶頸，能解決一些特定的瓶頸。二個以為代表的第三方工具，還有sharding，把你的數(shù)據(jù)弄的更小這也是一個比較好的方案。

這是5.6和5.7的并行復(fù)制的優(yōu)化，5.6剛才提到一個比較麻煩的問題，假設(shè)我是一個，你就不能用了，5.6只能根據(jù)一個副題復(fù)制，我有十個我可以取十個點，這樣只有一個庫你開不開沒什么區(qū)別。另外一個5.7說起來比較復(fù)雜，5.7基于，這種方式是可以跳出副題復(fù)制的。它并行率是非常高的，5.7是一個相對比5.6好很多的并行復(fù)制解決方案。

MySQL除了復(fù)制，下面還有很多，很多人聽說過的幾類，這類似的方案有很多。怎么去選擇？從兩個方面去考慮，你需不需要支持，比如說如果你哪個不需要，用MySQL就可以了。如果你對這種需要多點寫入，類似于需要一些MySQL這種方式。對比這個，做這個圖可以去選擇，合適的復(fù)制方式。

這個是半同步，半同步的話，比原生復(fù)制多了一點，從這個時間里面可以看出來，上面就是原生，寫到從頭不管了，下面就是半同步，半同步是需要同步其中有一個同步，是需要返回的，所以安全性比較可靠的。

半同步復(fù)制優(yōu)化在5.6和5.7有很多的，5.6還是一個同步，5.7可以設(shè)置多個同步。這樣的話安全性可以更好地去保證。下面就是對半同步更好的優(yōu)化。最后通過改進5.6的MySQL提升半同步的性能。

這就是MySQL5.7，這個是官方提供的多主復(fù)制方案，現(xiàn)在5.7已經(jīng)有了，是可以達到多組同步復(fù)制化。如果說這個東西以后能做得好一點的話，會是一個比較好的方案。

下面是InnoDB的引擎優(yōu)化，ACID也是目前做得比較好的引用，包括一些特性或者變化，或者是MVCC的一些支持都是非常好的。一些主要參數(shù)，主要參數(shù)是跟性能有關(guān)的基本就這幾個，5.6加了一些，變化不是特別大。這個圖就是不同redo，這個圖左邊是redolog5.5限制不能超過4G，這樣的話，在這種壓力的時候可控還是有的，每一段時候會刷一次，就會有一次性能對比，大的時候，刷的頻率就會低很多，就會平穩(wěn)很多。

這個圖是SSD上的優(yōu)化，這也是不太需要優(yōu)化的。后面這幾點，InnoDB壓縮和cgroup這還是需要的使用單機多實例，都是非常有需要的。

這個是現(xiàn)在MySQL5.6最新5.7版本，它在一些比較重要的參數(shù)上都有一些重要改進。說幾個，第一個在5.6的時候還是一樣，5.7已經(jīng)默認。這樣安全性會比之前版本黑更好，而且是已經(jīng)默認參數(shù)。下面還有一些預(yù)熱這部分也都是默認，還有一個也比較全部改。下面一個也已經(jīng)改了，這樣數(shù)據(jù)安全性會更好。

下面再說一個，TokuDB。InnoDB的特點，是一種基于結(jié)構(gòu)，正是因為這個原因，所以寫入密集場景非常好，并且壓縮都是非常不錯，也是原生支持，還是有很多吸引人的地方。下面就是主流分支都支持，官方目前最新版本應(yīng)該是這樣，已經(jīng)默認了。

MySQL壓縮的我們做的一個對比，MySQL有三種。移動也是壓縮，它壓縮是用到中間這種方式，右邊圖就是一個對比，可以看到，壓縮比是最好的黃色的，比另一個小好一些，好兩到三倍?，F(xiàn)在使用的時候，都會使用這種InnoDB來做，寫字優(yōu)化是非常好的。

這個就是我們之前做的一個MySQL寫入性能對比?？梢钥吹缴厦鎺讉€陡的都是InnoDB，一開始特別高的是另外一個。很多可以看到InnoDB一開始跟他只明白四、五千，而TokuDB在整個過程中都是非常穩(wěn)定。

TokuDB有一些問題，還是有不少漏洞，現(xiàn)在版本更新非常快，所以更新面還是要謹慎使用。

最后說一下數(shù)據(jù)庫存儲變遷，近幾年也是變化非?？斓模€有一個集中式分布式的演進，這個東西也是一個過程，不是誰好誰壞的過程，也是一個相互演進的過程。比如像最早的機械硬盤時代，從誕生到2001年之前都是在機械硬盤，機械硬盤也比較差，前三、四年發(fā)展，來適應(yīng)這種機械硬盤的讀寫特性，但是隨著互聯(lián)網(wǎng)的發(fā)展，它的瓶頸越來越明顯，當時最多的一個上面，掛20多以上，全是機械硬盤，掛20多個一旦出現(xiàn)一些緩存問題，還是不行，單一性實在太差。這種性能問題，導(dǎo)致你需要批判，因為你性能太大，數(shù)據(jù)太小，滿足你業(yè)務(wù)的一個需求。

后來就是閃存時代，最早是NAND技術(shù)出現(xiàn)，互聯(lián)網(wǎng)是最新開始吃螃蟹，在2001年的時候，成本高很多，每GB很高，它的也是非常明顯，有擊敗被的提升。所以說在當時閃存剛剛起步的時候，主要性還是保持一個懷疑。后面再往下發(fā)展，混合存儲，閃存還是太貴了，手機成本節(jié)約，會出現(xiàn)混合存儲，代表性就是用SSD的緩沖來解決這樣一個問題。你的讀寫最好有比較明顯的熱點，微博這幾年也用過兩年多，當然中間還是有很多問題。下面就說到問題，運維SSD的壽命還是非常大。

責任就是現(xiàn)在的時代，閃存2.0時代都不是問題，成本低，基本上都采用SSD這種方式。

SSD肯定還會有人懷疑，隨著SSD出現(xiàn)就有問題，SSD壽命會不會有問題，肯定會有問題，有一個極限，如果你買SSD產(chǎn)品你寫80T都有限制，當然這個東西對你業(yè)務(wù)來說你要算一下能夠扛多少年，你算算能寫好多年，這個壽命不太需要考慮。第二個SSD比HDD會不會更可靠，這是非常顯然的，肯定是可靠，因為它的一些問題，非常容易出現(xiàn)磁盤的損害，非常容易出現(xiàn)，整體比SSD低很多。第三故障率，很快剛才一樣比HDD要好很多，所以現(xiàn)在不用需要懷疑。

為什么要采用善存，因為這種人還是要比機器貴，人你要算工資，機械材料便宜。

最后說一下分布式存儲，這個我們之前也測試過，基于MySQL，我覺得它在未來這幾年也是一個不錯的方向，它對于規(guī)律和數(shù)據(jù)庫的收縮性都是非常有好處的。當然它的缺點或者它一個風險，你發(fā)現(xiàn)它放在一個里面，當然技術(shù)發(fā)展這個問題肯定會逐漸解決的。

這就是之前好多人問的，我們當時在微博上搞了60億表的問題，當然數(shù)據(jù)也是比較核心，數(shù)據(jù)也都是這種粉飾。所以它單表的話，單表的數(shù)在60億以上，原因也有很多。DB比較懶，導(dǎo)致的問題，但是還有一個想看看極限，到底能到多少。這個東西其實不大，確實是有風險，我們也清楚，一個單表恢復(fù)，這個肯定有風險，但是你的方案足夠成熟，其實也都是可以接受的。這個東西在你當前能解決問題的情況下，沒必要搞一些過于超前的方案。能解決問題的情況下，或者在你能力范疇之內(nèi)，能解決問題，就可以了。

最后就是總結(jié)，你整個數(shù)據(jù)庫的標準化或者自動化，在早期都需要關(guān)注的，第二個平臺化和服務(wù)化也是做了一個基礎(chǔ)平臺主要目標，優(yōu)化也是無止境的，還有適合自己才是最好的。所以說有時候拿著錘子不要看所有東西都是釘子，要選擇自己合適的，要選擇自己把控的東西，不要為了嘗試一些新技術(shù)而去嘗試，很多東西都是有成本的。

這是我的微博、微信，有興趣可以加一下。

新聞名稱：美圖網(wǎng)楊尚剛：數(shù)據(jù)庫運維和性能優(yōu)化之路
當前URL：http://muchs.cn/article22/sdcpjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、微信小程序、外貿(mào)網(wǎng)站建設(shè)、定制網(wǎng)站、商城網(wǎng)站、移動網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)