英文原文： Why is it hard to scale a database, in layman’s terms?

　　Paul King ， Facebook 數據科學家（3.6K 贊）

　　要擴展數據庫有四大挑戰：搜索、并發性、一致性和速度。

　　假設你有一張清單，上面有10個人名。如果你想要查找某個人，只需要看一眼清單就行。

　　但如果清單上有100萬個人名呢？這時，你就需要一些策略了。電話簿把人名按照字母順序排列，這樣你就可以略過不需要的部分了。這就是針對搜索問題的一種解決方案。

　　如果有100萬人在同時使用這本電話簿呢？這就是并發性的問題。要么大家在市政廳排長隊等待使用電話簿，要么把電話簿復印100萬份——“主從復制”策略。如果你把這100萬份復印件放到每個人的家里——“分布式”策略——你同樣可以得到快速響應。

　　如果有人電話號碼更換了呢？主從復制策略造成了一個問題：現在必須對100萬本電話簿作出更改。而且它們還在被使用呢，何時才能進行更改呢？如果一本一本的更改，就可能造成數據一致性問題。如果全部回收并印發新的，就可能造成可用性問題。

　　如果每小時都有成百上千的人更換他們的電話號碼呢？這時你就面臨由于“資源爭用”引起的嚴重的信息堵塞，這種堵塞還會導致“競態條件”（不可預知的輸出）和“死鎖”（數據庫的僵局）。

　　以上所有問題都有解決方案，但這些解決方案可能會非常復雜。比如，可以通過發放電話簿的附錄（稱為“修改日志”）而不是重新打印它們，不過你得時時刻刻檢查你的附錄。你可以按照修改日期發布電話簿的新版本，這樣人們可以同一時間交換它們以獲得更高的一致性，不過這樣的話，電話簿就總會稍微有一點過時。

　　現在，把規模擴展到有上百萬的用戶使用，數十億條數據分布式的存儲在世界各地的數據中心中。

　　數據庫基本目標是維護一種假象，即它只有一份拷貝，同一時間只有一個人在修改它，所有人看到的都是最新的數據，并且能立即響應。當數據庫擴展到全球有上百萬的人使用和修改上以萬億計的數據時，這個目標就無法達到了。

　　因此數據庫設計的任務是使用環環相扣的算法技巧以盡可能的接近這一假象。

　　黃易山，Reddit 前 CEO，（2k 贊）

　　這里有一個專門針對門外漢，例如完全不懂數據庫的非技術人員的解釋。

　　（對于懂數據庫的人，請自行忽略這句話以及接下來這個類比中的一些小技術錯誤。）

　　“擴展”在很多方面都是很難的，但是首先我想要從根本上講為什么擴展很難——原因是“擴展”并不是一個單一方向的活動。總的來說，它的本質是把一個復雜的系統變得“更好”——通常是更大或更多，而且通常很快就不得不這么做。關鍵在于一個復雜的系統不能通過一個簡單的方法就能變得更大或更多產或更高效——通常系統的各個方面相互影響，所以如果你想要拓展某一部分，那么其它部分通常會失效，從而你無法得到想要的擴展——你幾乎總要做一些重構

　　打個比方：

　　把數據庫想象成一個圖書館。你在那里存放書籍或者叢書（比如全套的哈利波特系列叢書）。特別的，你的web應用也是一個圖書館，它存放圖書，方便的提供人們閱讀。想象一下，這個圖書館出現在了TechCrunch上，變得非常受歡迎，如此一來你就突然面臨了一系列的擴張問題。讓我們列舉幾個問題，用簡單的術語進行解釋：

　　例一：很多、很多書

　　你的圖書館越來越受歡迎。因此，你比當初開始建立圖書館的時候多了很多書，很長一段時間里，你只是把它們放在房間的新書架上。但是目前的房子里無法放下全部的書了。它們已經超出了你的小圖書館可以承載的規模。你必須購買或者租賃相鄰的建筑物，把書放在里面。這可能會帶來一些問題，因為你附近的建筑物是有限的，或者房地產價格非常高以至于無法持續的租賃隔壁那個很貴的房子。因此你必須認真思考租賃哪個房子，如何找到那些距離很近又很合算的用于存放書籍的房子。

