06關(guān)于大型網(wǎng)站技術(shù)演進(jìn)的思考六存儲(chǔ)瓶頸

1、關(guān)于大型技術(shù)演進(jìn)的思考（六）-的瓶頸（6）在講數(shù)據(jù)庫(kù)水平拆分時(shí)候，我列出了水平拆分?jǐn)?shù)據(jù)庫(kù)需要解決的兩個(gè)難題，它們分別是主鍵的設(shè)計(jì)問題和單表查詢，主鍵問題前文已經(jīng)做了比較詳細(xì)的講述了，但是第二個(gè)問題我沒有講述，今天我將會(huì)講講如何解決數(shù)據(jù)表被水平拆分后的單表查詢問題。要解決數(shù)據(jù)表被水平拆分后的單表查詢問題，首先要回到問題的，為什么需要將數(shù)據(jù)庫(kù)的表進(jìn)行水平拆分。下面來推導(dǎo)下最終下定決心做水平拆分表的演進(jìn)過程，具體如下：第一個(gè)演進(jìn)過程：進(jìn)行了讀寫分離的表在數(shù)據(jù)增長(zhǎng)后需要進(jìn)行水平拆分嗎？回答這個(gè)疑問首先要想想進(jìn)行讀寫分離操作的表真的是因?yàn)閿?shù)據(jù)量大嗎？其實(shí)是否定的。最基本的讀寫分離的目的是為了解決數(shù)據(jù)庫(kù)的

2、某寫比率嚴(yán)重失衡，舉個(gè)例子，有一每天會(huì)增加 萬條數(shù)據(jù)，也就是說的系統(tǒng)每天會(huì)向這做 萬次寫的操作，當(dāng)然也有可能還會(huì)更新或者刪除這的某些已有的，這些操作 把它歸并到寫操作，那么這 一天 隨意定義個(gè)估值吧 萬 千次寫操作，其實(shí)這種表的數(shù)據(jù)量并不大，一年下來也就新增的幾百萬條數(shù)據(jù)，一個(gè)大型的商業(yè)級(jí)別的關(guān)系數(shù)據(jù)庫(kù)，當(dāng) 為表建立好索引和分區(qū)后，查詢幾百萬條數(shù)據(jù)它的效率并不低，這么說來查詢的效率問題還不一定是讀寫分離的 。其實(shí)啊，這 除了寫操作每天還承受的讀操作可能會(huì)是 萬， 萬甚至更高，這個(gè)時(shí)候問題來了，像 UXGIRK 和 這樣鼎鼎大名的關(guān)系數(shù)據(jù)庫(kù)默認(rèn)的最大連接數(shù)是 ，一般上了生產(chǎn)環(huán)境 可能會(huì)設(shè)置為 或

3、者 ，這些連接數(shù)已經(jīng)到了這些關(guān)系數(shù)據(jù)庫(kù)的最大極限了，如果再加以 ，數(shù)據(jù)庫(kù)性能會(huì)嚴(yán)重下降，最終很有可能導(dǎo)致數(shù)據(jù)庫(kù)由于壓力過大而變成了一個(gè)巨鎖，最終導(dǎo)致系統(tǒng)發(fā)生 的錯(cuò)誤，如是 就會(huì)想到采用讀寫分離方案，將數(shù)據(jù)庫(kù)的讀操作遷移到專門的讀 ，如果系統(tǒng)的負(fù)載指標(biāo)和我列舉的例子相仿，那么遷移的讀庫(kù)甚至不用做什么垂直拆分就能滿足實(shí)際的業(yè)務(wù)需求，因?yàn)?的目的只是為了減輕數(shù)據(jù)庫(kù)的連接壓力。第二個(gè)演進(jìn)過程：隨著公司業(yè)務(wù)的不斷增長(zhǎng)，系統(tǒng)的運(yùn)行的壓力也越來越大了， 已經(jīng)了解了系統(tǒng)的第一個(gè)瓶頸是從 開始了，如是 開始談?wù)摲桨溉绾谓鉀Q ，這時(shí) 發(fā)現(xiàn) 已經(jīng)做了讀寫分離，也使用了緩存，甚至連搜索技術(shù)也用上了，那么下個(gè)階段就是垂

