雷鋒網(wǎng)注：作者朱赟，硅谷 Airbnb 資深美女程序媛一枚。

題圖：Mark Bird

前兩天 Uber post 了一篇文章，說(shuō)他們從 Postgres SQL 轉(zhuǎn)到使用 MySQL 了。blog 寫(xiě)得不錯(cuò)，科普了一些 DB indexing 和 replication 的基本常識(shí)。當(dāng)時(shí)轉(zhuǎn)給一個(gè)朋友看，朋友說(shuō)，其實(shí) Uber  2013年才發(fā)了一篇文章說(shuō)他們從 MySQL 轉(zhuǎn) Postgres SQL。遂去找來(lái)看了?？赐旰髮に枷拢鋵?shí)兩篇文章背后的情況，兩次轉(zhuǎn)型的文章背后的原因，也就可以揣測(cè)一二了。

作為兩大主流開(kāi)源數(shù)據(jù)庫(kù)，MySQL 和 Postgres 的 “戰(zhàn)爭(zhēng)” 從來(lái)沒(méi)有停止過(guò)，雖然硝煙不似程序語(yǔ)言之間的斗爭(zhēng)那么濃烈。你可以去 Quora 或者 Stack Overflow 上搜相關(guān)的 MySQL v.s. Postgres 帖子，特別多。我的感覺(jué)是，各有各的優(yōu)勢(shì)和實(shí)用場(chǎng)景，并沒(méi)有一種比另一種有壓倒性?xún)?yōu)勢(shì)的存在。

對(duì)于大部分程序員來(lái)說(shuō)，公司用哪個(gè) DB，基本不太輪到你來(lái)做決定。你加入一個(gè)公司的時(shí)候，除非是創(chuàng)業(yè)公司，或者你是 CTO、VP、Director 級(jí)別的，否則大部分的技術(shù)選型都應(yīng)該早已經(jīng)塵埃落定了的。尤其是 DB，一旦選擇，再遷移的代價(jià)就很大。所以除非有了顛覆性的優(yōu)勢(shì)或者問(wèn)題，很少有公司會(huì)去費(fèi)時(shí)費(fèi)力做這種大的遷移。而不論是選型還是轉(zhuǎn)型，一個(gè)不可忽略的因素，就是你招到的工程師更能駕馭哪一種技術(shù)，或者有話(huà)語(yǔ)權(quán)的決策者們傾向于哪一種技術(shù)。這其實(shí)和程序語(yǔ)言的選型多少有著異曲同工的類(lèi)似。

其實(shí) Uber 兩次高調(diào)轉(zhuǎn)型，類(lèi)似的事情在 Square 也發(fā)生過(guò)。雖然 Square 最早是使用 MySQL，但是在大概在 2012 年間，因?yàn)?Postgres 的各種優(yōu)勢(shì)（如對(duì) geospatial 數(shù)據(jù)及搜索的支持等），以及當(dāng)時(shí)幾位比較 senior 的工程師的大力倡導(dǎo)，很多新的 service 都嘗試性地選擇了使用 Postgres。所以當(dāng)時(shí)公司的架構(gòu)是 MySQL 和 Postgres 并存。對(duì)于那時(shí)候的我而言，不過(guò)是有機(jī)會(huì)學(xué)習(xí)、了解、和比較兩個(gè)不同的技術(shù)。兩者各有特點(diǎn)，有些東西在 MySQL 里似乎更方便，另一些則反之?？傆蟹桨溉?shí)現(xiàn)，并沒(méi)有覺(jué)得非要哪一種才行。

DB 若安好，便是晴天。

一個(gè)公司，如果 DB 從來(lái)不出問(wèn)題。那肯定是因?yàn)闆](méi)有業(yè)務(wù)或者流量。所有的技術(shù)，都有它設(shè)計(jì)的應(yīng)用場(chǎng)景。除了一些 happy case，就一定有坑。能夠盡可能地避免這些坑，或者在出問(wèn)題的時(shí)候能夠最快修復(fù)，就成了至關(guān)重要的因素。Square 兩種 DB 并存的期間，公司里 Postgres 的牛人寥寥無(wú)幾。但是 MySQL 的 experts，卻有幾個(gè)極為靠譜的。大部分工程師，并不是數(shù)據(jù)庫(kù)專(zhuān)家，Postgres 和 MySQL 的相對(duì)優(yōu)勢(shì)，對(duì)我們而言，都比不過(guò)出問(wèn)題的時(shí)候有人解惑或者救火來(lái)的重要。何況一個(gè)公司維系兩套同類(lèi)的數(shù)據(jù)庫(kù)系統(tǒng)本身就是個(gè)負(fù)擔(dān)。因此，這些使用 Postgres 的 service 后來(lái)又都慢慢轉(zhuǎn)成 MySQL 了。