　　這是真實的模擬，數據庫通常存儲在硬盤上，硬盤存放在有限的空間里，你只能在一臺計算機（一個數據中心，一個機架）中存放許多的硬盤。為了抗衡這個普遍的問題數據中心設計的很大，但是如果你是一個非常大的圖書館，你可能還是會遇到這種限制，數據中心的機架無法承受如此之多的硬盤，甚至你需要廢棄掉這個數據中心并建立一個新的（這種情況很少見）。盡管如此，問題的核心是不管你最開始有多少空間，你總是需要擴展它，并且你沒法一直線性的在空間中增加“單元”（好比在圖書室里增加書架），你終會需要做出跨越性的改變，例如租賃隔壁的房子或者租賃又一個機架或者建立又一個數據中心。

　　例二：在書的海洋里找書

　　當你的圖書館只占用一個房間的時候，你只需要把所有的書按照字母順序排列放好就行。如果有人想要某本書，他只需要在房間里順序查找到他想要的那本就好。這大約需要花費30分鐘。

　　現在你的圖書館很大，你租賃了很多房子。如果有人想要看某本書的話，他可能需要走遍所有的房子。人們根本不能接受找一本書需要花費這么多的時間（和人們承受網頁的加載時間類似）。人們只想要直接走到正確的房子里，走到正確的樓層，走到正確的那個書架，直接拿到那本想要的書。他們根本不愿意花費超過半小時的時間。

　　為了實現這一目標，你得創建一個新的關聯系統，叫做索引。現實中的圖書館確實遇到了這個問題，他們使用的解決方案是卡片目錄。如下圖所示：

　　年輕一代可能不知道這是什么，因為這是計算機時代之前的產物。卡片目錄簡直就是個使用小抽屜和小紙片（卡片）的數據庫。因為它們太過笨重，所以我們把它們數字化并放進了計算機中。如果你小于25歲的話，你可能根本沒見過它們。

　　卡片目錄（即索引）為每本書建造了一個卡片，把卡片放進抽屜，按照標題、作者、主題等排序。如果你想要查找某本書，就直接使用卡片目錄——放在單獨的一個房間里——查找你要的書的卡片，卡片中會有這本書的具體所在位置。所以你只需花費10分鐘來檢索卡片，10分鐘走到正確的房子，5分鐘走到確切的樓層和書架前，再花5分鐘找到確切的書。

　　如果一個圖書館變得太大了，它就需要引進卡片目錄，使得查找一本書需要的時間保持在合理的范圍內（例如半小時），否則就需要花好幾天來搜索遍所有房子以找到一本書，這樣人們就不會使用這個圖書館了。這和僅僅只是租賃更多的房子并全部搜索有本質上的不同——這個例子說明當你在擴展中遇到門檻時，必須要想出一個新的解決方案以克服問題——不僅僅是增加書架，你還必須整理書目，打印出所有的卡片（這很困難，因為你必須遍歷所有的書，把他們按照作者、標題和主題等排序，這很痛苦，因為你的書堆滿了好幾個房子），然后你得在圖書館靠門口的位置空出一個特殊的房間用于存放你的卡片目錄，告訴每個人先檢查卡片。

　　例三：很多人同時查找同一本書

　　讓我們舉一個超級簡單的例子來說明這個問題：你的圖書館現在很受歡迎，每天有成千上萬的人同時光臨。人山人海，摩肩接踵。這可不是聽起來那么荒謬——這是當一個web應用突然火起來時遇到的最普遍的問題。

　　現在有好多人想要看同一本書以至于他們卡住了大門。這聽起來很荒謬，因為現實中這很少發生。但是想想這個——現實中的大門可以允許一秒鐘通過一個人。因此如果每秒鐘有20個人想要進入你的圖書館， 那么很快門口會排起長隊。越來越多的人到來，隊伍越來越長。最終，門口排隊的人數會超過在圖書館中的人數，大量等待的人群口口相傳他們只能一直在門口等待而永遠也無法讀到一本書。看不到書而恨你的人比看到書而得到滿足的人多的多，壞口碑就產生了。

