譯者注：原文題為 a comparison of advanced modern cloud database. 個(gè)人因興趣翻譯划煮，歡迎批評(píng)指正！
【譯文】
本文是一篇面向Aurora盆赤、Cosmos霉祸、Spanner 的現(xiàn)代云數(shù)據(jù)庫解決方案導(dǎo)引脐湾。
最近這些年乳乌，涌現(xiàn)出一些讓人印象深刻的云計(jì)算技術(shù)捧韵，范圍涉及拓展傳統(tǒng)數(shù)據(jù)庫的可擴(kuò)展性（Aurora），到利用定制硬件實(shí)現(xiàn)創(chuàng)新設(shè)計(jì)以獲取足夠的規(guī)模（Spanner）汉操。伴隨著數(shù)據(jù)無止盡的增長纫版，很多組織面臨新的問題，我們現(xiàn)在所使用的工具并沒有同比升級(jí)客情。
普通用戶很難跟蹤新工具的發(fā)展其弊，也很難準(zhǔn)確區(qū)分他們之間的差異，所以我嘗試匯總這些不同產(chǎn)品膀斋，并對(duì)比他們之間的差異梭伐。
不太可能簡單評(píng)價(jià)哪個(gè)是最好的選擇，有很多因素需要權(quán)衡仰担，不同組織要基于自己面臨的問題來選擇合適的技術(shù)糊识。雖然下面對(duì)比表中的很多特性的選擇是基于它們對(duì)于幫助構(gòu)建簡裝軟件的重要性，但不得不承認(rèn)仍會(huì)有一些偏見在里面摔蓝。當(dāng)然選擇哪些技術(shù)來對(duì)比本身也是一定的偏見赂苗。可以有很多選項(xiàng)贮尉，我沒有選擇大部分拌滋；這個(gè)列表僅聚焦在那些最常見的目標(biāo)、最實(shí)用性和最有趣的方面猜谚。
我把一些收藏的觀點(diǎn)放在文尾部分败砂。
對(duì)比表
各列含義說明
* 并發(fā) ACID：數(shù)據(jù)庫是否支持 ACID（原子性，一致性魏铅，隔離性昌犹，持久性）影響涉及很多操作。ACID 是保證系統(tǒng)正確性的強(qiáng)有力的工具览芳，直到最近它已經(jīng)是分布式數(shù)據(jù)庫長期追求但迷惑的幻想斜姥。我使用并發(fā) ACID 這個(gè)詞是因?yàn)榧夹g(shù)上 Cosmos 保證 ACID，但只能限制在單一操作中沧竟。
* HA：數(shù)據(jù)庫是否是高可用（HA）铸敏。雖然在列表我將每個(gè)數(shù)據(jù)庫都標(biāo)記為支持 HA，但一些比其他產(chǎn)品更高可用屯仗，CockroachDB搞坝、Cosmos、Spanner 在這方面處于領(lǐng)先地位魁袜。其他則傾向于依賴單一節(jié)點(diǎn)的故障轉(zhuǎn)移技術(shù)桩撮。
* 水平擴(kuò)展：數(shù)據(jù)庫是否可以通過增加節(jié)點(diǎn)實(shí)現(xiàn)水平擴(kuò)展敦第。表中除了 Postgres 外都支持，但我包含該列是為了突顯一個(gè)事實(shí)店量，不像其他產(chǎn)品芜果，Aurora 的擴(kuò)展性僅是磁盤。這并不是說它不適合使用融师，只是一些提醒（見 Amazon Aurora 的下面細(xì)節(jié)說明）右钾。
* 自動(dòng)數(shù)據(jù)分片：區(qū)分?jǐn)?shù)據(jù)庫數(shù)據(jù)分片、負(fù)載是手工處理還是由數(shù)據(jù)庫自動(dòng)完成旱爆。以一個(gè)手工的數(shù)據(jù)庫為例舀射，在 CitusDB 或 MongoDB 你需要明確的告訴數(shù)據(jù)庫，你想要一個(gè)表是分布式的怀伦，基于什么主鍵來進(jìn)行分片（例如user_id)脆烟。相對(duì)而言，Spanner自動(dòng)算出如何去分布存儲(chǔ)的數(shù)據(jù)到有效的節(jié)點(diǎn)房待，以及必要的重新均衡邢羔。這兩種選擇都是可行的，但手工分布需要更多的操作成本桑孩，如果沒有足夠的看護(hù)拜鹤，會(huì)導(dǎo)致不均衡的分片，尤其是大節(jié)點(diǎn)過度的負(fù)載運(yùn)行流椒。
* 低延遲：在要求很低的延遲操作（小于1ms）的情景下敏簿，CockroachDB、Cosmos 利用額外的內(nèi)部節(jié)點(diǎn)的協(xié)調(diào)來保證滿足不合適的成本镣隶。我在基于時(shí)間的一致性中會(huì)就此更多細(xì)節(jié)說明极谊。
附加的考慮因素
CAP
CAP 定理指出：給定的一致性，100%可用性和分區(qū)容忍性安岂，任何數(shù)據(jù)庫最多可以滿足三個(gè)中的兩個(gè)。
為了說明為什么CAP沒有包含在上面的表中帆吻，我會(huì)引用Eric Brewer（谷歌 基礎(chǔ)設(shè)施VP）關(guān)于 Spanner 的論述域那。
盡管作為一款全球分布的系統(tǒng)，Spanner 宣稱一致性和高可用猜煮，這暗示無分區(qū)次员，因此存疑。這表示 Spanner 是一個(gè) CA 系統(tǒng)（依據(jù) CAP 的定義）王带？簡單的回答式技術(shù)性的“不”淑蔚，但在效果上“是”。它的用戶可以假定 CA愕撰。
純粹主義的回答式“不”刹衫，因?yàn)榉謪^(qū)可以做醋寝，事實(shí)谷歌也是這么做，在一些分區(qū)Spanner 選擇 C带迟，損失 A音羞。它可以技術(shù)的定義為 CP 系統(tǒng)。我們將在下面探討分區(qū)的影響仓犬。
假定 Spanner 總是提供一致性嗅绰，聲明CA 的真正問題 Spanner嚴(yán)謹(jǐn)?shù)挠脩羰欠駮?huì)假設(shè)它的可用性。如果它實(shí)際可用性很高以致于用戶可以忽略運(yùn)行中斷搀继，這樣 Spanner 可改為支持有效的 CA窘面。這不是暗示100%的可用性（而且 Spanner 現(xiàn)在不會(huì)將來也不會(huì)提供它），而是5個(gè)9或更高（10的5次方會(huì)有1次或更少的失斶辞）财边。反過來，實(shí)際更簡單有效的方法是用戶是否寫代碼來處理中斷異常（如果他們需要自己的服務(wù)高可用）：如果他們沒有寫這樣的代碼险毁，他們實(shí)際是假定高可用制圈。由于已有大批使用的Spanner的內(nèi)部用戶，我們知道他們是認(rèn)為 Spanner 是高可用的畔况。
換句話說鲸鹦，現(xiàn)代技術(shù)可以實(shí)現(xiàn) CP，而且它可以保持非常好的可用性跷跪，如像5個(gè)9以上的好馋嗜。這結(jié)果是如此理想，以致于現(xiàn)代的數(shù)據(jù)庫似乎都聚焦在此吵瞻。列表中的每個(gè)數(shù)據(jù)庫都是支持CP葛菇，但在 A 上有不同級(jí)別的支持。
基于時(shí)間的一致性
像 Spanner 和CockroachDB這樣的復(fù)雜的分布式系統(tǒng)都傾向于需要多一點(diǎn)時(shí)間去協(xié)調(diào)和核實(shí)任意給定節(jié)點(diǎn)返回結(jié)果的準(zhǔn)確性橡羞。這使得對(duì)低延遲操作的符合度降低眯停。
Quizlet 建議， Spanner 操作的最小延遲為小于5ms。Spanner 論文在章節(jié)4.1和4.2中，描述不同操作的協(xié)調(diào)細(xì)節(jié)结笨。CockroachDB 在他們的 FAQ 中明確表示，它不適合用于對(duì)低延遲讀寫要求極其嚴(yán)格的場景齐邦。
微軟 Cosmos 的設(shè)計(jì)沒有公開，但它的文檔表明相似的性能特征第租，讀寫耗時(shí)的中位數(shù)是5ms措拇。
競爭者
Amazon Aurora
Aurora是一款托管的關(guān)系數(shù)據(jù)庫，擁有與 MySQL 和 Postgres 兼容的SQL接口慎宾。它其中一個(gè)最大的賣點(diǎn)是性能丐吓。它宣稱在相同硬件環(huán)境下浅悉，可以提供5倍于 MySQL和2倍于 Postgres 的吞吐量。
Aurora與列表中的其他產(chǎn)品有很大的不同汰蜘，因?yàn)樗诠?jié)點(diǎn)層面不能水平擴(kuò)展仇冯，它的集群更類似于傳統(tǒng)關(guān)系數(shù)據(jù)庫的一主（讀寫）多從（讀）。代替的是族操，亞馬遜設(shè)計(jì)了存儲(chǔ)層擴(kuò)展方案苛坚，允許表在尺寸上顯著的增長，這要比你見過的傳統(tǒng)關(guān)系數(shù)據(jù)庫要大的色难，最多可達(dá)到單表64TB泼舱。
這種基于存儲(chǔ)的擴(kuò)展有它的不足，計(jì)算和內(nèi)存資源（用于寫和一致性讀）被限制在單一垂直擴(kuò)展的節(jié)點(diǎn)枷莉，但它同樣也有很明顯的優(yōu)勢：數(shù)據(jù)存在一個(gè)位置上娇昙，所以延時(shí)很低。它也意味著笤妙，你不會(huì)弄錯(cuò)分區(qū)模式冒掌，進(jìn)而導(dǎo)致一些分片過熱，需要重新均衡負(fù)載（這種現(xiàn)象很容易發(fā)生蹲盘，但很難解決）股毫。相比 CockroachDB、Spanner召衔，如果用戶需要大量的擴(kuò)展铃诬，但有不需要無限擴(kuò)展時(shí)，它可能是個(gè)合適的選擇苍凛。
CitusDB
CitusDB 是一款基于 Postgres 的分布式數(shù)據(jù)庫趣席，允許單個(gè)表分片和分布到任意數(shù)量上的節(jié)點(diǎn)上。它提供聰明的觀念醇蝴，如引用表可以保證數(shù)據(jù)局部性以提升查詢效率宣肚。ACID 的保證是在特定的節(jié)點(diǎn)范圍內(nèi)的，這個(gè)節(jié)點(diǎn)通常夠用的悠栓，因?yàn)榉制O(shè)計(jì)保證數(shù)據(jù)都在該節(jié)點(diǎn)上钉寝。
最值得說明的是， CitusDB 是開源的闸迷，使用 Postgres 擴(kuò)展 API 來運(yùn)行。這減少了鎖定的風(fēng)險(xiǎn)俘枫，這是列表中其他選項(xiàng)最需要考慮的負(fù)面因素腥沽。相比于 Aurora，它意味著你更可能在你的數(shù)據(jù)庫中看到新版 Postgres 的新特性鸠蚪。
相比 CockroachDB 而言今阳，它的不好的一點(diǎn)是师溅，它的數(shù)據(jù)需要手工分片的，正如上面提到的盾舌，這會(huì)導(dǎo)致負(fù)載問題墓臭。另一個(gè)考慮的因素是，它由一個(gè)新公司發(fā)布妖谴，這個(gè)公司的商業(yè)模式也未得到證明窿锉。通常選擇一款數(shù)據(jù)庫，冷靜的頭腦需要知道膝舅，你所用的東西在未來十年內(nèi)一定要被很好的維護(hù)管理的嗡载。當(dāng)產(chǎn)品是由大型公司研制的，你可能會(huì)很自信仍稀，如亞馬遜洼滚、谷歌、微軟技潘，但如果小公司遥巴，你的信心會(huì)少。
CockroachDB
CockroachDB是由Cockroch實(shí)驗(yàn)室發(fā)布的產(chǎn)品享幽，該公司由前谷歌員工創(chuàng)立铲掐，他最有影響力的是他創(chuàng)建了谷歌文件系統(tǒng)（GFS）和谷歌閱讀器（Google Reader）。它基于已經(jīng)公布的最初的Spanner 論文設(shè)計(jì)的琉闪，像 Spanner 一樣迹炼，使用基于時(shí)間的機(jī)制來實(shí)現(xiàn)一致性，但沒有谷歌 GPS 和原子時(shí)鐘的支持颠毙。
它提供可序列化的分布式事務(wù)斯入，外鍵和輔助索引。它開源蛀蜜，并用 Go 開發(fā)刻两，后者使得在開發(fā)環(huán)境中易安裝、易運(yùn)行滴某。它們的文檔寫的很清晰磅摹，易于閱讀，坦率霎奢。如以它們已知的限制為例户誓。
像 Spanner，附加的保持分布式一致性意味著幕侠，當(dāng)需要低延時(shí)操作時(shí)帝美，它是不好的選擇（他們自己也承認(rèn)）。像 上面的 CitusDB晤硕，由商業(yè)模式未知的小公司發(fā)布也是一個(gè)負(fù)面因素悼潭。
微軟Cosmos
Cosmos是微軟全新的云數(shù)據(jù)庫庇忌。它的銷售勢頭很強(qiáng)勁。例如舰褪，這有一段關(guān)于他們無預(yù)定結(jié)構(gòu)的設(shè)計(jì)的摘錄皆疹，所宣傳的是著名的權(quán)衡或更少，一個(gè)反特色：
關(guān)系數(shù)據(jù)庫和 no-sql 數(shù)據(jù)庫都強(qiáng)迫你去處理模式和索引的管理占拍、版本管理略就、遷移[……]但不用擔(dān)心，Cosmos DB讓這些問題走開刷喜。
這說明残制，它擁有一組很好的特點(diǎn)。
* 快速且容易的跨區(qū)域分布掖疮。
* 可配置的一致性模型初茶，包括從強(qiáng)一致性到最終一致性（為速度犧牲讀取順序錯(cuò)亂的可能）。
* 操作 SLA時(shí)間保證浊闪，99%的情況下恼布，讀小于10ms，索引寫小于15ms搁宾。
像 CockroachDB 和 Spanner 一樣折汞，Cosmos 的分布式架構(gòu)使得它不是很適應(yīng)用于低延遲要求的應(yīng)用。它們的文檔表示讀寫延遲的中位數(shù)是5ms盖腿。
Cosmos 憑借基于 JavaScript 的存儲(chǔ)過程的使用爽待，可以提供 ACID。這似乎是依靠只有一個(gè) JavaScript 運(yùn)行時(shí)運(yùn)行在主節(jié)點(diǎn)翩腐，所以一個(gè)時(shí)間只有一個(gè)腳本被處理鸟款，但它也同事記錄一些記錄，以保證任意的寫可以被還原茂卦，因此確保真正的原子性（不像Redis 的 EVAL）何什。盡管如此，這種方法也沒有像 MVCC 引擎那樣復(fù)雜（后者則被應(yīng)用在列表中的其他數(shù)據(jù)庫中）等龙，因?yàn)樗荒芴峁┎l(fā)使用处渣。
MongoDB
MongoDB 是一款 NoSQL 數(shù)據(jù)存儲(chǔ)，它以無模式JSON 文檔方式存儲(chǔ)數(shù)據(jù)蛛砰。它不支持 ACID 事務(wù)罐栈，如果這夠用，關(guān)于它2009的發(fā)行版泥畅，有大量關(guān)于核心競爭力的合理批評(píng)悠瞬，包括持久性、安全性、正確性浅妆。
為了對(duì)比，我已經(jīng)將其包括在內(nèi)障癌，因?yàn)樗匀贿€有很多值得關(guān)注點(diǎn)凌外，但就復(fù)雜度而言，它和列表上的其他系統(tǒng)已經(jīng)不在一個(gè)級(jí)別上了涛浙。其他的大部分有嚴(yán)格的功能超集康辑，但也支持其他極其重要的特色，如 ACID 的保證轿亮。新項(xiàng)目不應(yīng)該基于 MongoDB 開展疮薇，而老系統(tǒng)應(yīng)該考慮從它遷移走。
Postgres
Postgres是一款值得信賴的傳統(tǒng)關(guān)系數(shù)據(jù)庫我注。內(nèi)置不支持 HA按咒，但借助亞馬遜 RDS、Heroku Postgres或 Azure Database 來實(shí)現(xiàn)（谷歌運(yùn) SQL 也很快支持）但骨。
即使它不如列表中其他產(chǎn)品完美励七，我仍然將它包含在內(nèi)，因?yàn)樗匀皇呛芏嗍褂脠鼍暗淖罴堰x擇奔缠。大部分組織都沒有他們所認(rèn)為的那么多的數(shù)據(jù)掠抬，通過有意識(shí)的限制膨脹，他們可以放棄垂直擴(kuò)展的 Postgres 節(jié)點(diǎn)校哎。這會(huì)促成更可操作的棧两波，更多的選擇，萬一必須在云和供應(yīng)商之間遷移闷哆。你可以在本地運(yùn)行 Postgres 或測試腰奋，這對(duì)于無沖突的生產(chǎn)能力很重要。
結(jié)尾
觀點(diǎn)時(shí)間：對(duì)于大多數(shù)人阳准，最好的選擇是從 Postgres 開始氛堕。它是久經(jīng)考驗(yàn)的數(shù)據(jù)庫，擁有非常多的特性野蝇，同時(shí)限制也很少讼稚。它是開源的，廣泛的可用性绕沈，所以它可以很容易的運(yùn)行在部署環(huán)境锐想、CI，甚至是遷移至主流的云廠商乍狐。垂直擴(kuò)展能力可以支持組織很長時(shí)間的需求赠摇。
在你達(dá)到AirBnB 或Uber 的級(jí)別時(shí)，像 Aurora 會(huì)更有趣。它看起來擁有很多 Postgres 的優(yōu)點(diǎn)藕帜，仍然可以管理維護(hù)數(shù)據(jù)的位置和擴(kuò)展的存儲(chǔ)（代價(jià)時(shí)失去開發(fā)與生產(chǎn)的對(duì)等烫罩，鎖定在特定廠商）。這個(gè)層次的組織運(yùn)轉(zhuǎn)繁忙洽故，需要計(jì)算和內(nèi)存資源能擴(kuò)展超越單節(jié)點(diǎn)贝攒，此時(shí)將會(huì)收益像 CitusDB 這樣的替代品。
在你達(dá)到谷歌的級(jí)別時(shí)时甚，一些接近 Spanner 的產(chǎn)品可能是正確的選擇隘弊。雖然延遲會(huì)有所增加，但它的擴(kuò)展性會(huì)表現(xiàn)的更無限制荒适。
列表中的數(shù)據(jù)庫梨熙，在生產(chǎn)環(huán)境中，我只見過 MongoDB 和 Postgres刀诬，所以應(yīng)該謹(jǐn)慎的看待這些建議咽扇。幾乎可以肯定的是，隨著進(jìn)一步了解舅列，關(guān)于他們的注意事項(xiàng)會(huì)逐漸顯現(xiàn)肌割。
原文鏈接：https://brandur.org/cloud-databases?utm_source=dbweekly&utm_medium=email