4、直拆分了，垂直拆分很簡(jiǎn)單就是把表從數(shù)據(jù) 拆出來，單獨(dú)建庫(kù)建表，但是這種直截了當(dāng)?shù)姆桨赶胂刖湍芨械竭@樣的做法似乎沒有打中系統(tǒng)的痛點(diǎn)，那么系統(tǒng)的痛點(diǎn)到底是什么呢？根據(jù)數(shù)據(jù)庫(kù)本身的特性， 會(huì)發(fā)現(xiàn)痛點(diǎn)主要是三個(gè)方面組成：第一個(gè)方面：數(shù)據(jù)庫(kù)的連接數(shù)的限制。原庫(kù)的某些表可能承擔(dān)數(shù)據(jù)庫(kù) 的連接， 下甚至可以超過 的連接，而且這些表的業(yè)務(wù)操作十分的頻繁，當(dāng)其他小眾業(yè)務(wù)的表需要進(jìn)行操作時(shí)候，搞不好因?yàn)檫B接數(shù)被全部占用而不得不排隊(duì)等待空閑連接的出現(xiàn)，那么這個(gè)時(shí)候 就會(huì)考慮把這 做垂直拆分，這樣就減輕了原數(shù)據(jù)庫(kù)連接的壓力，使得數(shù)據(jù)庫(kù)連接負(fù)載變得比較均衡。第二個(gè)方面是數(shù)據(jù)庫(kù)的讀操作，第三個(gè)方面是數(shù)據(jù)庫(kù)的寫操作，雖然把

5、讀和寫分成兩個(gè)方面，但是這兩個(gè)方面在 做垂直拆分時(shí)候要結(jié)合起來考慮。首先 要分析下數(shù)據(jù)庫(kù)的寫操作，單獨(dú)的寫操作效率都是很高的，不管 的寫是單條 的寫操作，還是批量的寫操作，這些寫操作的數(shù)據(jù)量就是 要去寫的數(shù)據(jù)的大小，因此控制寫的數(shù)據(jù)量的大小是一件很容易很天然的操作，所以這些操作不會(huì)造成數(shù)據(jù)庫(kù)太大負(fù)擔(dān)，詳細(xì)點(diǎn)的話，對(duì)于數(shù)據(jù)庫(kù)而言，新增操作無非是在原來數(shù)據(jù)后面追加些 ，而修改操作或者刪除操作一般都是通過建立了高效索引的字段來定位數(shù)據(jù)后再進(jìn)行的操作，因此它的性能也是非常高的。而讀操作看起來比寫操作簡(jiǎn)單（例如：讀操作不存在像事務(wù)這些烏七八糟 的干擾），但是當(dāng)讀操作面對(duì)海量數(shù)據(jù)時(shí)候就嚴(yán)重 著數(shù)據(jù)庫(kù)和硬盤

6、的極限能力，因此讀操作很容易產(chǎn)生瓶頸問題，而且這個(gè)瓶頸不管問題表是否讀寫失衡都會(huì) 的。前文里我詳細(xì)列舉了一個(gè)交易表設(shè)計(jì)的案例，其中 可以看到數(shù)據(jù)庫(kù)垂直拆分在實(shí)際應(yīng)用里的運(yùn)用，在例子里 首先根據(jù)業(yè)務(wù)特點(diǎn)將交易表分成了實(shí)時(shí)交易表和歷史交易表，這個(gè)做法其實(shí)就是將原交易表的讀和寫進(jìn)行分離，但是這種分離和純粹的讀寫分離相比會(huì)更加有深意，這個(gè)深意就是拆分實(shí)時(shí)和歷史交易表也就是在分拆原表的讀寫操作的關(guān)聯(lián)性，換句話說，如果 不這么做的話，那么交易表的每次寫和每次讀幾乎等價(jià)，這樣 沒法單獨(dú)解決讀的性能問題，分出了歷史交易表后 再對(duì)歷史交易表來做讀的優(yōu)化，那么這也不會(huì)影響到寫操作，這樣把問題的復(fù)雜度給降低了。在案