　　一個顯而易見的解決方案是在墻上開更多的門。你現在又開了一道門，兩倍的人涌入了！你開了更多的門，最終有上百個門，每面墻都擠滿了門。嘿，你只需移除所有的墻！這樣，更多的人可以使用圖書館了！數量級的激增！

　　但很快你就會遇到另一個問題，每本書所在的書架前只有有限的空間，只能給有限的人站立，也許他們速度可以很快——他們瀏覽書架找到想要的書然后就離開。但是他們依然需要在書架前站立幾秒鐘，但最終因為你的圖書館太受歡迎，成百上千的人都在查找同一本書（或者被查找的兩本書放在同一個垂直空間），他們沒法都擠在書架前的一小塊空地里。

　　再一次，書架前排起了長隊——也許是所有的書架，也許只是某一個放著暢銷書的書架。以下是一些可能的解決方案：

　　如果人群只是聚集在暢銷書架附近，那你只需要把暢銷書分散放在圖書館即可。但這樣，書本就不再是按序擺放的了，它們變得隨機分布，所以你就需要重構你的卡片目錄以使得人們可以快速找到它們。這不是那么痛苦——因為你僅僅只需要更新所有的暢銷書的卡片而已。

　　如果到處都人擠人，例如，所有的書都很受歡迎，或者僅僅是人太多，你可以嘗試增加副本。也就是說，復制你的整個圖書館然后在城市的另一邊（或者下一個街區）租賃一些新的房子，把一般的人遷移到新圖書館去。你可以這樣重復做幾次，增加一些副本。這樣做的話需要確保備份都是最新的，你必須確保所有的新書在多個圖書館都有最新的備份。有一個解決方案是把其中一個圖書館稱為“主”圖書館，所有的新書都只進入這一個圖書館，每次有新書進入時，你得派人復印這些書并排一個快遞員把這些備份送到其它圖書館中。這些快遞員也需要占用交通資源，這又限制了可以使用你的圖書館的人數，因此你需要限制每個圖書館的接待人數，當人數過多的時候，你就要再新建一個圖書館了。

　　總結如下，最開始的時候你想要擴展你的圖書館以應對大量的人群，你僅僅只是增加新的門，通過人數瞬間翻倍。你可以再開一扇門再次增加通過人數。在一段時間里，你都可以通過增加新的門來擴展，直到你在所有的墻上都開滿了門——即你移除了所有的墻。在此之后你還想繼續擴展（記住，來你圖書館的人永不停息的在增長），你就得想一個全新的解決方案了，比如建立幾個備份圖書館。這樣做造成很多影響——你得復印你所有的書，租賃新的房子，然后還得想出一個合理分流的方案使得每個圖書館的人數都很合理。所有的這些都是新的基礎設施，你沒法等到你意識到需要開辟足夠多的門的時候再做這些，因為建設它們的時候訪問人數依然在不斷增加，等待的人群會很不滿意。所以你得根據訪問量的增長速率來預測當你開辟新門策略可能無效的時候就早早開始增加圖書館的數量。

　　例四：增加很多、很多新書

　　所有的圖書館都得與時俱進，也就意味著得不停的增加新書。讓我們假設你有一個很活躍的圖書館，每時每刻都有成百上千的新書增加進來。

　　如此一來，你得安排人購買新書，在主圖書館復印它們，把這些書分散放到書架上。你有一個超級通暢的交通和足夠數量的圖書館們，即使快遞員們在各個圖書館之間游走送達新書，也不會影響你的圖書館的訪問速度。太棒了，一切看起來都很贊，你決定今天終于可以休個假了。

　　好的，你圖書館中所有的書都是排好序的，也就是說他們不是隨機的放在書架上，而是按照作者或者標題或者別的什么排序擺放（在現實中，是按照杜威十進分類法，當你在小學第一次接觸到它的時候肯定覺得很荒謬，但一旦你明白了這些數據庫問題之后，很奇怪的，你就能明白它其實是很有意義的）無論如何，書本按序排放，當有人通過卡片目錄找到某本書在某個書架上的時候，他不需要瀏覽整個書架來找到那本書——書架上的每本書都是按序排放的，所以可以查閱書架中間的書，選取他的左側或者右側繼續查閱，以此遞歸找到特定的書。無論何時，所有的書都得排好序讓使用者可以照此方法找書。