因?yàn)槲覀?strong>做支付的需要強(qiáng) transactional 的支持，所以不太會(huì)用 NoSQL 類(lèi)型的，主要用的還是 MySQL 或者 Postgres。雖說(shuō)數(shù)據(jù)庫(kù)相關(guān)的知識(shí)和技術(shù)，現(xiàn)在工作中因?yàn)橛玫枚?，慢慢也了解了不少，但如果真的線上出了問(wèn)題，自己還是不太擺得平。好在每個(gè)公司都會(huì)有一些數(shù)據(jù)庫(kù)大牛，有的公司叫做 DBA。很多中小公司并沒(méi)有專(zhuān)職的 DBA，都是做系統(tǒng)的人監(jiān)管。有幾位私交甚好。加上自己平時(shí)系統(tǒng)里相關(guān)問(wèn)題也經(jīng)常需要請(qǐng)教，所以一來(lái)二去知道了好些好玩的事情。

對(duì)數(shù)據(jù)庫(kù)大牛我一向是抱景仰的態(tài)度的。公司只要稍具規(guī)模，數(shù)據(jù)庫(kù)這塊做不好，基本也就沒(méi)啥好玩的了。這一塊不出問(wèn)題也罷，一出問(wèn)題，基本就是見(jiàn)血封喉，網(wǎng)站直接掛掉。那么平時(shí)最常見(jiàn)的都有哪些問(wèn)題呢？

首先就是選型。

每個(gè)公司因?yàn)闃I(yè)務(wù)的不同，數(shù)據(jù)庫(kù)系統(tǒng)應(yīng)用場(chǎng)景不一樣，哪一種最合適就不一樣。沒(méi)有哪一個(gè)系統(tǒng)一定是最好的。比如做支付的一定要強(qiáng)事務(wù)性、一致性的支持，而很多社交平臺(tái)更多時(shí)候其實(shí)是需要高可用；有的業(yè)務(wù) writes 特別 heavy，有的業(yè)務(wù)更重要的是 reads；有些業(yè)務(wù)可以只關(guān)心最近幾天的數(shù)據(jù)，因此可以 tradeoff 老數(shù)據(jù)讀寫(xiě)的低效，有的卻要頻頻 access 歷史數(shù)據(jù)；有些業(yè)務(wù)可以通過(guò)加 index 解決 query 效率，有些卻只能通過(guò)加緩存等等。。這也是為什么很多公司有多個(gè)數(shù)據(jù)庫(kù)系統(tǒng)并存，以最優(yōu)化對(duì)每個(gè)場(chǎng)景和業(yè)務(wù)的支持。

選型錯(cuò)了，基本就掉在坑里了，也沒(méi)有頻頻踩坑一說(shuō)了。

另外一個(gè)就是相關(guān)架構(gòu)。

什么意思呢？這里包括數(shù)據(jù)庫(kù)上層的 cache 系統(tǒng)的設(shè)計(jì)，程序語(yǔ)言對(duì) DB connection 的處理，proxy layer（如果存在）的功能，以及和 binlog 等相關(guān)的 data pipeline 的搭建。當(dāng)然，也包括數(shù)據(jù)庫(kù)系統(tǒng)的分區(qū)、備份等的具體設(shè)計(jì)。很多公司早期所有的 table 都在一個(gè) DB 里面，因?yàn)楦鞣N connection pool 和 throughput 的限制，這其實(shí)基本沒(méi)法 scale。能夠合理的安排不同 table 的分離，讓數(shù)據(jù)相關(guān)的留在一起，不相關(guān)的或者不太相關(guān)的放在另一個(gè) DB 里。類(lèi)似這些很簡(jiǎn)單的道理，很多時(shí)候卻可以很大程度上緩解 scalability 的問(wèn)題。

而平時(shí)我們遇到的最多的問(wèn)題，還是 human mistake.