7、例里 對(duì)歷史交易表進(jìn)行了業(yè)務(wù)級(jí)別的水平拆分，但是這個(gè)拆分是以如何 讀的效率進(jìn)行的，因此前文講到的水平拆分里主鍵設(shè)計(jì)方案基本上派不上用場(chǎng)，因?yàn)檫@兩種水平拆分的出發(fā)點(diǎn)是不同的，那么使用段和達(dá)到效果也將不一樣。由上所述，可以把數(shù)據(jù)庫(kù)的水平拆分重新定義下，我在這幾篇文章里一直講述的水平拆分本質(zhì)是從數(shù)據(jù)庫(kù)技術(shù)來定義的，我把它們稱為狹義的水平拆分，與狹義相對(duì)的就是廣義的水平拆分，例如上文例子里把交易表根據(jù)業(yè)務(wù)特性分為實(shí)時(shí)交易表和歷史交易表，這種行為也是一種水平拆分，但是這個(gè)拆分不會(huì)遵守我前面講到主鍵設(shè)計(jì)方案，但是它的確達(dá)到水平拆分的目的，所以這樣的水平拆分就屬于廣義的水平拆分了。第三個(gè)演進(jìn)過程：到了三個(gè)演

8、進(jìn)過程就會(huì)考慮到真正的水平拆分了，也就是上面提到的狹義的水平拆分了，狹義的水平拆分執(zhí)行的理由有兩個(gè)，一個(gè)那就是數(shù)據(jù)量太大了，另一個(gè)是數(shù)據(jù)表的讀寫的關(guān)聯(lián)性很難進(jìn)行拆分了，這點(diǎn)和垂直拆分有所不同，做垂直拆分的考慮不一定是因?yàn)閿?shù)據(jù)量過大，例如某種表數(shù)據(jù)量不大，但是負(fù)載過重，很容易讓數(shù)據(jù)庫(kù)達(dá)到連接的極限值，也會(huì)采取垂直拆分來解決問題，此外，想減輕寫操作和讀操作的關(guān)聯(lián)性，從而能單獨(dú)對(duì)有瓶頸的寫操作或讀操作做優(yōu)化設(shè)計(jì)，那么也會(huì)考慮到垂直拆分，當(dāng)然數(shù)據(jù)量實(shí)在是太大的表想優(yōu)化，首先也會(huì)考慮到垂直拆分，因?yàn)榇怪辈鸱质轻槍?duì)海量數(shù)據(jù)優(yōu)化的起始，但是垂直拆分可不一定能解決海量數(shù)據(jù)。狹義水平拆分的使用的前提是因?yàn)閿?shù)據(jù)量

9、太大，到底多大了，舉個(gè)例子來說明下，假如某個(gè)一天的交易筆數(shù)有 億筆，數(shù)據(jù)的關(guān)系數(shù)據(jù)庫(kù)單表到了 千萬條后，查詢性能就會(huì)嚴(yán)重下降，那用來么如果把這兩億條數(shù)據(jù)全部存進(jìn)這個(gè)數(shù)據(jù)庫(kù)，那么隨著數(shù)據(jù)的累積，實(shí)時(shí)交易查詢基本已經(jīng)沒法正常完成了，這個(gè)時(shí)候就得考慮把實(shí)時(shí)交易表進(jìn)行狹義的水平拆分，狹義的水平拆分首先碰到的難點(diǎn)就是主鍵設(shè)計(jì)的問題，主鍵設(shè)計(jì)問題也就說明狹義水平拆分其實(shí)解決的是海量數(shù)據(jù)寫，如果這操作很少，或者基本沒有，這個(gè)水平拆分是很好設(shè)計(jì)的，但是一前文講到的主鍵設(shè)計(jì)方案其實(shí)基本沒只寫不讀，對(duì)于作為業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫(kù)那基本是非常罕見的，。業(yè)務(wù)上的意義，它解決的主要問題是讓寫入的數(shù)據(jù)分布均勻，從而能合理使用資

