蟑螂數據庫？Google前工程師企圖開源實現Spanner精簡版

【編者按】MapReuce、Google File System、Bigtable、Percolator、Pregel、Dremel、Spanner，近十年Google為業界貢獻了大量影響深遠的論文，也催生了許多優秀的開源產品，其中Hadoop、HBase更成為大數據處理、儲存的通用平臺。近日，Google的一批前員工，以蟑螂為項目命名，旨在建立Spanner的精簡開源版本，然而他們的時間似乎并沒有那么寬裕。

免費訂閱“CSDN大數據”微信公眾號，實時了解最新的大數據進展！

CSDN大數據，專注大數據資訊、技術和經驗的分享和討論，提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、機器學習、智能算法等相關大數據觀點，大數據技術，大數據平臺，大數據實踐，大數據產業資訊等服務。

以下為譯文：

蟑螂是這個地球上生命力最強的生物之一。沒有空氣情況下可以存活45分鐘，沒有食物時甚至可以存活超過一個月。砍下頭顱都不能殺死它們，至少不是立刻死亡，它們在沒有頭的情況下還能存活好幾天。

在Google、亞馬遜以及Facebook等科技巨人里面，工程師們先進的技術同樣是在幫助它們網站不那么容易被停掉。他們必須做到，在一個/多個服務器，甚至整個數據中心丟失的情況下，站點仍然能繼續運轉。這個至關重要，因為每一秒的停機時間都意味著巨額收入損失。

Google、亞馬遜以及Facebook等科技巨人，工程師們革新的技術同樣幫助網站不那么容易被停掉。

現在，一個開源的開發團隊希望讓所有的公司都能夠很容易的構建這種適應力強大的云計算系統，這樣就可以像Google一樣運行在線系統了。他們將這個項目叫做 CockroachDB，將它宣傳為一個能夠持久運行的數據庫。對軟件來說這個名字聽起來有些古怪，但是Spencer Kimball（創始合伙人，Google前工程師）認為它非常合適，“這個名字代表了它的非常重要的兩個特性：當然有殘存性，還有基本上能夠自發地擴展到可用的硬件。”

跟很多其他的設計用來驅動大型在線操作的開源項目類似，CockroachDB同樣基于Google的大數據論文―― Spanner。Spanner是一個影響廣泛的軟件，最終允許Goolge 在全世界范圍內上百個數據中心的數以百萬計的服務器間傳播數據，Google花費了不止5年的時間來構建它。即使已經有Google的論文，CockroachDB的程序員仍然有很多的工作要面對，這是一個很偉大的藍圖。

散布各地的Google前雇員

截至當下，這個項目還在“alpha”開發階段，遠遠沒有準備好用作產品服務。Spanner作為計算歷史上讓人印象最為深刻的系統之一，如果真能得到開源實現，或許就只有CockroachDB團隊了。他們中相當一部分是Google前工程師，即使不是Spanner項目組成員。Kimball 和Peter Mattis，作為Photoshop的開源替代品GIMP的創始合伙人，幫助創立了Google的大文件存儲系統 Colossus。Ben Darnell在Google Reader工作過，Andy Bonventre則曾經為Chrome和Google Tasks工作過。

團隊中的大部分成員現在為支付新貴Square（Viewfinder被收購后）工作，包括including Kimball、Andy Kimball、Darnell、Mattis以及 Shawn Morel。但是Kimball指出Square不支持CockroachDB。他和他的同事只能利用業余時間在開發。有些人，比如Bonventre和Tobias Schottdorf，則非Square員工。

只在晚上以及周末來重構Spanner聽起來有點天方夜譚了，即使是地球上最好的工程師。然而，并不是每一個公司都需要達到Google的級別，但是Kimball指出Viewfinder團隊已經使用了一些Google的技術，在Square漸入佳境并且很快就能派上用場。并且因為在市場上還沒有類似Spanner的產品，Kimball和他們的公司才下決心自己創建它。

CockroachDB并不試圖復制Spanner最引人注目的部分――使用原子鐘（atomic clock）來同步跨全球網絡的數據中心的時間。考慮到大部分的在線運營商不太可能達到Google的規模（同時運行成千上萬的服務器），他們并不需要這個。Kimball指出，這些公司實際需要一種非常可靠的方式用來自動在不同的數據中心間復制信息，以保證某個數據中心丟失不會造成服務中斷，這樣一來，服務就像還在那個地方運行一樣，這就是CockroachDB旨在提供的功能。

更大的表

Spanner是另一個Google數據庫BigTable的繼任者，它打破了數據庫行業的很多悠久的傳統，開辟了新的途徑來創立高度可縮放的軟件。Google在2006年發表了一個關于BigTable的白皮書之后，它的想法很快被開源克隆所采用，比如 Cassandra和 Hbase迅速成為一些公司的核心技術，像Facebook、Twitter和Netflix，開啟了所謂“NoSQL”的改革浪潮。

但是當NoSQL數據庫幫助公司將信息存儲到大量的機器上時，也在某些方面制造了一些麻煩。像BigTable這個數據庫就犧牲了一致性這個古老的數據庫概念，這是指當你在數據庫的某一個部分做修改時，無須關心另一個部分在做什么。

問題是當數據庫就運行在一臺機器上時，一致性是相當容易的，但是當規模擴大并擴展到不同的數據中心時，一致性就變得更加困難了。對很多應用來說，比如即時消息，這不是一個大問題。但是如果你做些類似于在線銀行的事情，這就是個很大的問題了。數據庫的一部分可能會認為某人的帳戶上有很多的錢，沒有意識到所有的錢已經在另一部分被取走了。另外，缺少一致性，當部分數據庫出現故障了也會引起問題。Spanner解決了這些問題，CockroachDB追隨了它的腳步。

與蟑螂一樣的生命力

Spanner在不犧牲性能的同時保證了跨數據中心的一致性。另外通過F1，使得公司可以使用標準的SQL語句查詢數據庫（通用語就是信息檢索）。盡管運行了成千上萬的服務器，Spanner數據庫就像是在一臺單獨的機器上運行一樣。如果數據中心故障了，應用可以通過簡單的ping另一個數據中心來獲取需要的信息，因為所有的數據是跨數據中心無縫同步。CouchroachDB可以做一些類似的事情，盡管沒有原子鐘，它可能沒有那么快完成或者同步那么多數據。

Kimball和他的同事的目標是創建些比Google的產品更容易建立的東西，Google的基礎項目傾向于相互依賴。Spanner 需要Colossus，而Colossus也需要稱之為Chubby的維護系統。但是CockroachDB的目標是創建一個獨立的系統，它不需要依靠某些特定的文件系統或者文件管理器。這個團隊同樣計劃添加F1這個SQL查詢工具到這個項目。Kimball指出如果亞馬遜或者其他的云主機公司開始添加原子鐘到他們的數據中心，CockroachDB最終也可以利用起來。

Kimball指出，如果這個數據庫最終超越了一些有內部資源來管理的大公司，一些商業公司將需要為軟件提供支持。但是Kimball也指出需要早點考慮這個問題。如果這些確實發生了，這個計劃是否需要尋找一個更好聽的名字呢？Kimball不這樣認為。“人們更容易記住一些帶有強烈正面或者負面情緒的東西，這個已經得到了證明。”他說，“我也想找到一個帶有超強正面情緒沖擊的名字，但是我沒有找到，“RainbowDB”聽起來就很沒勁。

原文鏈接： http://www.wired.com/2014/07/cockroachdb/（翻譯/海霞  責編/仲浩）

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