再好的系統(tǒng)，使用姿勢(shì)不對(duì)，也是枉然。何況并不是所有的工程師都是數(shù)據(jù)庫(kù)專(zhuān)家。

人為錯(cuò)誤分成兩種。

一種是 DB operation 中犯的錯(cuò)誤。

這種概率比較低，但是通常危害卻最大。幾乎所有的公司都會(huì)有類(lèi)似的傳奇，常見(jiàn)的版本有：

• 某某工程師或無(wú)意或有意，“不小心” 刪掉了數(shù)據(jù)庫(kù)某 core table 中所有的數(shù)據(jù)。不是開(kāi)玩笑，這種事 Facebook 也發(fā)生過(guò)，還是一個(gè)朋友。好在后來(lái)恢復(fù)了。這事也成了他的工程師歷史上光輝的一筆。

• 某某工程師做 online schema change 的時(shí)候，不小心有一步誤操作。結(jié)果數(shù)據(jù)庫(kù)被 lock 長(zhǎng)達(dá)幾個(gè)小時(shí)。該公司網(wǎng)站也就掛了好幾個(gè)小時(shí)。

• 最后這個(gè)版本聽(tīng)國(guó)內(nèi)一個(gè)大公司的朋友說(shuō)的，細(xì)節(jié)還真是不記得了。只是記得兩臺(tái)服務(wù)器，做 master slave switch 還是什么的時(shí)候，拔錯(cuò)了一個(gè)電源插頭，然后......就沒(méi)有然后了。

另一種是程序員程序里或者腳本里犯的錯(cuò)誤。

這個(gè)就很常見(jiàn)了。舉個(gè)很簡(jiǎn)單的例子。我們知道 Ruby on Rails 對(duì)數(shù)據(jù)庫(kù)的 access 基本是通過(guò) Active Record 來(lái)完成的。Active Record 可以通過(guò)一個(gè) connection pool 來(lái)限制每個(gè) application 到 DB 的 connection。如果某一個(gè)程序或者腳本中的 query 是查詢(xún)沒(méi)有被 index 的數(shù)據(jù)，而導(dǎo)致 full table scan，加上一些 web server 的并行的實(shí)現(xiàn)，很經(jīng)常就會(huì)有整個(gè) DB 的所有 connection 被占用，連 kill query 都沒(méi)法執(zhí)行。只能人肉的去做一些類(lèi)似重啟的操作。還有更常見(jiàn)的，就是程序里的 N+1 query。這些都很無(wú)語(yǔ)，但若說(shuō)你從沒(méi)遇到過(guò)，那可能是……呵呵。

最后一種，也就是自然流量增長(zhǎng)或者流量突增造成的數(shù)據(jù)庫(kù)訪問(wèn)瓶頸。

只要是數(shù)據(jù)庫(kù)，就有 throughput 的限制。只要你的業(yè)務(wù)在增長(zhǎng)，總有一天數(shù)據(jù)庫(kù)訪問(wèn)就會(huì)達(dá)到一個(gè)上限。所以在這個(gè)預(yù)警到來(lái)前，就要做各種 horizontal 或者 vertical 的 scale 來(lái)不斷提升這個(gè)上限?；蛘呤峭ㄟ^(guò)緩存等其他機(jī)制來(lái)對(duì)訪問(wèn)量進(jìn)行分流。這里面可以做的東西就多了。覺(jué)得可以單獨(dú)寫(xiě)一篇了。

另一種就是類(lèi)似 DDoS、Marketing 等等帶來(lái)的各種流量的突增。如果是有計(jì)劃的 Marketing 等，就需要提前做好各種戰(zhàn)斗準(zhǔn)備。如果是惡意攻擊，那就只能靠各種防御工程（如 IP blocking 等等）擋掉這些訪問(wèn)來(lái)保證數(shù)據(jù)庫(kù)正常工作了。

最后，推薦一個(gè) DBA 寫(xiě)的博客網(wǎng)站，內(nèi)容很精彩，有技術(shù)有情懷。文章寫(xiě)的比我好多了。

雷鋒網(wǎng)注：本文由作者授權(quán)雷鋒網(wǎng)發(fā)布，轉(zhuǎn)載請(qǐng)聯(lián)系授權(quán)并保留出處和作者，不得刪減內(nèi)容。

雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見(jiàn)轉(zhuǎn)載須知。