• 原文鏈接：https://www.cockroachlabs.com/blog/hello-world/
• 原作者：Spencer Kimball
• 原文日期：Jun 4, 2015
• 譯：zifeiy

數據庫是世界上每個企業的心臟，支撐著小至幾個簡單的表格，大到成千上萬臺服務器。
並且他們進化的速度非常快。
在蟑螂實驗室（Cockroach Labs）的大多數工程師在他們的職業生涯中都一直在維護並觀察這些數據庫的運行狀態，當他們發現數據庫出現這樣或那樣的瓶頸的時候，他們便會著力解決這些出現的瓶頸問題。

但是首先，為什麽要選擇“COckroach”？
雖然他的外表長的很荒誕，但是請相信他有一個強韌的內心。
你聽說過蟑螂會是世紀末日後唯一的幸存者嗎？
現代數據庫系統通過模仿自然界最古老和最成功的設計而獲得了很多收獲。
生存，復制，擴散。
這是古老的地質時代中蟑螂的模型，當然也是我們的。
即使“蟑螂”這個聽上去感覺會被遺忘，但是也無所謂啦。

在20世紀初，當我們還在Google工作的時候，我們很快就遇到了在行業當中非常普遍的數據庫的問題：應用程序級別的分片（application-level sharding）。
如果你有大量的數據（可能是TB級別的甚至是PB級別的）要存儲到數據庫中應該怎麽辦呢？
很簡單，解決的辦法就是：你把這些數據切分出來，就像切分蛋糕一樣，然後把一塊蛋糕放到一個數據庫裏，再把另一塊蛋糕放到另一個數據庫裏，如此循環，盡量多地切分蛋糕，然後分到不同的數據庫裏（當然我這裏說的蛋糕就是分片）。
但是如果數據的增長速度非常快怎麽辦？
簡而言之，大量的數據面臨的挑戰是：更多的分片，更多的問題，在分片操作時客戶將不能訪問數據庫，服務器過載，安裝復雜度也會越來越大。
我們對大規模數據面臨的困難提供了良好的鑒別能力。

快進到20世紀中期，那個時候Google迎來了NoSQL的運動。
為了簡單起見，NoSQL犧牲了傳統關系型數據庫(RDBMS)的一些性能。
一個更簡單的設計允許商品硬件透明的可擴展性。
自此數據庫開發可以像使用單個數據庫一樣，但是這個數據庫背後的數據庫集群所能支持的數據量卻能達到聞所未聞的大小。
但是我們觀察到，NoSQL的這些簡化最終成為了開發人員的致命弱點，因為在使用NoSQL的過程中，將使用越來越復雜的應用程序邏輯來處理NoSQL所缺失的一些功能，比如事務。
NoSQL面臨的這些問題需要下一代的新的數據庫系統設計來解決一致性和事務性的問題。

在2012年我們團隊離開了Google取創建一個圖片共享平臺Viewfinder。
在這段時期，為數十億用戶提供服務的夢想並不是白日做夢，我夢有一個遠大的夢想。
但是當我們為我們優秀的基礎設施尋求一種開源的解決方案的時候，才發現理想和顯示之間存在著一條宏大的溝。
（譯者的理解：他們想在開源產品中尋找一款跟在Google的時候用起來很好的NewSQL產品，但是沒有發現開源界有，然後他們就準備自己造一個）
我們（在使用市面上的這些開源NoSQL產品時）犯過懵逼，體面的搭建，有的時候使用復雜的解決辦法也是可能的，在必要的地方使用管道膠帶。
事實證明，調試這些NoSQL產品並不是我們的首要目標，我們根本沒有那麽多時間來解決使用這些NoSQL產品時遇到的問題（破產品bug太多了!!!）。

所以我們決定以建立一款優秀的分布式數據庫產品為我們的首要使命。
於是乎我們建立了蟑螂實驗室（Cockroach Labs）並且確立了一個明確的目標：建立一個我們多年以來就像建立的數據庫產品，並且使他在建立之初就是開源的。
這項任務很簡單，並且我們非常驕傲的承諾：讓數據變得簡單（Make Data Easy）。

我們想要的這個數據庫支持伸縮性，容災性，始終是一致的，並且支持抽象，以使得他更易於使用。
我們寧願花時間來快速構建及叠代一個新的產品，也不願意對現有數據庫的缺陷進行工程解決方案。（譯者的理解：作者再次強調你們這些開源NoSQL產品bug太多了，該bug的時候還不如重新做一個沒啥bug的數據庫呢）
而這個數據庫(CockroachDB)將會是我們在成立下一家公司時所使用的數據庫。
並且時我們下下個公司，下下下個公司……所使用的數據庫。

如今，我們為搭建推出蟑螂DB。
使用他，
構建他，
為他做出Contribute吧！

Ben, Peter & Spencer

CockroachDB學習筆記——[譯]Hello World