編者按：費用管理公司 Expensify 第一次設計數據庫結構，是為了建立自己的公司信用卡系統。與金融機構合作有著嚴格的要求：響應時間在毫秒內、多臺服務器實時復制、每一個交易都必須記錄，并進行身份驗證等。當時，這些要求對于一個想要建立一個高層次、企業級架構的創業公司來說無疑是矯枉過正的。當公司把精力耗費在昂貴的報告上時，強大的技術處理也是必不可少的。創業公司往往不知道，他們的早期決策是多么得有價值。Expensify 的創始人兼 CEO David Barrett （大衛·巴雷特）也是在后來才意識到早期限制Expensify的數據庫架構關系著企業的許多關鍵性競爭優勢。
在超過八年的時間里，巴雷特見證了數據庫設計早期的大量投資所帶來的優勢。這種優勢不僅體現在產品的功能，也創新了一個激進的商業模式，以此來贏得不同于競爭對手的客戶青睞。客戶量在2015增長了超過120%，超過同行業競爭對手近70%。費用管理公司現在服務著超過20000家公司。巴雷特認為，公司的成功，很大一部分應該歸功于技術決策，特別是得以依靠非常強大的數據庫體系。
First Round Review 對巴雷特進行了獨家專訪，談到了數據庫系統和一個創業公司是怎樣因此陷入危機的。并且就一些應該要避免的錯誤進行了解釋性說明。他分享了創業公司技術和商業模式的規模化和實現成功的三個關鍵步驟。最后，他還分享了校正數據庫體系結構的方法。
許多初創公司在數據庫體系的建立一事上會存在動搖
初創公司都知道，他們應該是“數據驅動”型的公司，但很少能在做出關鍵技術決策時知道這究竟意味著什么。“當您剛開始創業時，您沒有數據，也沒有客戶。您所做的一切都可以簡單地用一個由單一的Web服務器支持的單一數據庫搞定。你會選擇使用舊式機器，或者是目前流行的那款，然后還會覺得這是最好的選擇了。“巴雷特說。“隨著公司的發展，慢慢地，單個服務器的性能或可靠性不再適用，您開始需要多臺服務器。接著，你會把一臺臺的服務器增加到你曾經單一的數據中心，公司的產能也會隨著規模的逐漸擴大而增加。”
這就是為什么一些方法會讓許多創業者落入陷阱：
到處都是松鼠。在皮克斯的一個電影《飛屋環游記》中，主人公在聊金毛獵犬道格時，話說到一半，突然停下來，大叫“松鼠！很多時候想到的不一定就是看到的。“大多數公司都會在他們最熟悉的領域來創業。這是一個安全的選擇，它有效地在最開始讓風險最小化。不幸的是，人們對過去熟悉，但是世界屬于未來，“巴雷特說。“有膽識的公司總是退后一步，看看有什么新鮮的或者比熟悉的更好的東西。這當然是好的。但是，很多公司把“時髦”誤認為是“好”，然后在他們猶豫用什么時，選擇一些恰好流行但卻未經檢驗的技術。事實上。這種做法會慢慢地將你的創業公司置于死地的。
幾年前，巴雷特曾就職于一個公司。這個公司試圖建立一個早期版本的Dropbox。“所有的技術是當時有的，但他們堅持不用簡單的集中式系列服務器而要用那個名叫JXTA的糟糕透頂的P2P技術。我們那時候沒有客戶，也沒有多少數據需要來存儲，但我們的首席技術官偏要把整個公司賭上來用這個分布式系統，并且聲稱這是得以擴展到PB級數據的唯一途徑，”巴雷特說。“跟很多看上去不錯，綜合性很強的解決方法一樣，它根本不可能實現預期目標。這種技術簡直是一個噩夢，之后也再沒有在生產環境中使用過。公司幾次調整戰略，最終，在四年后一個融合新舊，新一代Dropbox的解決方案問世了。”
任何初創公司的關鍵挑戰是新舊結合，保證最新科技不會被扼殺在搖籃里。
你不是 Google。這并不是說你將來不能或者不會成為像 Google 那樣。但不要一開始就做這個假設。“當下流行的技術是給那些已經出現規模效應、有著復雜需求的成熟公司的。那些都是理想中的新技術。你作為一個新創的品牌公司，需求跟像 Google 這樣的大公司相同的可能性是微乎其微的，” 巴雷特說，“像Postgres的數據庫也不錯，但是它們都不夠酷炫。Google 用的那種有特色的數據庫技術聽上去更有意思。我想要像Google，所有我就要選擇那種技術。”
但人們往往忽略了，Google 以他那種方式發展技術基礎是因為它要運行世界上最大的搜索引擎。“搜索引擎的驅動技術是跟其他商業網站的驅動不一樣的。Google 每天需要吸收大量的數據，而其中只有一小部分是變化或有趣的。也就是說，Google 基本上每天都會拷貝一份互聯網數據。這意味著它能夠使用數據索引的方法，非常快速地搜索和添加數據，但數據一旦添加，選擇性地刪除或更改就會非常緩慢。這對Google來說沒有太大影響,因為這種事情他們每天都會做一遍。” 巴雷特說，“絕大多數企業都不能這么做。相反，他們需要慢慢積累更密集的數據集，包括帳戶、密碼和可編輯的文件，這些原始的數據你都不能只是扔掉，然后重新開始收集，它是需要時間，不斷更新積累的。”
你的創業公司每天都在做網上的一份拷貝嗎？如果不是，停止試圖模仿Google的數據庫架構。
如何明智地選擇數據庫體系結構
復制許多流行的或你喜歡的公司的技術基礎的危險之處就在于，這些公司很可能與你的公司非常不同。他們的決定對于你來說可能是種約束。但對于他們來說需要小心翼翼的限制因素，可能成為你的亮點。這里列舉幾項設計數據庫架構時能夠減輕這種風險的方法。
拒絕被引誘，做好你的打算。人們很容易驚異于數據庫的強大性能，而不考慮自己的實際需要。“當你聽到一個數據庫可以控制一千多臺電腦和處理PB級數據的時候，不要昏頭了。首先，問自己：“我可能會有多少數據需要處理？”，你是不大可能需要那么大的處理量的，” ”巴雷特說，“即使在今天，如果我們不關心的可靠性和可維護性，我們公司可能現在用的還是建立公司五年時的那套數據庫服務器。人們忘記了，今天的電腦功能是如此強大卻又如此廉價。你的手機處理的數據量是美國宇航局去月球上帶的電腦的10000倍，甚至一個簡單的服務器處理的數據量也是它的1000倍。對于一般的創業公司，幾年內，單一的服務器難以處理所需數據的可能性是微乎其微的。
優先維護生產能力。“今天，最便宜的戴爾服務器有一個雙核2.8ghz處理器和500gb磁盤陣列存儲，價格剛剛超過700美元。升級到一個有著64GB的RAM和10TB存儲的8核3.7ghz處理器版本，只需要約3200美元，花銷遠小于Expensify每個月在咖啡上的花費。大多數創業公司在提高自己市場上最便宜的服務器前就倒閉或者被收購了。特別是現在存儲成本下降的速度遠遠快于大多數創業公司成長速度。即使使用EC2付費云托管，它仍然需要支付兩倍的違約金。無論你的硬件是租的還是買的，機器容量永遠不會成為絕大多數創業公司的一個真正的問題。維修保養才是最難的部分。如果你的單個服務器出問題了-或者你只是需要升級一下-當你重新啟動它之后又會發生什么？你的整個服務就癱瘓了。總而言之，現在的電腦這么地便宜，多備幾臺，不是在提高生產能力，而是純屬多余。”
為安全問題鉆牛角尖兒。“大多數數據庫可以以兩種方式訪問。第一個是在數據庫上做一個通用查詢。另一種方法是通過存儲過程來訪問。誠然，所有的數據庫都有安全措施，但他們也存在區別，“巴雷特說。“最流行的新數據庫依賴于內置到Web服務器的代碼。它的問題是，你的Web服務器十分有可能被攻破，因為他們直接連在互聯網上。不懷好意者可以繞過安全措施，并不受限制地訪問數據庫。但如果一個存儲過程在數據庫內執行，網絡黑客難以觸及，這樣能夠保證在數據庫層面的安全性。然而，絕大多數的創業公司-尤其是消費類公司-卻選擇使用不夠安全的技術。這樣一旦他們有了客戶，在不停機的前提下進行安全改造的成本遠比從一開始就做好安全工作高得多。”
初創公司在數據庫安全方面還是應該保證，如果有閑置資金，最好買一個更安全的服務器。下面是應該怎么做。
早期，成長期。消費者，企業。每一家創業公司都有自己的情況，但巴雷特認為，有一個經驗法則的方法，可以服務于一系列正在尋求智能化和實現目的性數據庫架構的技術公司。下面是如何做：
從三個數據庫開始。巴雷特認為，今天的技術讓這成為可能，每一個初創公司應該在創業第一天就有三個數據中心。“三是一個神奇的數字，”他說。“一個還不夠，因為它壞掉只是時間問題。可能連不上網或者主機癱瘓。不管是哪種情況出現，都是問題，一個單一的數據庫是無法解決這個問題的。兩個數據中心存在的問題是，你很容易受到所謂的“分裂大腦綜合癥”的影響，如果兩個數據中心的服務器之間失去了聯系，一旦兩者之一完全或暫時無法訪問，一切就都陷入了混亂。如果，在同一時間，他們都認為對方死機了，那么他們都認為他們是在充當主機，然后一直做著備份。在我們看來，就是他們都在消耗著相同的費用，成本會翻倍。顯然這是不劃算的。”
用一個時鐘，你總是能夠知道時間。但是如果有兩個不同的時鐘，你永遠不會知道確切的時間，因為你不知道哪一個才是正確的。
由于一個數據中心是脆弱的，兩個容易出現責任不明的問題，那就選擇使用三個數據中心的服務器。“如果你有三個數據中心，這意味著在任何一時間點上，你可以失去一個完整的數據中心，還有兩個剩余的。兩個數據中心是足以正常運行的，“巴雷特說。“這聽起來已經挺多了，但它同樣可能出現問題。但是，即使問題出現了，在沒有人催促逼迫的時候，正面解決問題會更有效一些。這種情況下，投資者不至于對你失望，客戶也不用擔心。因為前期規模已經奠定了基礎。所以準備三個不同的數據中心或在AWS內準備三個不同的可用性區域吧。這一點都不貴，而且還簡單，只是需要不凡的遠見。”
查找和使用復制技術。為什么更多的創業公司創業時不用三個數據中心？公司創立初期建立三個數據中心意味著，在你有數據需要處理之前，-你得要先復制。每個數據中心中的每個服務器都需要不斷地互相之間共享數據，這樣每個服務器才能共享同一級別的信息。
“但備用或備份服務器可以很大程度上優化原始的復制技術。主機癱瘓的時候，整體都喪失了工作能力。這種故障轉移過程要不是通過手動，要不就是隨著請求沿途自定義腳本的過程一起被攻擊。無論以哪種方式，都是全局性的問題，最終將會影響到客戶，“巴雷特說。“更現代的解決方案充分考慮到復制和故障轉移問題，這樣，一個服務器死機也不會產生太大影響，無需手動操作，也不影響客戶。此外，不同于原始的解決方案被設計在一個單一的數據中心，依賴快速而可靠的網絡，新的解決方案能使優化工作在相對緩慢和不可靠的互聯網連接情況下也能實現。”
問題的一部分來自，過時的關系數據庫管理系統仍然處于主導地位。“想要使用MySQL，是非常困難的。因為這是一個舊的數據庫，它最初是為小容量、運行速度慢的磁盤設計的。文件系統不能大于4GB。而現在，情況與那時大不相同了，“巴雷特說。“今天，所有的一切都是在固態硬盤或緩存在內存中，因此超快速。這是MySQL的難題。它還在不斷優化，現在仍在被使用。所以它有所有的舊世界的包袱，但它著實不具備新世界的優勢。”
有一些工具可以幫助在不同的數據中心同步服務器，但開放源代碼，易于安裝的工具才剛剛出現。“一些舊的解決方案與三個數據中心同步啟動仍然是艱難的，這些在沒有預言機那么強大的機器之前的2007年是不可能實現的。公平地說，Percona可能會奏效，但那時它剛被開發，我都沒聽說過，”巴雷特說。“因為我有做PtoP網絡軟件的背景，所以決定建立一個我們自己的解決方案。由此，產生了calledbedrock，它易于操作，并能實時復制，也不像 Oracle或MySQL那么復雜。就每一個服務器而言，只是在它的本地有一個單一的數據庫，該技術將它們連接起來，并實現所有的復制功能。為了好玩，我們也會讓它運行MySQL協議，它幾乎可以作為一種簡易替換器件。”
“如果還有其他的解決方案可供選擇，Expensify計劃無償放棄這項技術。“最初，它只是一個專有的解決方案，因為我們找不到現成的。但隨著時間的推移，我們意識到他強大的功能，任何人都可以用它。由于自動無縫聚類的思想，那些關心性能和可用性的人十分在意無損故障轉移”巴雷特說，“但很少有人會因此來自行建立。因為其核心技術-Paxos的分布式一致性算法，很難得到正解。也正是它使得一組同等服務器能夠可靠地選出一個主機，來協調分布式事務和平衡流量，并在故障發生的0毫秒之內做出反應。但我們已經花了八年的時間來讓它跨過幾個數量級，所以它還并不適用于很多現實世界的情況，因此，我們還在不斷做出改進和準備，讓它被更廣泛的使用。”
決定你的數據是否需要分區。在從不同的數據中心選擇三個服務器并選擇一個復制技術后，還要決定是否將數據分區。分區涉及將一個數據庫分解成完整的獨立部分。這種選擇會影響很多未來的決定。
提到分區，需要問一個問題：我想讓每一位用戶與其他用戶共享數據還是將用戶群互相分割開？
“幾乎每個人開始都是“脫節的群體”，這是最簡單的概念。無論你是為個人提供消費品還是為企業提供商品，用戶之間的關系在開始時就已經很明顯，“巴雷特說。“例如，如果你正在做企業文檔存儲，事情一開始就很明朗，你只需要在公司內部的員工之間共享文檔。你甚至可能與企業客戶簽訂合同，這也要求數據被物理隔離-不管如何，這樣做總沒壞處。”
風險是有一天你可能遇到一個意外情況，需要將以前你覺得不會有聯系的幾方聯系起來。“想象一個法律公司為兩個不同的客戶工作，每一個都托管在兩個不同的數據庫上。突然分托的模型不適用了，因為正在使用一個數據庫的公司不能調閱另一個數據庫中的文件。你的技術現在阻礙了這一關鍵用例來提供產品支持-糟糕的是，你可能已經在此前提下通過簽署企業協議鞏固了這項技術。
另一種方法是提前設計一個通道，以備用戶之間有朝一日共享數據，也就是從一開始就設計一個共享的數據庫。“這需要你采用完全不同的技術路徑，因為你不能再從硬件層面解決問題。如果你的數據庫滿了，你不能再為你的下一批客戶買一個，你需要找到一種方法來升級整個系統-而不是單純只為某個客戶，“巴雷特說。“為所有用戶保持一個單一的連續數據庫的好處是，你可以消除客戶之間資源分享的約束，無論是立刻還是在未來的任何時間。缺點是一個單一的巨大的數據庫，比一堆小的數據庫更難維護-尤其是如果你正在使用一個舊的數據庫解決方案的時候。”
正確的入門課程
不是每一次的創業都能華麗地從頭開始。如果你已經做了一些其他的選擇-故意或不知情的-還有方法來走回正道。撞擊道岔，轉換方向可能不那么輕松，但火車其實還沒有駛離車站。
· 選擇在多個可用性區域中復制的數據庫。“很多公司會說，“我已經有了一個EC2，立馬就能運行我的web服務器，一個單一的RDS就是我的數據庫，或者我把一些數據存儲在S3里。這都是一個單一的可用性區域。“不要一開始就讓自己陷入困境：與亞馬遜一起構建能支持多個可用性區域或完全不同的數據中心。”
· 嘗試Expensify的復制技術。“從MySQL換到Bedrock很簡單：如果數據量小，你可以在深夜關掉你的服務器，把數據導出，再導入到Bedrock。您的Web服務器不會受到任何影響。因為Bedrock執行的也是MySQL協議。”
· 從存儲過程開始。“問問你自己：“如果黑客襲擊我的服務器，后果會有多嚴重？如果答案是“特別糟糕”，那么將您的驗證邏輯移到數據庫中的存儲過程中。它會更安全，能保持更好的分層，并為最終用戶提供更好的服務。”
結合
大多數人不會覺得數據庫結構很酷。但在擁有客戶和他們的數據之前，充分了解也是很重要的。你如何組織，規劃和保證這些數據的安全不僅會對你的技術產生作用，而且還會影響你的商業模式的可擴展性。保證在每三個不同的數據中心或可用性區域中至少有一個服務器。選擇一個允許它們精確、可靠地相互通信的復制技術。檢查您的用戶之間的關系，以決定是否應分區您的數據。充分考慮存儲的程序來保護您的數據。最大的挑戰不是決定去采取這種做法，而是怎樣順利地從MySQL一類的流行數據庫管理系統中轉變過來。
“不要把自己的角色設定為 Google，以此來圍繞數據庫架構做決定。但也不要把在創業時有太多拘束，這會阻礙公司發展成為像 Google一樣成熟的公司。事實上，許多初創公司在這些問題出現前，就已經失敗了。你需要問問自己：你是在變得更好還是更壞？”巴雷特說。“嚴格的要求和機會，其實早就迫使我們做出更多關于數據庫架構的思考。我們現在知道，堅實的基礎不僅幫助我們按著預期的目標擴大規模，也為我們從未想過的深數據和人工智能技術提供支持。這些可能在我們第一次作出數據庫架構的決定的時候就確定好了。這個系統架構像一個大桶，收納了以任何你能想象的方式存在的數據。而另一個選擇則是糟糕的。如果你沒有意識到你在第一天就建立了一個監獄，將來遇到的困難可能是無法解決的。”
翻譯來自：蟲洞翻翻 譯者ID 郭洋陽
編者按：費用管理公司 Expensify 第一次設計數據庫結構，是為了建立自己的公司信用卡系統。與金融機構合作有著嚴格的要求：響應時間在毫秒內、多臺服務器實時復制、每一個交易都必須記錄，并進行身份驗證等。當時，這些要求對于一個想要建立一個高層次、企業級架構的創業公司來說無疑是矯枉過正的。當公司把精力耗費在昂貴的報告上時，強大的技術處理也是必不可少的。創業公司往往不知道，他們的早期決策是多么得有價值。Expensify 的創始人兼 CEODavid Barrett （大衛·巴雷特）也是在后來才意識到早期限制Expensify的數據庫架構關系著企業的許多關鍵性競爭優勢。
在超過八年的時間里，巴雷特見證了數據庫設計早期的大量投資所帶來的優勢。這種優勢不僅體現在產品的功能，也創新了一個激進的商業模式，以此來贏得不同于競爭對手的客戶青睞。客戶量在2015增長了超過120%，超過同行業競爭對手近70%。費用管理公司現在服務著超過20000家公司。巴雷特認為，公司的成功，很大一部分應該歸功于技術決策，特別是得以依靠非常強大的數據庫體系。
First Round Review 對巴雷特進行了獨家專訪，談到了數據庫系統和一個創業公司是怎樣因此陷入危機的。并且就一些應該要避免的錯誤進行了解釋性說明。他分享了創業公司技術和商業模式的規模化和實現成功的三個關鍵步驟。最后，他還分享了校正數據庫體系結構的方法。
許多初創公司在數據庫體系的建立一事上會存在動搖
初創公司都知道，他們應該是“數據驅動”型的公司，但很少能在做出關鍵技術決策時知道這究竟意味著什么。“當您剛開始創業時，您沒有數據，也沒有客戶。您所做的一切都可以簡單地用一個由單一的Web服務器支持的單一數據庫搞定。你會選擇使用舊式機器，或者是目前流行的那款，然后還會覺得這是最好的選擇了。“巴雷特說。“隨著公司的發展，慢慢地，單個服務器的性能或可靠性不再適用，您開始需要多臺服務器。接著，你會把一臺臺的服務器增加到你曾經單一的數據中心，公司的產能也會隨著規模的逐漸擴大而增加。”
這就是為什么一些方法會讓許多創業者落入陷阱：
到處都是松鼠。在皮克斯的一個電影《飛屋環游記》中，主人公在聊金毛獵犬道格時，話說到一半，突然停下來，大叫“松鼠！很多時候想到的不一定就是看到的。“大多數公司都會在他們最熟悉的領域來創業。這是一個安全的選擇，它有效地在最開始讓風險最小化。不幸的是，人們對過去熟悉，但是世界屬于未來，“巴雷特說。“有膽識的公司總是退后一步，看看有什么新鮮的或者比熟悉的更好的東西。這當然是好的。但是，很多公司把“時髦”誤認為是“好”，然后在他們猶豫用什么時，選擇一些恰好流行但卻未經檢驗的技術。事實上。這種做法會慢慢地將你的創業公司置于死地的。
幾年前，巴雷特曾就職于一個公司。這個公司試圖建立一個早期版本的Dropbox。“所有的技術是當時有的，但他們堅持不用簡單的集中式系列服務器而要用那個名叫JXTA的糟糕透頂的P2P技術。我們那時候沒有客戶，也沒有多少數據需要來存儲，但我們的首席技術官偏要把整個公司賭上來用這個分布式系統，并且聲稱這是得以擴展到PB級數據的唯一途徑，”巴雷特說。“跟很多看上去不錯，綜合性很強的解決方法一樣，它根本不可能實現預期目標。這種技術簡直是一個噩夢，之后也再沒有在生產環境中使用過。公司幾次調整戰略，最終，在四年后一個融合新舊，新一代Dropbox的解決方案問世了。”
任何初創公司的關鍵挑戰是新舊結合，保證最新科技不會被扼殺在搖籃里。
你不是 Google。這并不是說你將來不能或者不會成為像Google那樣。但不要一開始就做這個假設。“當下流行的技術是給那些已經出現規模效應、有著復雜需求的成熟公司的。那些都是理想中的新技術。你作為一個新創的品牌公司，需求跟像Google這樣的大公司相同的可能性是微乎其微的，” 巴雷特說，“像Postgres的數據庫也不錯，但是它們都不夠酷炫。Google用的那種有特色的數據庫技術聽上去更有意思。我想要像Google，所有我就要選擇那種技術。”
但人們往往忽略了，Google以他那種方式發展技術基礎是因為它要運行世界上最大的搜索引擎。“搜索引擎的驅動技術是跟其他商業網站的驅動不一樣的。Google每天需要吸收大量的數據，而其中只有一小部分是變化或有趣的。也就是說，Google基本上每天都會拷貝一份互聯網數據。這意味著它能夠使用數據索引的方法，非常快速地搜索和添加數據，但數據一旦添加，選擇性地刪除或更改就會非常緩慢。這對Google來說沒有太大影響,因為這種事情他們每天都會做一遍。” 巴雷特說，“絕大多數企業都不能這么做。相反，他們需要慢慢積累更密集的數據集，包括帳戶、密碼和可編輯的文件，這些原始的數據你都不能只是扔掉，然后重新開始收集，它是需要時間，不斷更新積累的。”
你的創業公司每天都在做網上的一份拷貝嗎？如果不是，停止試圖模仿Google的數據庫架構。
如何明智地選擇數據庫體系結構
復制許多流行的或你喜歡的公司的技術基礎的危險之處就在于，這些公司很可能與你的公司非常不同。他們的決定對于你來說可能是種約束。但對于他們來說需要小心翼翼的限制因素，可能成為你的亮點。這里列舉幾項設計數據庫架構時能夠減輕這種風險的方法。
拒絕被引誘，做好你的打算。人們很容易驚異于數據庫的強大性能，而不考慮自己的實際需要。“當你聽到一個數據庫可以控制一千多臺電腦和處理PB級數據的時候，不要昏頭了。首先，問自己：“我可能會有多少數據需要處理？”，你是不大可能需要那么大的處理量的，” ”巴雷特說，“即使在今天，如果我們不關心的可靠性和可維護性，我們公司可能現在用的還是建立公司五年時的那套數據庫服務器。人們忘記了，今天的電腦功能是如此強大卻又如此廉價。你的手機處理的數據量是美國宇航局去月球上帶的電腦的10000倍，甚至一個簡單的服務器處理的數據量也是它的1000倍。對于一般的創業公司，幾年內，單一的服務器難以處理所需數據的可能性是微乎其微的。
優先維護生產能力。“今天，最便宜的戴爾服務器有一個雙核2.8ghz處理器和500gb磁盤陣列存儲，價格剛剛超過700美元。升級到一個有著64GB的RAM和10TB存儲的8核3.7ghz處理器版本，只需要約3200美元，花銷遠小于Expensify每個月在咖啡上的花費。大多數創業公司在提高自己市場上最便宜的服務器前就倒閉或者被收購了。特別是現在存儲成本下降的速度遠遠快于大多數創業公司成長速度。即使使用EC2付費云托管，它仍然需要支付兩倍的違約金。無論你的硬件是租的還是買的，機器容量永遠不會成為絕大多數創業公司的一個真正的問題。維修保養才是最難的部分。如果你的單個服務器出問題了-或者你只是需要升級一下-當你重新啟動它之后又會發生什么？你的整個服務就癱瘓了。總而言之，現在的電腦這么地便宜，多備幾臺，不是在提高生產能力，而是純屬多余。”
為安全問題鉆牛角尖兒。“大多數數據庫可以以兩種方式訪問。第一個是在數據庫上做一個通用查詢。另一種方法是通過存儲過程來訪問。誠然，所有的數據庫都有安全措施，但他們也存在區別，“巴雷特說。“最流行的新數據庫依賴于內置到Web服務器的代碼。它的問題是，你的Web服務器十分有可能被攻破，因為他們直接連在互聯網上。不懷好意者可以繞過安全措施，并不受限制地訪問數據庫。但如果一個存儲過程在數據庫內執行，網絡黑客難以觸及，這樣能夠保證在數據庫層面的安全性。然而，絕大多數的創業公司-尤其是消費類公司-卻選擇使用不夠安全的技術。這樣一旦他們有了客戶，在不停機的前提下進行安全改造的成本遠比從一開始就做好安全工作高得多。”
初創公司在數據庫安全方面還是應該保證，如果有閑置資金，最好買一個更安全的服務器。下面是應該怎么做。
早期，成長期。消費者，企業。每一家創業公司都有自己的情況，但巴雷特認為，有一個經驗法則的方法，可以服務于一系列正在尋求智能化和實現目的性數據庫架構的技術公司。下面是如何做：
從三個數據庫開始。巴雷特認為，今天的技術讓這成為可能，每一個初創公司應該在創業第一天就有三個數據中心。“三是一個神奇的數字，”他說。“一個還不夠，因為它壞掉只是時間問題。可能連不上網或者主機癱瘓。不管是哪種情況出現，都是問題，一個單一的數據庫是無法解決這個問題的。兩個數據中心存在的問題是，你很容易受到所謂的“分裂大腦綜合癥”的影響，如果兩個數據中心的服務器之間失去了聯系，一旦兩者之一完全或暫時無法訪問，一切就都陷入了混亂。如果，在同一時間，他們都認為對方死機了，那么他們都認為他們是在充當主機，然后一直做著備份。在我們看來，就是他們都在消耗著相同的費用，成本會翻倍。顯然這是不劃算的。”
用一個時鐘，你總是能夠知道時間。但是如果有兩個不同的時鐘，你永遠不會知道確切的時間，因為你不知道哪一個才是正確的。
由于一個數據中心是脆弱的，兩個容易出現責任不明的問題，那就選擇使用三個數據中心的服務器。“如果你有三個數據中心，這意味著在任何一時間點上，你可以失去一個完整的數據中心，還有兩個剩余的。兩個數據中心是足以正常運行的，“巴雷特說。“這聽起來已經挺多了，但它同樣可能出現問題。但是，即使問題出現了，在沒有人催促逼迫的時候，正面解決問題會更有效一些。這種情況下，投資者不至于對你失望，客戶也不用擔心。因為前期規模已經奠定了基礎。所以準備三個不同的數據中心或在AWS內準備三個不同的可用性區域吧。這一點都不貴，而且還簡單，只是需要不凡的遠見。”
查找和使用復制技術。為什么更多的創業公司創業時不用三個數據中心？公司創立初期建立三個數據中心意味著，在你有數據需要處理之前，-你得要先復制。每個數據中心中的每個服務器都需要不斷地互相之間共享數據，這樣每個服務器才能共享同一級別的信息。
“但備用或備份服務器可以很大程度上優化原始的復制技術。主機癱瘓的時候，整體都喪失了工作能力。這種故障轉移過程要不是通過手動，要不就是隨著請求沿途自定義腳本的過程一起被攻擊。無論以哪種方式，都是全局性的問題，最終將會影響到客戶，“巴雷特說。“更現代的解決方案充分考慮到復制和故障轉移問題，這樣，一個服務器死機也不會產生太大影響，無需手動操作，也不影響客戶。此外，不同于原始的解決方案被設計在一個單一的數據中心，依賴快速而可靠的網絡，新的解決方案能使優化工作在相對緩慢和不可靠的互聯網連接情況下也能實現。”
問題的一部分來自，過時的關系數據庫管理系統仍然處于主導地位。“想要使用MySQL，是非常困難的。因為這是一個舊的數據庫，它最初是為小容量、運行速度慢的磁盤設計的。文件系統不能大于4GB。而現在，情況與那時大不相同了，“巴雷特說。“今天，所有的一切都是在固態硬盤或緩存在內存中，因此超快速。這是MySQL的難題。它還在不斷優化，現在仍在被使用。所以它有所有的舊世界的包袱，但它著實不具備新世界的優勢。”
有一些工具可以幫助在不同的數據中心同步服務器，但開放源代碼，易于安裝的工具才剛剛出現。“一些舊的解決方案與三個數據中心同步啟動仍然是艱難的，這些在沒有預言機那么強大的機器之前的2007年是不可能實現的。公平地說，Percona可能會奏效，但那時它剛被開發，我都沒聽說過，”巴雷特說。“因為我有做PtoP網絡軟件的背景，所以決定建立一個我們自己的解決方案。由此，產生了calledbedrock，它易于操作，并能實時復制，也不像 Oracle或MySQL那么復雜。就每一個服務器而言，只是在它的本地有一個單一的數據庫，該技術將它們連接起來，并實現所有的復制功能。為了好玩，我們也會讓它運行MySQL協議，它幾乎可以作為一種簡易替換器件。”
“如果還有其他的解決方案可供選擇，Expensify計劃無償放棄這項技術。“最初，它只是一個專有的解決方案，因為我們找不到現成的。但隨著時間的推移，我們意識到他強大的功能，任何人都可以用它。由于自動無縫聚類的思想，那些關心性能和可用性的人十分在意無損故障轉移”巴雷特說，“但很少有人會因此來自行建立。因為其核心技術-Paxos的分布式一致性算法，很難得到正解。也正是它使得一組同等服務器能夠可靠地選出一個主機，來協調分布式事務和平衡流量，并在故障發生的0毫秒之內做出反應。但我們已經花了八年的時間來讓它跨過幾個數量級，所以它還并不適用于很多現實世界的情況，因此，我們還在不斷做出改進和準備，讓它被更廣泛的使用。”
決定你的數據是否需要分區。在從不同的數據中心選擇三個服務器并選擇一個復制技術后，還要決定是否將數據分區。分區涉及將一個數據庫分解成完整的獨立部分。這種選擇會影響很多未來的決定。
提到分區，需要問一個問題：我想讓每一位用戶與其他用戶共享數據還是將用戶群互相分割開？
“幾乎每個人開始都是“脫節的群體”，這是最簡單的概念。無論你是為個人提供消費品還是為企業提供商品，用戶之間的關系在開始時就已經很明顯，“巴雷特說。“例如，如果你正在做企業文檔存儲，事情一開始就很明朗，你只需要在公司內部的員工之間共享文檔。你甚至可能與企業客戶簽訂合同，這也要求數據被物理隔離-不管如何，這樣做總沒壞處。”
風險是有一天你可能遇到一個意外情況，需要將以前你覺得不會有聯系的幾方聯系起來。“想象一個法律公司為兩個不同的客戶工作，每一個都托管在兩個不同的數據庫上。突然分托的模型不適用了，因為正在使用一個數據庫的公司不能調閱另一個數據庫中的文件。你的技術現在阻礙了這一關鍵用例來提供產品支持-糟糕的是，你可能已經在此前提下通過簽署企業協議鞏固了這項技術。
另一種方法是提前設計一個通道，以備用戶之間有朝一日共享數據，也就是從一開始就設計一個共享的數據庫。“這需要你采用完全不同的技術路徑，因為你不能再從硬件層面解決問題。如果你的數據庫滿了，你不能再為你的下一批客戶買一個，你需要找到一種方法來升級整個系統-而不是單純只為某個客戶，“巴雷特說。“為所有用戶保持一個單一的連續數據庫的好處是，你可以消除客戶之間資源分享的約束，無論是立刻還是在未來的任何時間。缺點是一個單一的巨大的數據庫，比一堆小的數據庫更難維護-尤其是如果你正在使用一個舊的數據庫解決方案的時候。”
正確的入門課程
不是每一次的創業都能華麗地從頭開始。如果你已經做了一些其他的選擇-故意或不知情的-還有方法來走回正道。撞擊道岔，轉換方向可能不那么輕松，但火車其實還沒有駛離車站。
·選擇在多個可用性區域中復制的數據庫。“很多公司會說，“我已經有了一個EC2，立馬就能運行我的web服務器，一個單一的RDS就是我的數據庫，或者我把一些數據存儲在S3里。這都是一個單一的可用性區域。“不要一開始就讓自己陷入困境：與亞馬遜一起構建能支持多個可用性區域或完全不同的數據中心。”
·嘗試Expensify的復制技術。“從MySQL換到Bedrock很簡單：如果數據量小，你可以在深夜關掉你的服務器，把數據導出，再導入到Bedrock。您的Web服務器不會受到任何影響。因為Bedrock執行的也是MySQL協議。”
·從存儲過程開始。“問問你自己：“如果黑客襲擊我的服務器，后果會有多嚴重？如果答案是“特別糟糕”，那么將您的驗證邏輯移到數據庫中的存儲過程中。它會更安全，能保持更好的分層，并為最終用戶提供更好的服務。”
結合
大多數人不會覺得數據庫結構很酷。但在擁有客戶和他們的數據之前，充分了解也是很重要的。你如何組織，規劃和保證這些數據的安全不僅會對你的技術產生作用，而且還會影響你的商業模式的可擴展性。保證在每三個不同的數據中心或可用性區域中至少有一個服務器。選擇一個允許它們精確、可靠地相互通信的復制技術。檢查您的用戶之間的關系，以決定是否應分區您的數據。充分考慮存儲的程序來保護您的數據。最大的挑戰不是決定去采取這種做法，而是怎樣順利地從MySQL一類的流行數據庫管理系統中轉變過來。
“不要把自己的角色設定為Google，以此來圍繞數據庫架構做決定。但也不要把在創業時有太多拘束，這會阻礙公司發展成為像Google一樣成熟的公司。事實上，許多初創公司在這些問題出現前，就已經失敗了。你需要問問自己：你是在變得更好還是更壞？”巴雷特說。“嚴格的要求和機會，其實早就迫使我們做出更多關于數據庫架構的思考。我們現在知道，堅實的基礎不僅幫助我們按著預期的目標擴大規模，也為我們從未想過的深數據和人工智能技術提供支持。這些可能在我們第一次作出數據庫架構的決定的時候就確定好了。這個系統架構像一個大桶，收納了以任何你能想象的方式存在的數據。而另一個選擇則是糟糕的。如果你沒有意識到你在第一天就建立了一個監獄，將來遇到的困難可能是無法解決的。”
翻譯來自：蟲洞翻翻 譯者ID 郭洋陽
京公網安備 11010502049343號