10、源，但是這個(gè)合理分布式資源卻會(huì)給查詢操作帶來極大，甚至有時(shí)可以說狹義水平拆分后數(shù)據(jù)查詢變得就是由這種看起來合理的主鍵設(shè)計(jì)方案所致。還是以實(shí)時(shí)交易表的實(shí)例來說明問題，一個(gè)下會(huì)接入很多不同的商戶，但是不同的商戶每天產(chǎn)下不到 的商生的交易量是不同，也就是說商戶的維度會(huì)讓使交易數(shù)據(jù)變得嚴(yán)重的不均衡，可能戶完成了全天交易量的 ，而其他 的商戶僅僅完成 的交易量，但是作為業(yè)務(wù)系統(tǒng)的數(shù)據(jù)表，進(jìn)行讀操作首先被限制和約束的條件就是商戶號(hào)，如果要為設(shè)計(jì)的實(shí)時(shí)交易表進(jìn)行狹義的水平拆分，做拆分前要明確這個(gè)拆分是由交易量大的少量商戶所致，而不是全部的商戶所致的。如果按照均勻分布主鍵的設(shè)計(jì)方案，不加商戶區(qū)分的分布數(shù)據(jù)，那

11、么就會(huì)發(fā)生產(chǎn)生少量交易數(shù)據(jù)的商戶的查詢行為也要承受交易量大的商戶數(shù)據(jù)的影響，而能產(chǎn)生大量交易數(shù)據(jù)的商戶也沒有因?yàn)樽约旱呢暙I(xiàn)度而得到應(yīng)有的高級(jí)服務(wù)，碰到這個(gè)問題其實(shí)非常好解決，就是在做狹義水平拆分前，分出來，交易量小的商戶用一先做一次廣義的水平拆分，把交易量大的商戶交易和交易量小的商戶交易拆，這樣交易量小的商戶也會(huì)很 NGVV_ 的查詢出需要的數(shù)據(jù)，心里也是美滋滋的。接下來服務(wù)。就要對(duì)交易量大的商戶的交易表開始做狹義的水平拆分了，為這些重點(diǎn)商戶做專門的定制化做狹義水平拆分前，有個(gè)問題需要過一下，在狹義水平拆分前需要先做一下廣義的水平拆分嗎？這個(gè)我這里不好說，具體要看實(shí)際的業(yè)務(wù)場(chǎng)景，但是針對(duì)我列舉

12、的實(shí)時(shí)交易的例子而言，我覺得沒那個(gè)必要，因此拆分出的重點(diǎn)商戶交易量本來就很大，每個(gè)都在數(shù)據(jù)庫(kù)讀能力的極限，更重要的是實(shí)時(shí)交易數(shù)據(jù)的時(shí)間粒度已經(jīng)很小了，再去做廣義水平拆分難度很大，而且很難做好，所以這個(gè)時(shí)候還是直接使用狹義的水平拆分。拆分完畢后就要解決查詢問題了。做實(shí)時(shí)查詢的標(biāo)準(zhǔn)做法就是分頁(yè)查詢了，在講述如何解決分頁(yè)查詢前，這個(gè)條件的分頁(yè)情況，如下圖所示：看看在淘寶里搜索【衣服】看到一共才 100 頁(yè)，淘寶上衣服的商品最多了，居然搜索出來的總頁(yè)數(shù)只有 100 頁(yè)，這是不是在的啊，淘寶的這個(gè)做法也給在實(shí)現(xiàn)水平拆分后如何做分頁(yè)查詢一種啟迪。明這個(gè)啟迪前首先要看看傳統(tǒng)的分頁(yè)是如何做的，傳統(tǒng)分頁(yè)的做法是

