2014.1.16  有物報告/Victor Lin

現今網路科技好比開水龍頭，一打開資訊就源源不絕地流出來。然而在背後，處理海量資料一點都不容易。我們在「一至千萬的藝術──如何養成支撐網路巨量交易的伺服器艦隊」討論了打造伺服器艦隊無法一蹴可幾。同樣的，海量資料儲存一樣不能一步登天，必須由簡到繁。在此筆者用簡單易懂的方式，介紹海量資料儲存的原理。

第一間倉庫
很久很久以前，在一個叫做雲端小鎮的地方，蓋出了第一間倉庫。也就是用一台主機儲存資料。有了這間倉庫，人們可以開始儲存資料。

一開始事情很順利，村民們也都很滿意這間倉儲的服務。然而隨著村民數量成長，漸漸的這一間倉庫的容量到達極限。

除此之外，每當遇到天災人禍（如下圖的恐龍攻擊），村民都得擔心放在倉庫裡的資料會不會隨著一把火化為灰燼。這就是之前提到的「瓶頸」（Bottleneck）與「失效單點」（Single point of failure）問題。

倉儲街
倉儲公司意識到只有一間倉庫不但容量不足，資料也不安全。於是老闆把同一條街其它九間店面都買下來，全改成倉庫。如此一來有了一條倉儲街。

然而倉庫多了，問題也出現了：客戶要的某一筆資料究竟放在哪一間倉庫呢？於是老闆做了一張清單，裡面清楚記載了資料分別放在哪一間倉庫。清單放在第一間店裡供大家記錄與查詢，如下圖：

但很快的，老闆發現存取人少時這個設計還能夠負荷；人數一多，大家搶著用那張表，便在第一間倉庫的門前大排長龍。於是第一間店又成了「瓶頸」與「失效單點」。這似乎是頭痛醫頭，並沒有真正解決問題。

編號與分類
老闆左思右想，想到了好方法。他給倉庫編號，從0到9。再將每筆資料對應一個數字。老闆訂了新的規定──所有資料結尾是0的都放進0號倉庫，結尾是1的放進1號倉庫，以此類推。例如王小明的個人照片檔案編號是123456，就擺進6號倉庫。如此一來客人可以自己算出所在的倉庫在哪裡，不必查詢清單。

資料半夜大風吹
事情至此發展的不錯。但隨著時間過去，使用量愈來愈多，倉儲街裡的倉庫也都漸漸滿了。老闆於是又買下了週圍的九家店面改成倉庫，繼續從10號編號到18號。算法也從原本的取個位數改成求除以19的餘數。

然而改了編號規則，原本放在各間倉庫裡資料都得搬家了。像王小明的檔案編號123456，原本擺在6號倉庫裡；算法改變後，123456除19的餘數是13，就得改搬到13號倉庫裡。這樣下來，大部分的資料都得搬新家。

老闆找了一堆人手，好不容易趁半夜把資料搬完。沒想到因為生意太好，過不了多久所有的倉庫又接近滿載。於是老闆擴充倉庫數量的同時，就得不停的玩資料大風吹的遊戲。不只成本昂貴，在搬運的期間客戶也沒辦法在新的地點找到資料。

從街道改成圓環
為了解決這問題，老闆躲進山中在瀑布下打坐苦思，終於想到了一個方法！首先他挑了一個很大的數字（例如1,000），接著他將倉庫均勻地編號在小於這個數字的號碼中。

同時他宣布了新的收納方法：

檔案編號×123456除以1,000，求餘數

這個公式就成了新的歸檔方法。而選擇倉庫不再是直接的取對應的餘數，而是算出餘數後，找到最接近餘數、且比餘數大的倉庫。簡單來說是把數字拆成區段來對應到倉庫。我們來舉個實際的例子，假設共有5間倉庫分別編號如下：

倉庫25
倉庫225
倉庫425
倉庫625
倉庫825

（註：因為只有5間倉庫，因此必須以1,000/5＝200的間隔編號，才能形成一個環。）

以圖來表示的話：

舉王小明的檔案為例子來說，123456*123456除1,000是936。因為沒有比936大的倉庫編號，因此就歸檔到第25號倉庫裡。

這樣分段有個好處，當有新的倉庫要加入時，只需插入兩個倉庫的編號之間，等於是將原本的區段再更加細分。如此只有一小部份原本區段裡的資料會受影響，遠比先前所見到的大風吹情況來得小。如下圖：

原本倉庫625和425之間的區段被平拆分成更細的兩段，只有原先在這段之中的檔案的一半需要搬動到新的區段裡。這種機制叫做「一致性雜湊環」（Consistent hash ring）。採用這樣的機制後，這間倉儲公司再也不用害怕新增新的倉庫，每次新增機器所造成的資料搬移都相對的非常有限。

為了讓讀者好理解，本文省略了許多現實考量，像是資料沒有異地備援。實務上同一份檔案會複製到不同節點上。另外真正的檔案編號會使用「雜湊函數」對檔案名稱進行運算，倉庫編號也會以亂數產生。有興趣的讀者可以自行深入研究。

萬丈高樓平地起
之前文章談網路巨量交易的伺服器艦隊，獲得了不錯的回應，筆者所見到在網路上最有趣的討論大概是像這樣：

這樣的技術很不錯，不過雲端還是比較先進一點

這話聽起來就好像是對金城武說：

你長得還挺帥的，但我覺得金城武比較帥

之前那篇文章講的就是雲端。「雲端」兩字已被過度渲染，讓人以為雲端是更神奇的東西。事實上雲端也是靠基礎的技術解決工程問題所堆疊的，並非浮在空中的一塊閃亮招牌而已。萬丈高樓平地起，雲端技術業界的領頭羊Amazon的S3或是Dynamodb都有用到這樣的技巧。

本文所提到的「一致性雜湊環」只是眾多雲端開發設計上的技巧中最經典的方法之一。Amazon 曾發表過一篇經典論文「Dynamo: Amazon’s Highly Available Key-value Store」，就是在講他們自行設計的資料庫系統是如何透過各種設計來達成高可得性。

從對於雲端本質的誤解與曲解不難看出，台灣在這方面還是相對落後。國內最近也有許多業者想往雲端的方向發展，甚至也有地方政府建起雲端園區來了。在這方面想要突破，並非喊雲端的口號，或是生產名稱裡有雲端兩字的產品，或蓋很多園區就能辦到。真正該做的是下苦功，從最基本的技術能力培養起，台灣產業的能力才有辦法真正的提升。

【有物報告】取名自「言之有物」，是一個內容深、觀點多、有時帶點幽默的網路媒體。我們聚集了科技業的業內人士，從專業的角度探討科技業有興趣的議題，包括國際合作、新科技、領袖、商業策略、遊戲、動畫、法律、職場生活、以及創業等。有時這裡的讀者留言比原文更精采，是令作者們又高興又不好意思的特色之一。