　　書架上的書按需排列，書架也走擺的滿滿的。也就意味著當快遞員想要把新書放進書架的時候，需要把排在末尾的書移到下一個書架上，下一個書架上的末尾的書移到又一個書架上，以此往復。最終，你得重新設計書架，使其有一些空隙可以放書，而不再需要把書移到另一個書架，這個過程是很惱人的，也很花費時間，更重要的是，當你重新設計書架排放的時候，你不希望有其他的使用者或者快遞員從這些書架上拿書或者放書。所以你得“鎖住”這些書架以及周圍的所有書架，以防止你需要把書挪到別的書架上去，別的書架上的書又得挪到又一個別的書架上去等等。

　　這種鎖定造成了巨大的交通問題。問題從找書的時候需要等待其他站立在書架前的人離開變成了大量的人群需要等待在書架區的外圍，等待快遞員插入新書以及移動書籍的位置。如果快遞員很多，那這個問題就會經常發生。大量的人群需要等待某一個快遞員完成操作，更糟的是，一個快遞員可能需要等待另一個快遞員。在現實中，新書并不常常增加，但如果你運行一個網站有很多人同時上傳很多東西，這就等同于每時每刻都有有很多快遞員給圖書館快遞新書，你就會遇到上述的問題。

　　同時，如果快遞員動作不夠快，例如沒法把所有的備份同時送到所有的圖書館，那么有些人不能找到某本書但是其他人可以，他們就會得到相互矛盾的信息。

　　該問題的解決方案就給讀者留作練習吧。

　　要記住，解決該問題就得幫快遞員們想出一個全新的解決方案（也許可以將臨近的書放在同一批次一起更新，這樣一次就可以在一個書架上更新很多書了），或者改變圖書館的布局方式（也許你可以為所有的書周圍都留下空位；但如果這些空位又被填滿了呢？）——總而言之，我們可以得到如下的教訓：如果你的快遞員數量不多，你每天新增的書本數量也不多，那這就不是什么大問題，但如果你超過一個閥值（比如多如潮水的快遞員和新書）你就得改變你現在的整個解決方案和物理布局，而這往往需要想象力和創造力。

　　這就是為什么數據庫難以擴展的原因。

　　事實上，這也是為什么擴展任何一個稍許復雜的系統（比如web應用，它包含了數據庫和其他服務器及其交互）很難的原因。參考一所完整的研究性大學吧，它包含了實驗室、教室和宿舍等等，圖書館及其用途只是整個大學的組成之一。這些組成部分的任何一個的使用量的快速增長都會引發擴展問題。為了克服這種問題，你通常都得重構整個動態底層協議和重排操作協議（即你代碼里的算法）或者你的資源布局。實現這些總是需要創造性的努力并且不同系統的底層細節各不相同，因此，只有一些通用的解決方案——上文提到了其中一些——你常常得調整這些通用解決方案以適應你的情況：也許你很難租到房子用來當做復制圖書館；也許你的書都是大百科全書，快遞員沒法一次快遞很多本書；也許你那兒環境太冷，你沒法開很多扇門，否則顧客就凍死了。適用于這個環境的解決方案沒法完全適用于那個環境，所以你每次都不得不調整解決方案以適應眼前的環境，敏銳的觀察力是幫助你發現問題并找到最適宜該問題的解決方案的必備品。

　　最后要記住，當你重新設計解決方案的時候，會有越來越多的顧客敲你的門，沖你叫嚷，因為隊伍太長他們沒法看到想看的書了！

　　哦，對了。你的圖書館可能會讓你的錢包邊的空空，讓你的心流血，因為你要購買足夠多的書架，租賃足夠多的房子，那你怎么樣才能開始賺錢呢？所有的風險投資者都不想資助你，因為你居然想讓顧客免費借書？你居然不愿意插頁內廣告？

　　謝謝欣賞！

　　本文由 伯樂在線 - 顧星竹 翻譯，sunbiaobiao 校稿。