13、首先使用 select count(1) form table 這樣的語(yǔ)句查詢出需要查詢數(shù)據(jù)的總數(shù)，然后再根據(jù)每頁(yè)顯示的條數(shù)，查詢出需要顯示的，然后頁(yè)面根據(jù)總數(shù)，每頁(yè)的條數(shù)，和查詢的結(jié)果來完成分頁(yè)查詢?；氐降慕灰妆韺?shí)例里，有一個(gè)重要商戶在做實(shí)時(shí)交易查詢，這個(gè)時(shí)候該商戶已經(jīng)產(chǎn)生了 1 千萬筆交易了，假如每頁(yè)顯示 10 條，那么就要分成 100 萬頁(yè)，這要是真顯示那樣驚奇，反正我見過的最多分頁(yè)也就是 200 多頁(yè)，在頁(yè)面上，絕對(duì)能讓這些開發(fā)像發(fā)現(xiàn)的數(shù)據(jù)量非常大的時(shí)候，select 的 count 查詢效率就非常低下，這還是在搜索發(fā)現(xiàn)的。其實(shí)當(dāng)數(shù)據(jù)庫(kù)一個(gè)查詢有時(shí)也會(huì)近似個(gè)全表檢索，所以 count

14、查詢還沒結(jié)束就會(huì)失去等待結(jié)果的耐心了，更不要是說等把數(shù)據(jù)查詢出來了，所以這個(gè)時(shí)候可以學(xué)習(xí)下淘寶的做法，當(dāng)商戶第一次查詢準(zhǔn)許他查詢有限的數(shù)據(jù)。我自己所做的一個(gè)項(xiàng)目的做法就是這樣的，當(dāng)某個(gè)商戶的交易量實(shí)在是很大時(shí)候其實(shí)不會(huì)計(jì)算數(shù)據(jù)的總筆數(shù)，而查詢出 1000 條數(shù)據(jù)，這 1000 條數(shù)據(jù)查詢出來后存入到緩存里，頁(yè)面則只分 100 頁(yè)，當(dāng)用戶一定要查是詢 100 頁(yè)后的數(shù)據(jù)，再去追加查詢，不過實(shí)踐下來，商戶基本很少會(huì)查詢 100 頁(yè)后的數(shù)據(jù)，常?？戳?5，6頁(yè)就會(huì)停止查詢了。不過商戶也時(shí)常會(huì)有查詢?nèi)繑?shù)據(jù)的需求，但是商戶有這種需求的目的也不是想在分頁(yè)查詢里看的，一般都是為了比對(duì)數(shù)據(jù)使用的，這個(gè)時(shí)候一

15、般是提供一個(gè)發(fā)起查詢?nèi)拷灰椎墓δ茼?yè)面，商戶根據(jù)自己的條件先發(fā)起這樣的需求，然后系統(tǒng)會(huì)在單獨(dú)起個(gè)線程查詢出全部數(shù)據(jù)，生成一個(gè)固定格式的文件，最后通過一些有效通知商戶數(shù)據(jù)生成好了，讓商戶文件即可。對(duì)于進(jìn)行了狹義水平拆分的表做分頁(yè)查詢通常都不會(huì)是全表查詢，而是抽取全局的數(shù)據(jù)的一部分結(jié)果呈現(xiàn)給用戶，這個(gè)做法其實(shí)和很多市場(chǎng)的方式類似，市場(chǎng)通常是找一些樣本相關(guān)數(shù)據(jù)，通過分析這些樣本數(shù)據(jù)推導(dǎo)出全局的一個(gè)發(fā)展趨勢(shì)，那么這些樣本選擇的合理性就和最終的結(jié)論有很大關(guān)系，回到狹義水平拆分的表做分頁(yè)查詢，為了及時(shí)滿足用戶需求，只是取出了全部數(shù)據(jù)中的一部分，但是這一部分?jǐn)?shù)據(jù)是否滿足用戶的需求，這個(gè)問題是很有學(xué)問的，如果

16、是交易表，往往是按時(shí)間先后順序查詢部分?jǐn)?shù)據(jù)，所以這里其實(shí)使用到了一個(gè)時(shí)間的維度，其他業(yè)務(wù)的表可能這個(gè)維度會(huì)不一樣，但肯定是有個(gè)維度約束到底返回那些部分的數(shù)據(jù)。這個(gè)維度可以用一個(gè)專有的名詞指代那就是排序，具體點(diǎn)就是要那個(gè)字段進(jìn)行升序還是降序查詢，看到這里肯定有人會(huì)有異議，那就是這種抽樣式的查詢，肯定會(huì)導(dǎo)致查詢中率，即查出來的數(shù)據(jù)不一定全部都是要的，其實(shí)要想讓數(shù)據(jù)排序正確，最好就是做全量排序，但是一到全量排序那就是全表查詢，做海量數(shù)據(jù)的全表排序查詢對(duì)于分頁(yè)這種場(chǎng)景是無法完成的?；氐教詫毜睦?，相信淘寶肯定沒有返回全部數(shù)據(jù)，而是抽取了部分?jǐn)?shù)據(jù)分頁(yè)，也就是淘寶查詢時(shí)候加入了維度，每個(gè)淘寶的店家都希望自

17、己的商戶放在搜索的前列，那么淘寶就可以讓商家掏錢，付了錢以后淘寶改變下商家在這個(gè)維度里的權(quán)重，那么商家的商品就可以靠前了。狹義水平拆分的本身對(duì)排序也有很大的影響，水平拆分后一個(gè)分頁(yè)查詢可能要從不同數(shù)據(jù)庫(kù)不同的物理表里去取數(shù)據(jù)，單表下可以先通過數(shù)據(jù)庫(kù)的排序算法得到一定的數(shù)據(jù)，但是局部的排序到了全局可能就不正確了，這個(gè)又該怎么辦了？其實(shí)由上面內(nèi)容可以知道要滿足對(duì)海量數(shù)據(jù)的所有查詢限制是非常難的，時(shí)常是根本就，只能做到盡量多滿足些查詢限制，也就是海量查詢只能做到盡量接近查詢限制的條件，而很難完全滿足，這個(gè)時(shí)候我前面提到的主鍵分布方案就能起到作用了，在設(shè)計(jì)狹義水平拆分表主鍵分布時(shí)候查詢要從多張不同物理

18、表里取的時(shí)候，例如要查 條數(shù)據(jù)，而是盡量保持?jǐn)?shù)據(jù)分布均衡，那么如果狹義水平拆分出了兩個(gè)物理數(shù)據(jù)庫(kù)，那么就可以每個(gè)數(shù)據(jù)庫(kù)查詢 條，然后在服務(wù)層歸并成 條數(shù)據(jù)，在服務(wù)層排序，這種場(chǎng)景下如果的主鍵設(shè)計(jì)時(shí)候還包含點(diǎn)業(yè)務(wù)意義，那么這個(gè)排序的精確度就會(huì)得到很大提升。假如用戶對(duì)排序不敏感，那就更好做了，分頁(yè)時(shí)候如果每頁(yè)規(guī)定顯示 條，給兩個(gè)數(shù)據(jù)庫(kù)，也就是顯示 條 庫(kù)的數(shù)據(jù)，再顯示 條 ( 庫(kù)的數(shù)據(jù)?？梢园?條數(shù)據(jù)平均分配看到這里有些細(xì)心的朋友可能還會(huì)有疑問，那就是居然排序是分頁(yè)查詢的痛點(diǎn)，那么可以不用數(shù)據(jù)庫(kù)查詢，而使用搜索技術(shù)啊，4U9WR 數(shù)據(jù)庫(kù)啊，的確這些技術(shù)可以更好的解決分頁(yè)問題，但是關(guān)系數(shù)據(jù)庫(kù)過渡到搜索引擎和 4U9WR 數(shù)據(jù)庫(kù)首先需要轉(zhuǎn)化數(shù)據(jù)，而狹義的水平拆分的數(shù)據(jù)表本身數(shù)據(jù)量很大，這個(gè)轉(zhuǎn)化過