Megastore：为交互式服务提供可扩展的高可用性存储
目錄
? ? ? ? 1?簡介
? ? ? ??2 以可用性和規(guī)模為目標(biāo)
? ? ? ??3?A TOUR OF?Megastore
? ? ? ??4?復(fù)制
? ? ? ??5?經(jīng)驗(yàn)
? ? ? ??6?相關(guān)工作
? ? ? ??7?結(jié)論
Megastore：為交互式服務(wù)提供可擴(kuò)展的高可用性存儲(chǔ)
摘要：Megastore 是為滿足當(dāng)今交互式在線服務(wù)的要求而開發(fā)的存儲(chǔ)系統(tǒng)。Megastore 以一種新穎的方式將?NoSQL?數(shù)據(jù)存儲(chǔ)的可擴(kuò)展性與傳統(tǒng)關(guān)系數(shù)據(jù)庫管理系統(tǒng)的便利性相結(jié)合，并提供了強(qiáng)大的一致性保證和高可用性。我們?cè)跀?shù)據(jù)的細(xì)粒度分區(qū)（fine-grained partitions of data）中提供完全可序列化的ACID語義。這種分區(qū)允許我們以合理的延遲在廣域網(wǎng)上同步復(fù)制每個(gè)寫操作，并支持?jǐn)?shù)據(jù)中心之間的無縫故障轉(zhuǎn)移。本文描述了?Megastore 的語義和復(fù)制算法。它還描述了我們支持使用?Megastore 構(gòu)建的各種谷歌生產(chǎn)服務(wù)的經(jīng)驗(yàn)。
關(guān)鍵詞：大型數(shù)據(jù)庫，分布式事務(wù)，BigTable，Paxos
?
1?簡介
隨著桌面應(yīng)用程序向云遷移，交互式在線服務(wù)正迫使存儲(chǔ)社區(qū)滿足新的需求。電子郵件、協(xié)作文檔和社交網(wǎng)絡(luò)等服務(wù)一直呈指數(shù)級(jí)增長，并在測試現(xiàn)有基礎(chǔ)架構(gòu)的局限性。由于許多相互沖突的需求，滿足這些服務(wù)的存儲(chǔ)需求具有挑戰(zhàn)性。
首先，互聯(lián)網(wǎng)帶來了大量的潛在用戶，因此應(yīng)用程序必須具有高度的可擴(kuò)展性。服務(wù)可以使用?MySQL?作為其數(shù)據(jù)存儲(chǔ)庫快速構(gòu)建，但要將服務(wù)擴(kuò)展到數(shù)百萬用戶，需要對(duì)其存儲(chǔ)基礎(chǔ)架構(gòu)進(jìn)行徹底的重新設(shè)計(jì)。第二，服務(wù)必須爭奪用戶。這需要快速開發(fā)功能和快速上市。第三，服務(wù)必須有響應(yīng)性；因此，存儲(chǔ)系統(tǒng)必須具有低延遲。第四，服務(wù)應(yīng)該為用戶提供一致的數(shù)據(jù)視圖——更新的結(jié)果應(yīng)該是立即可見且持久的。看到云托管的電子表格編輯消失，無論多么短暫，都是糟糕的用戶體驗(yàn)。最后，用戶已經(jīng)開始期望互聯(lián)網(wǎng)服務(wù)全天候運(yùn)行，因此服務(wù)必須高度可用。該服務(wù)必須能夠應(yīng)對(duì)多種故障，從單個(gè)磁盤、機(jī)器或路由器的故障一直到影響整個(gè)數(shù)據(jù)中心的大規(guī)模停機(jī)。
這些要求是沖突的。關(guān)系數(shù)據(jù)庫為輕松構(gòu)建應(yīng)用程序提供了一套豐富的功能，但它們很難擴(kuò)展到數(shù)億用戶。NoSQL?的數(shù)據(jù)存儲(chǔ)庫，如谷歌的?Bigtable 、Apache Hadoop?的?HbBase?或?Facebook?的?Cassandra?具有高度可擴(kuò)展性，但它們有限的?API?和松散的一致性模型使應(yīng)用程序開發(fā)變得復(fù)雜。在提供低延遲的同時(shí)跨遠(yuǎn)程數(shù)據(jù)中心復(fù)制數(shù)據(jù)是一項(xiàng)挑戰(zhàn)，因?yàn)楸ＷC復(fù)制數(shù)據(jù)的一致視圖也是一項(xiàng)挑戰(zhàn)，尤其是在故障期間。
Megastore 是為滿足當(dāng)今交互式在線服務(wù)的存儲(chǔ)要求而開發(fā)的存儲(chǔ)系統(tǒng)。它的新穎之處在于它將?NoSQL?數(shù)據(jù)存儲(chǔ)的可擴(kuò)展性與傳統(tǒng)關(guān)系數(shù)據(jù)庫管理系統(tǒng)的便利性結(jié)合在一起。它使用同步復(fù)制來實(shí)現(xiàn)高可用性和一致的數(shù)據(jù)視圖。簡而言之，它在遠(yuǎn)程副本上提供了完全可序列化的ACID語義，具有足夠低的延遲來支持交互式應(yīng)用程序。
我們通過在關(guān)系數(shù)據(jù)庫管理系統(tǒng)和?NoSQL?的設(shè)計(jì)采取折中的辦法實(shí)現(xiàn)這一點(diǎn)：我們對(duì)數(shù)據(jù)存儲(chǔ)區(qū)進(jìn)行分區(qū)，并分別復(fù)制每個(gè)分區(qū)，在分區(qū)內(nèi)提供完整的ACID語義，但在它們之間只有有限的一致性保證。我們提供了傳統(tǒng)的數(shù)據(jù)庫功能，例如輔助索引，但是只有那些能夠在用戶可容忍的延遲限制內(nèi)擴(kuò)展的功能，并且只有我們的分區(qū)方案能夠支持的語義。我們認(rèn)為，大多數(shù)互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)可以進(jìn)行適當(dāng)?shù)姆謪^(qū)（例如，按用戶），以使這種方法可行，并且一組小而不簡單的功能可以大大減輕開發(fā)云應(yīng)用程序的負(fù)擔(dān)。
與傳統(tǒng)觀點(diǎn)相反，我們能夠使用 Paxos 構(gòu)建一個(gè)高可用性的系統(tǒng)，該系統(tǒng)在跨地理分布的數(shù)據(jù)中心同步復(fù)制寫操作的同時(shí)，為交互式應(yīng)用程序提供合理的延遲。雖然許多系統(tǒng)只將 Paxos 用于鎖定、選主、復(fù)制元數(shù)據(jù)和配置，但我們認(rèn)為，Megastore 是部署的最大的系統(tǒng)，它在每次寫入時(shí)都使用 Paxos 跨數(shù)據(jù)中心復(fù)制主用戶數(shù)據(jù)。
Megastore 已經(jīng)在谷歌內(nèi)部廣泛部署了幾年。它每天處理?30?多億次寫入和?200?億次讀取事務(wù)，并在許多全球數(shù)據(jù)中心存儲(chǔ)近?1PB 的主要的數(shù)據(jù)。本文的主要貢獻(xiàn)是：
(1) 數(shù)據(jù)模型和存儲(chǔ)系統(tǒng)的設(shè)計(jì)，允許交互式應(yīng)用程序的快速開發(fā)，從一開始就內(nèi)置高可用性和可擴(kuò)展性；
(2) Paxos復(fù)制和一致性算法的實(shí)現(xiàn)，針對(duì)地理上分布的數(shù)據(jù)中心的低延遲操作進(jìn)行了優(yōu)化，為系統(tǒng)提供了高可用性；
(3) 一份關(guān)于我們?cè)诠雀璐笠?guī)模部署?Megastore 的經(jīng)驗(yàn)的報(bào)告。
論文組織如下。第?2?節(jié)描述了?Megastore 如何使用分區(qū)提供可用性和可擴(kuò)展性，并證明了我們的設(shè)計(jì)對(duì)于許多交互式互聯(lián)網(wǎng)應(yīng)用程序的充分性。第?3?節(jié)概述了?Megastore 的數(shù)據(jù)模型和功能。第?4?節(jié)詳細(xì)解釋了復(fù)制算法，并給出了一些關(guān)于它們?cè)趯?shí)踐中如何執(zhí)行的度量。第?5?節(jié)總結(jié)了我們開發(fā)該系統(tǒng)的經(jīng)驗(yàn)。我們?cè)诘?/span>?6?節(jié)回顧相關(guān)工作。第七節(jié)總結(jié)。
?
?
2 以可用性和規(guī)模為目標(biāo)
與我們對(duì)全球、可靠且任意大規(guī)模的存儲(chǔ)平臺(tái)的需求形成對(duì)比的是，我們的硬件構(gòu)建模塊受到地理位置的限制，容易出現(xiàn)故障，并且容量有限。我們必須將這些組件綁定到一個(gè)統(tǒng)一的整體中，以提供更大的吞吐量和可靠性。為此，我們采取了雙管齊下的方法：
(1) 為了可用性，我們實(shí)現(xiàn)了一個(gè)同步、容錯(cuò)的日志復(fù)制器，該復(fù)制器針對(duì)長距離鏈路進(jìn)行了優(yōu)化；
(2) 為了擴(kuò)大規(guī)模，我們將數(shù)據(jù)劃分到一個(gè)巨大的小型數(shù)據(jù)庫空間中，每個(gè)數(shù)據(jù)庫都有自己的復(fù)制日志，存儲(chǔ)在每個(gè)副本的?NoSQL?數(shù)據(jù)存儲(chǔ)區(qū)中。
?
2.1?復(fù)制
在單個(gè)數(shù)據(jù)中心內(nèi)跨主機(jī)復(fù)制數(shù)據(jù)通過克服特定的主機(jī)的故障提高了可用性，但回報(bào)不斷減少。我們?nèi)匀槐仨毭鎸?duì)將它們與外部世界連接起來的網(wǎng)絡(luò)，以及為它們供電、散熱和提供住所的基礎(chǔ)設(shè)施。經(jīng)濟(jì)建設(shè)的站點(diǎn)面臨一定程度的設(shè)施范圍內(nèi)的停機(jī)風(fēng)險(xiǎn)，并且容易受到區(qū)域性災(zāi)難的影響。為了讓云存儲(chǔ)滿足可用性需求，服務(wù)提供商必須在廣闊的地理區(qū)域內(nèi)復(fù)制數(shù)據(jù)。
?
2.1.1?戰(zhàn)略
我們?cè)u(píng)估了廣域復(fù)制（wide-area replication）的常見策略：
異步主/從（Asynchronous Master/Slave）
主節(jié)點(diǎn)將預(yù)寫日志條目（write-ahead log entries）復(fù)制到至少一個(gè)從節(jié)點(diǎn)。日志追加在主機(jī)上得到確認(rèn)，同時(shí)傳輸?shù)綇臋C(jī)。主服務(wù)器可以支持快速?ACID?事務(wù)，但在故障轉(zhuǎn)移到從服務(wù)器期間有停機(jī)或數(shù)據(jù)丟失的風(fēng)險(xiǎn)。調(diào)解主導(dǎo)權(quán)需要一個(gè)共識(shí)協(xié)議。
同步主/從（Synchronous Master/Slave）
主機(jī)在確認(rèn)更改之前會(huì)等待將其鏡像到從機(jī)，這樣就可以在不丟失數(shù)據(jù)的情況下進(jìn)行故障轉(zhuǎn)移。主設(shè)備和從設(shè)備故障需要外部系統(tǒng)及時(shí)檢測。
樂觀復(fù)制（Optimistic Replication）
同一個(gè)復(fù)制組的任何成員的突變（mutations，指數(shù)據(jù)的變化）是可以接受的，改變的數(shù)據(jù)通過組內(nèi)異步傳播。可用性和延遲非常好（Any member of a homogeneous?replica group can accept mutations, which are?asynchronously propagated through the group）。然而，全局變異排序在提交時(shí)是未知的，因此事務(wù)是不可能的。
我們避免了可能丟失故障數(shù)據(jù)的策略，這在大規(guī)模系統(tǒng)中很常見。我們還放棄了不允許?ACID事務(wù)的策略。盡管最終一致性的系統(tǒng)具有操作上的優(yōu)勢，但在快速的應(yīng)用程序開發(fā)中，放棄讀-修改-寫習(xí)慣用法是非常困難的。
我們也拋棄了重量級(jí)?master?的選項(xiàng)。故障轉(zhuǎn)移需要一系列高延遲階段，通常會(huì)導(dǎo)致用戶可見的中斷，并且仍然存在巨大的復(fù)雜性。如果我們可以完全避免?master，為什么要建立一個(gè)容錯(cuò)系統(tǒng)來選主（arbitrate mastership）和故障轉(zhuǎn)移工作流？
?
2.1.2?Enter Paxos
我們決定使用?Paxos，這是一種經(jīng)過驗(yàn)證的最佳容錯(cuò)一致性算法，不需要杰出的?master。我們?cè)谝唤M對(duì)稱的對(duì)等體上復(fù)制預(yù)寫日志。任何節(jié)點(diǎn)都可以啟動(dòng)讀取和寫入。每個(gè)日志都在大多數(shù)副本的確認(rèn)中添加塊，少數(shù)副本盡可能趕上來——該算法固有的容錯(cuò)性消除了對(duì)可區(qū)分的"失敗"狀態(tài)的需要。第?4.4.1?節(jié)詳細(xì)介紹了?Paxos?的一個(gè)新擴(kuò)展，它允許在任何最新的副本上進(jìn)行本地讀取。另一個(gè)擴(kuò)展允許單路往返寫入（single-roundtrip writes）。
即使?Paxos?具有容錯(cuò)能力，使用單個(gè)日志也有局限性。由于副本分布在很廣的區(qū)域，通信延遲限制了整體吞吐量。此外，當(dāng)沒有當(dāng)前副本或大多數(shù)副本未能確認(rèn)寫入時(shí)，進(jìn)度會(huì)受到阻礙。在一個(gè)擁有數(shù)千或數(shù)百萬用戶的傳統(tǒng)數(shù)據(jù)庫中，使用同步復(fù)制的日志會(huì)有造成廣泛影響的中斷風(fēng)險(xiǎn)。因此，為了提高可用性和吞吐量，我們使用多個(gè)復(fù)制的日志，每個(gè)日志管理自己的數(shù)據(jù)集分區(qū)。
?
?
2.2?分區(qū)和局部性
為了擴(kuò)展我們的復(fù)制方案并最大限度地提高底層數(shù)據(jù)存儲(chǔ)的性能，我們?yōu)閼?yīng)用程序提供了對(duì)其數(shù)據(jù)分區(qū)和位置的細(xì)粒度控制。
?
2.2.1?實(shí)體組
為了擴(kuò)大吞吐量和本地化中斷，我們將數(shù)據(jù)劃分為一組實(shí)體組，每個(gè)實(shí)體組在很大范圍內(nèi)獨(dú)立同步復(fù)制。底層數(shù)據(jù)存儲(chǔ)在每個(gè)數(shù)據(jù)中心的可擴(kuò)展?NoSQL?數(shù)據(jù)存儲(chǔ)中（參見圖1）。
實(shí)體組中的實(shí)體使用單階段 ACID 事務(wù)（通過 Paxos 復(fù)制提交記錄）進(jìn)行數(shù)據(jù)改寫。跨實(shí)體組的操作可能依賴于昂貴的兩階段提交，但通常利用 Megastore 的高效異步消息傳遞。發(fā)送實(shí)體組中的事務(wù)在隊(duì)列中放置一條或多條消息；接收實(shí)體組的事務(wù)原子地使用這些消息并應(yīng)用隨后發(fā)生的數(shù)據(jù)改寫。
請(qǐng)注意，我們?cè)谶壿嬌线b遠(yuǎn)的實(shí)體組之間使用異步消息傳遞，而不是物理上遙遠(yuǎn)的副本。數(shù)據(jù)中心之間的所有網(wǎng)絡(luò)流量都來自同步且一致的復(fù)制操作。實(shí)體組的局部索引服從?ACID?語義；跨實(shí)體組的一致性較弱。有關(guān)實(shí)體組上和實(shí)體組之間的各種操作，請(qǐng)參見圖2。
?
2.2.2?選擇實(shí)體組邊界
實(shí)體組為快速操作定義了數(shù)據(jù)的優(yōu)先分組。過于細(xì)粒度的邊界會(huì)強(qiáng)制執(zhí)行過多的跨組操作，但是在單個(gè)組中放置太多不相關(guān)的數(shù)據(jù)會(huì)序列化不相關(guān)的寫入，從而降低吞吐量。以下示例顯示了應(yīng)用程序在這些約束條件下的工作方式：
Email 每個(gè)電子郵件帳戶形成一個(gè)自然實(shí)體組。帳戶內(nèi)的操作是事務(wù)性的與一致性的：發(fā)送或標(biāo)記消息的用戶保證會(huì)觀察到更改，盡管可能會(huì)故障轉(zhuǎn)移到另一個(gè)副本。外部郵件路由器處理帳戶之間的通信。
Blogs?一個(gè)博客應(yīng)用程序可以用多個(gè)實(shí)體組類來建模。每個(gè)用戶都有一個(gè)配置文件，這自然是它自己的實(shí)體組。然而，博客是協(xié)作性的，沒有單一的永久所有者。我們創(chuàng)建了第二類實(shí)體組來保存每個(gè)博客的帖子和元數(shù)據(jù)。第三類提供了每個(gè)博客的唯一名稱。當(dāng)單個(gè)用戶操作同時(shí)影響博客和個(gè)人資料時(shí)，應(yīng)用程序依賴異步消息傳遞。對(duì)于流量較低的操作，比如創(chuàng)建一個(gè)新的博客并聲明它的唯一名稱，兩階段提交更方便，性能也更好。
Maps?地理數(shù)據(jù)沒有任何一致性或方便的自然粒度。映射應(yīng)用程序可以通過將地球劃分為不重疊的面片來創(chuàng)建實(shí)體組。對(duì)于跨越補(bǔ)丁的突變，應(yīng)用程序使用兩階段提交來使它們成為原子的。補(bǔ)丁必須足夠大，以至于兩階段事務(wù)不常見，但又足夠小，以至于每個(gè)補(bǔ)丁只需要很小的寫吞吐量。與前面的示例不同，實(shí)體組的數(shù)量不會(huì)隨著使用的增加而增加，因此最初必須創(chuàng)建足夠的補(bǔ)丁，以便在以后的規(guī)模上獲得足夠的聚合吞吐量。
幾乎所有基于?Megastore 構(gòu)建的應(yīng)用程序都找到了自然的方法來繪制實(shí)體組邊界。
?
2.2.3?物理布局
我們使用谷歌的?Bigtable?在單個(gè)數(shù)據(jù)中心內(nèi)實(shí)現(xiàn)可擴(kuò)展的容錯(cuò)存儲(chǔ)，允許我們通過跨多行擴(kuò)展操作來支持任意的讀寫吞吐量。我們通過讓應(yīng)用程序控制數(shù)據(jù)的放置來最小化延遲和最大化吞吐量：通過選擇?Bigtable?實(shí)例和指定實(shí)例內(nèi)的位置。
為了最大限度地減少延遲，應(yīng)用程序試圖將數(shù)據(jù)保持在用戶附近，并將副本保持在彼此附近。他們將每個(gè)實(shí)體組分配給最常訪問它的區(qū)域或大陸。在該區(qū)域內(nèi)，他們將三個(gè)或五個(gè)副本分配給具有獨(dú)立故障域的數(shù)據(jù)中心。
為了獲得低延遲、緩存效率和吞吐量，實(shí)體組的數(shù)據(jù)保存在連續(xù)的?Bigtable 行范圍內(nèi)。我們的模式語言允許應(yīng)用程序控制分層數(shù)據(jù)的放置，將一起訪問的數(shù)據(jù)存儲(chǔ)在附近的行中，或者反規(guī)范化到同一行中。
?
?
3?A TOUR OF?Megastore
Megastore 將這種架構(gòu)映射到精心選擇的功能集上，以鼓勵(lì)快速開發(fā)可擴(kuò)展的應(yīng)用程序。這一部分推動(dòng)了折衷，并描述了由此產(chǎn)生的面向開發(fā)人員的特性。
?
3.1?API?設(shè)計(jì)理念
ACID?事務(wù)簡化了對(duì)正確性的推理，但是能夠?qū)π阅苓M(jìn)行推理也同樣重要。Megastore 強(qiáng)調(diào)成本透明的?API，運(yùn)行時(shí)成本與應(yīng)用程序開發(fā)人員的直覺相匹配。規(guī)范化的關(guān)系模式依賴于查詢時(shí)的連接來服務(wù)用戶操作。出于以下幾個(gè)原因，這種模式不適合?Megastore 應(yīng)用：
(1) 與表達(dá)性查詢語言相比，高容量交互式工作負(fù)載從可預(yù)測的性能中獲益更多。
(2) 在我們的目標(biāo)應(yīng)用程序中，讀取多于寫入，因此將工作從讀取時(shí)間轉(zhuǎn)移到寫入時(shí)間是值得的。
(3) 在像?Bigtable?這樣的鍵值存儲(chǔ)中，存儲(chǔ)和查詢分層數(shù)據(jù)非常簡單。
考慮到這一點(diǎn)，我們?cè)O(shè)計(jì)了一個(gè)數(shù)據(jù)模型和模式語言來提供對(duì)物理位置的細(xì)粒度控制。分層布局和聲明性非規(guī)范化有助于消除大多數(shù)連接的需要。查詢指定對(duì)特定表和索引的掃描或查找。需要時(shí)，連接在應(yīng)用程序代碼中實(shí)現(xiàn)。我們提供了合并連接算法在合并階段的實(shí)現(xiàn)，其中用戶提供了多個(gè)查詢，這些查詢以相同的順序返回同一表的主鍵；然后，我們返回所有提供的查詢的鍵的交集。
我們也有通過并行查詢實(shí)現(xiàn)外部連接的應(yīng)用程序。這通常涉及索引查找，然后使用初始查找的結(jié)果進(jìn)行并行索引查找。我們發(fā)現(xiàn)，當(dāng)并行進(jìn)行二級(jí)索引查找，并且第一次查找的結(jié)果數(shù)量相當(dāng)少時(shí)，這就為?SQL?風(fēng)格的連接提供了一個(gè)有效的替代。
雖然模式更改需要對(duì)查詢實(shí)現(xiàn)代碼進(jìn)行相應(yīng)的修改，但該系統(tǒng)保證了在構(gòu)建特性時(shí)對(duì)其性能影響有清晰的理解。例如，當(dāng)用戶（可能沒有數(shù)據(jù)庫背景）發(fā)現(xiàn)自己在寫類似嵌套循環(huán)連接算法的東西時(shí)，他們很快意識(shí)到最好添加一個(gè)索引，并遵循上面的基于索引的連接方法。
?
3.2?數(shù)據(jù)模型
Megastore 定義了一個(gè)位于關(guān)系數(shù)據(jù)庫管理系統(tǒng)的抽象元組和?NoSQL?的具體行列存儲(chǔ)之間的數(shù)據(jù)模型。像在關(guān)系數(shù)據(jù)庫管理系統(tǒng)中一樣，數(shù)據(jù)模型在模式中聲明，并且是強(qiáng)類型的。每個(gè)模式都有一組表，每個(gè)表都包含一組實(shí)體，這些實(shí)體又包含一組屬性。屬性是命名和類型化的值。類型可以是字符串、各種類型的數(shù)字或谷歌的協(xié)議緩沖區(qū)。它們可以是必需的、可選的或重復(fù)的（允許在單個(gè)屬性中列出值）。表中的所有實(shí)體都具有相同的允許屬性集。屬性序列用于形成實(shí)體的主鍵，主鍵在表中必須是唯一的。圖?3?顯示了一個(gè)簡單照片存儲(chǔ)應(yīng)用程序的示例模式。
Megastore 表可以是實(shí)體組根表，也可以是子表。每個(gè)子表必須聲明一個(gè)引用根表的可分辨外鍵，如圖?3?中的實(shí)體組鍵注釋所示。因此，每個(gè)子實(shí)體引用其根表中的特定實(shí)體（稱為根實(shí)體）。實(shí)體組由根實(shí)體以及子表中引用它的所有實(shí)體組成。一個(gè)?Megastore 實(shí)例可以有幾個(gè)根表，從而產(chǎn)生不同類別的實(shí)體組。在圖?3?的示例模式中，每個(gè)用戶的照片集合是一個(gè)單獨(dú)的實(shí)體組。根實(shí)體是用戶，照片是子實(shí)體。請(qǐng)注意，"照片標(biāo)簽"字段是重復(fù)的，允許每個(gè)照片有多個(gè)標(biāo)簽，而不需要子表。
?
3.2.1?用鍵預(yù)連接
傳統(tǒng)的關(guān)系建模建議所有的主鍵都采用代理值，而?Megastore 鍵則被選擇來集群將一起讀取的實(shí)體。每個(gè)實(shí)體映射到一個(gè)單一的?Bigtable?行；主鍵值被連接起來形成?Bigtable?行鍵，每個(gè)剩余的屬性占用它自己的?Bigtable?列。
請(qǐng)注意圖?3?中的照片和用戶表如何共享一個(gè)公共的?user_id?key 的前綴。表內(nèi)用戶指令指示?Megastore 將這兩個(gè)表放在同一個(gè)?Bigtable 中，鍵排序確保照片實(shí)體存儲(chǔ)在相應(yīng)用戶的旁邊。這種機(jī)制可以遞歸地應(yīng)用于加速沿任意連接深度的查詢。因此，用戶可以通過操作?key 順序來強(qiáng)制分層布局。
模式聲明鍵是升序還是降序排序，或者完全避免排序：SCATTER?屬性指示?Megastore 在每個(gè)鍵前添加一個(gè)兩字節(jié)的散列。以這種方式編碼單調(diào)遞增的鍵可以防止跨?Bigtable?服務(wù)器的大型數(shù)據(jù)集中出現(xiàn)熱點(diǎn)。
?
3.2.2 ?Indexes
輔助索引可以在任何實(shí)體屬性列表上聲明，也可以在協(xié)議緩沖區(qū)中的字段上聲明。我們區(qū)分了兩個(gè)高層次的索引類別：本地和全局（見圖2）。本地索引被視為每個(gè)實(shí)體組的單獨(dú)索引。它用于在實(shí)體組中查找數(shù)據(jù)。在圖?3?中，PhotosByTime?是一個(gè)本地索引的例子。索引條目存儲(chǔ)在實(shí)體組中，并自動(dòng)更新，與主要實(shí)體數(shù)據(jù)保持一致。
全局索引跨越實(shí)體組。它用于在事先不知道包含實(shí)體的實(shí)體組的情況下查找實(shí)體。圖?3?中的?PhotosByTag?索引是全局的，可以發(fā)現(xiàn)帶有給定標(biāo)簽的照片，而不考慮所有者。全局索引掃描可以讀取許多實(shí)體組擁有的數(shù)據(jù)，但不能保證反映所有最近的更新。Megastore 提供了額外的索引功能：
3.2.2.1?存儲(chǔ)條款
通過索引訪問實(shí)體數(shù)據(jù)通常是一個(gè)兩步過程：首先讀取索引以找到匹配的主鍵，然后使用這些鍵來獲取實(shí)體。我們提供了一種將實(shí)體數(shù)據(jù)的部分直接反規(guī)格化為索引條目的方法。通過向索引中添加?STORING?子句，應(yīng)用程序可以存儲(chǔ)主表中的附加屬性，以便在讀取時(shí)更快地進(jìn)行訪問。例如，PhotosByTag?索引存儲(chǔ)照片縮略圖網(wǎng)址，以便更快地檢索，而不需要額外的查找。
?
3.2.2.2?重復(fù)索引
Megastore 提供了索引重復(fù)屬性和協(xié)議緩沖子字段的能力。重復(fù)索引是子表的有效替代。照片字節(jié)標(biāo)簽是一個(gè)重復(fù)的索引：標(biāo)簽屬性中的每個(gè)唯一條目都會(huì)代表照片創(chuàng)建一個(gè)索引條目。
?
3.2.2.3?內(nèi)聯(lián)索引
內(nèi)聯(lián)索引提供了一種將來自源實(shí)體的數(shù)據(jù)反規(guī)范化為相關(guān)目標(biāo)實(shí)體的方法：來自源實(shí)體的索引條目在目標(biāo)條目中顯示為虛擬的重復(fù)列。通過使用目標(biāo)實(shí)體的第一個(gè)主鍵作為索引的第一個(gè)組成部分，并在與目標(biāo)實(shí)體相同的?Bigtable?中物理定位數(shù)據(jù)，可以在任何具有引用另一個(gè)表的外鍵的表上創(chuàng)建內(nèi)聯(lián)索引。
內(nèi)聯(lián)索引對(duì)于從子實(shí)體中提取信息片段并將數(shù)據(jù)存儲(chǔ)在父實(shí)體中以便快速訪問非常有用。與維護(hù)多對(duì)多鏈接表相比，再加上重復(fù)的索引，它們還可以更有效地實(shí)現(xiàn)多對(duì)多關(guān)系。
PhotosByTime?索引可以作為父用戶表的內(nèi)聯(lián)索引來實(shí)現(xiàn)。這將使數(shù)據(jù)可作為正常索引或用戶的虛擬重復(fù)屬性訪問，每個(gè)包含的照片都有一個(gè)按時(shí)間排序的條目。
?
3.2.3?映射到?BigTable
Bigtable?列名是?Megastore 表名和屬性名的串聯(lián)，允許來自不同?Megastore 表的實(shí)體映射到同一個(gè)?Bigtable?行，而不會(huì)發(fā)生沖突。圖?4?顯示了示例照片應(yīng)用程序中的數(shù)據(jù)在?Bigtable?中的外觀。
在根實(shí)體的?Bigtable?行中，我們存儲(chǔ)實(shí)體組的事務(wù)和復(fù)制元數(shù)據(jù)，包括事務(wù)日志。將所有元數(shù)據(jù)存儲(chǔ)在一個(gè)?Bigtable 行中允許我們通過一個(gè)?Bigtable 事務(wù)自動(dòng)更新它。每個(gè)索引條目都表示為一個(gè)?Bigtable?行；使用與索引實(shí)體的主鍵連接的索引屬性值來構(gòu)造單元格的行鍵。例如，PhotosByTime?索引行關(guān)鍵字將是每張照片的元組（用戶?id、時(shí)間、主鍵）。對(duì)重復(fù)字段進(jìn)行索引會(huì)為每個(gè)重復(fù)元素生成一個(gè)索引條目。例如，一張帶有三個(gè)標(biāo)簽的照片的主鍵會(huì)在?PhotosByTag?索引中出現(xiàn)三次。
?
?
3.3?事務(wù)和并發(fā)控制
每個(gè)大型實(shí)體組的功能就像一個(gè)微型數(shù)據(jù)庫，提供可序列化的 ACID 語義。事務(wù)將其突變寫入實(shí)體組的提前寫日志，然后對(duì)數(shù)據(jù)應(yīng)用這些突變。
Bigtable?提供了在具有不同時(shí)間戳的同一行/列對(duì)中存儲(chǔ)多個(gè)值的能力。我們使用這個(gè)特性來實(shí)現(xiàn)多版本并發(fā)控制（MVCC）：當(dāng)一個(gè)事務(wù)中的突變被應(yīng)用時(shí)，這些值被寫入它們的事務(wù)的時(shí)間戳。讀者使用上次完全應(yīng)用的事務(wù)的時(shí)間戳來避免看到部分更新。讀者和寫者不會(huì)相互阻塞，并且在事務(wù)期間，讀取和寫入是隔離的。
Megastore 提供當(dāng)前、快照和不一致的讀取。當(dāng)前和快照讀取總是在單個(gè)實(shí)體組的范圍內(nèi)完成。當(dāng)開始當(dāng)前讀取時(shí)，事務(wù)系統(tǒng)首先確保應(yīng)用所有先前提交的寫入；然后，應(yīng)用程序讀取最近提交的事務(wù)的時(shí)間戳。對(duì)于快照讀取，系統(tǒng)獲取最后一個(gè)已知的完全應(yīng)用的事務(wù)的時(shí)間戳，并從那里讀取，即使一些已提交的事務(wù)尚未應(yīng)用。Megastore 還提供不一致讀取，忽略日志狀態(tài)，直接讀取最新值。這對(duì)于具有更嚴(yán)格的延遲要求并且可以容忍陳舊或部分應(yīng)用的數(shù)據(jù)的操作非常有用。
寫事務(wù)總是從當(dāng)前讀取開始，以確定下一個(gè)可用的日志位置。提交操作將變化收集到一個(gè)日志條目中，給它分配一個(gè)比以前更高的時(shí)間戳，并使用?Paxos?將其附加到日志中。該協(xié)議使用樂觀并發(fā)：雖然多個(gè)寫入者可能試圖寫入同一日志位置，但只有一個(gè)人會(huì)贏得寫入權(quán)利。其余的將注意到勝利的寫，中止，并重試他們的操作。咨詢鎖定可用于減少爭用的影響。通過會(huì)話關(guān)聯(lián)性對(duì)特定前端服務(wù)器的寫入進(jìn)行批處理可以完全避免爭用。完整的事務(wù)生命周期如下：
(1) 讀取：獲取上次提交事務(wù)的時(shí)間戳和日志位置。
(2) 應(yīng)用程序邏輯：從?Bigtable 中讀取，并將寫入內(nèi)容收集到日志條目中。
(3) 提交：使用?Paxos?來實(shí)現(xiàn)將該條目附加到日志的一致性。
(4) 應(yīng)用：將突變寫入?Bigtable 中的實(shí)體和索引。
(5) 清理：刪除不再需要的數(shù)據(jù)。
寫操作可以在提交后的任何時(shí)間點(diǎn)返回到客戶端，盡管它會(huì)盡最大努力等待最近的復(fù)制副本應(yīng)用。
?
3.3.1?隊(duì)列
隊(duì)列提供實(shí)體組之間的事務(wù)消息傳遞。它們可用于跨組操作、將多個(gè)更新批量處理到單個(gè)事務(wù)或延遲工作。實(shí)體組上的事務(wù)除了更新其實(shí)體外，還可以原子地發(fā)送或接收多個(gè)消息。每條消息有一個(gè)發(fā)送和接收實(shí)體組；如果它們不同，則交付是異步的（見圖2）。
隊(duì)列提供了一種執(zhí)行影響許多實(shí)體組的操作的方法。例如，考慮一個(gè)日歷應(yīng)用程序，其中每個(gè)日歷都有一個(gè)不同的實(shí)體組，我們希望向一組日歷發(fā)送邀請(qǐng)。單個(gè)事務(wù)可以自動(dòng)向許多不同的日歷發(fā)送邀請(qǐng)隊(duì)列消息。每個(gè)接收消息的日歷將在其自己的事務(wù)中處理邀請(qǐng)，該事務(wù)更新被邀請(qǐng)者的狀態(tài)并刪除消息。
在功能齊全的關(guān)系數(shù)據(jù)庫管理系統(tǒng)中，消息隊(duì)列有著悠久的歷史。我們的支持以其規(guī)模而聞名：聲明一個(gè)隊(duì)列會(huì)自動(dòng)在每個(gè)實(shí)體組上創(chuàng)建一個(gè)收件箱，給我們提供數(shù)百萬個(gè)端點(diǎn)。
?
3.3.2?兩階段提交
Megastore 支持跨實(shí)體組的原子更新的兩階段提交。由于這些事務(wù)具有高得多的延遲并增加了爭用的風(fēng)險(xiǎn)，我們通常不鼓勵(lì)應(yīng)用程序使用該特性來支持隊(duì)列。然而，它們?cè)诤喕瘧?yīng)用程序代碼以實(shí)現(xiàn)唯一的二級(jí)密鑰實(shí)施方面很有用。
?
?
3.4?其他功能
我們已經(jīng)與?Bigtable?的全文索引建立了緊密的集成，其中更新和搜索參與?Megastore 的事務(wù)和多版本并發(fā)。在?Megastore 模式中聲明的全文索引可以索引表的文本或其他應(yīng)用程序生成的屬性。
同步復(fù)制足以抵御最常見的損壞和事故，但在程序員或操作員出錯(cuò)的情況下，備份可能是無價(jià)的。Megastore 的集成備份系統(tǒng)支持事務(wù)日志的定期完整快照和增量備份。恢復(fù)過程可以將實(shí)體組的狀態(tài)恢復(fù)到任意時(shí)間點(diǎn)，也可以省略選定的日志條目（在意外刪除之后）。備份系統(tǒng)符合已刪除數(shù)據(jù)過期的規(guī)則和常識(shí)原則。
應(yīng)用程序可以選擇加密靜態(tài)數(shù)據(jù)，包括事務(wù)日志。加密對(duì)每個(gè)實(shí)體組使用不同的密鑰。我們避免授予相同的操作員訪問加密密鑰和加密數(shù)據(jù)的權(quán)限。
?
?
4?復(fù)制
本節(jié)詳細(xì)介紹了我們的同步復(fù)制方案的核心：Paxos?的低延遲實(shí)現(xiàn)。我們討論運(yùn)營細(xì)節(jié)，并介紹我們生產(chǎn)服務(wù)的一些衡量標(biāo)準(zhǔn)。
?
4.1?概述
Megastore 的復(fù)制系統(tǒng)提供了存儲(chǔ)在其底層副本中的數(shù)據(jù)的單一且一致的視圖。讀取和寫入可以從任何副本啟動(dòng)，并且無論客戶端從哪個(gè)副本啟動(dòng)，ACID?語義都會(huì)得到保留。復(fù)制是通過將每個(gè)實(shí)體組的事務(wù)日志同步復(fù)制到復(fù)制副本的仲裁中來完成的。寫操作通常需要一輪數(shù)據(jù)中心間通信，正常情況下的讀操作在本地運(yùn)行。當(dāng)前讀取有以下保證：
(1) 讀取的總是最后確認(rèn)的寫入。
(2) 觀察到寫入后，所有將來的讀取都會(huì)觀察到該寫入。（在確認(rèn)之前，可能會(huì)觀察到寫入）
?
?
4.2?Paxos?簡介
Paxos?算法是一種在一組副本中就單個(gè)值達(dá)成共識(shí)的方法。它可以容忍延遲或重新排序的消息以及因停止而失敗的副本。大多數(shù)副本必須是活躍的和可達(dá)的，算法才能取得進(jìn)展，也就是說，它允許?2F + 1?副本最多有?F?個(gè)故障。一旦某個(gè)值被大多數(shù)人選中，以后所有讀取或?qū)懭朐撝档膰L試都會(huì)得到相同的結(jié)果。
單獨(dú)確定單個(gè)值的結(jié)果的能力對(duì)數(shù)據(jù)庫來說用處不大。數(shù)據(jù)庫通常使用?Paxos?來復(fù)制事務(wù)日志，其中?Paxos?的單獨(dú)實(shí)例用于日志中的每個(gè)位置。新值被寫入日志中最后選擇的位置之后的位置。
最初的?Paxos?算法不適用于高帶寬網(wǎng)絡(luò)鏈路，因?yàn)樗枰噍喭ㄐ拧?/strong>在達(dá)成一致之前，寫入至少需要兩次副本間往返：一輪準(zhǔn)備，保留后續(xù)一輪接受的權(quán)利。讀取至少需要一輪準(zhǔn)備，以確定最后選擇的值。建立在?Paxos?上的系統(tǒng)減少了使其成為實(shí)用算法所需的往返次數(shù)。我們將首先回顧基于主機(jī)的系統(tǒng)如何使用?Paxos，然后解釋我們?nèi)绾问?/span>?Paxos?高效。
?
?
4.3?基于?Master?的方法
為了最大限度地減少延遲，許多系統(tǒng)使用一個(gè)專用?master，所有讀取和寫入都指向該master。master?參與所有寫入，因此它的狀態(tài)始終是最新的。它可以在沒有任何網(wǎng)絡(luò)通信的情況下提供當(dāng)前一致狀態(tài)的讀數(shù)。通過在每次接受時(shí)進(jìn)行下一次寫操作的準(zhǔn)備，寫操作被簡化為一輪通信。主機(jī)可以一起批量寫入，以提高吞吐量。
對(duì)?master?的依賴限制了讀和寫的靈活性。事務(wù)處理必須在主副本附近完成，以避免順序讀取造成的延遲累積。任何潛在的主副本必須有足夠的資源用于系統(tǒng)的全部工作負(fù)載；從屬副本浪費(fèi)資源，直到他們成為?master。master?故障轉(zhuǎn)移可能需要復(fù)雜的狀態(tài)機(jī)，并且在服務(wù)恢復(fù)之前必須經(jīng)過一系列計(jì)時(shí)器。很難避免用戶可見的中斷。
?
?
4.4?Megastore 的方法
在本節(jié)中，我們將討論使?Paxos?對(duì)我們的系統(tǒng)實(shí)用的優(yōu)化和創(chuàng)新。
4.4.1?快速讀取
我們?cè)O(shè)置了一個(gè)早期要求，即當(dāng)前讀取通常應(yīng)該在沒有副本間?RPC?的任何副本上執(zhí)行。由于寫入通常在所有副本上都成功，因此允許在任何地方進(jìn)行本地讀取是現(xiàn)實(shí)的。這些本地讀取為我們提供了更好的利用率、所有區(qū)域的低延遲、細(xì)粒度的讀取故障轉(zhuǎn)移和更簡單的編程體驗(yàn)。
我們?cè)O(shè)計(jì)了一個(gè)名為協(xié)調(diào)器的服務(wù)，每個(gè)副本的數(shù)據(jù)中心都有服務(wù)器。協(xié)調(diào)服務(wù)器跟蹤一組實(shí)體組，其副本已觀察到該組實(shí)體組的所有?Paxos?寫入。對(duì)于該集中的實(shí)體組，副本具有足夠的狀態(tài)來服務(wù)本地讀取。保持協(xié)調(diào)器狀態(tài)是寫算法的責(zé)任。如果一個(gè)復(fù)制副本的?Bigtable 上的寫操作失敗，則在該復(fù)制副本的協(xié)調(diào)器收回該組的密鑰之前，不能將其視為已提交。由于協(xié)調(diào)器很簡單，他們比?Bigtable?更可靠、更快速地做出響應(yīng)。第?4.7?節(jié)描述了罕見故障情況或網(wǎng)絡(luò)分區(qū)的處理。
?
4.4.2?快速寫入
為了實(shí)現(xiàn)快速的單往返寫入，Megastore 采用了基于?master 的方法所使用的預(yù)準(zhǔn)備優(yōu)化。在基于?master 的系統(tǒng)中，每次成功寫入都包含一條隱含的準(zhǔn)備消息，授予主機(jī)為下一個(gè)日志位置發(fā)出接受消息的權(quán)利。如果寫入成功，準(zhǔn)備工作將得到執(zhí)行，下一次寫入將直接跳到接受階段。Megastore 不使用專門的?master，而是使用?leader。
我們?yōu)槊總€(gè)日志位置運(yùn)行一個(gè)獨(dú)立的?Paxos?算法實(shí)例。每個(gè)日志位置的前導(dǎo)是與前一個(gè)日志位置的一致的值一起選擇的一個(gè)可分辨的副本。leader 仲裁哪一個(gè)值可以使用?proposal number zero。第一個(gè)向?leader 提交值的寫者贏得了要求所有副本接受該值作為零號(hào)建議書的權(quán)利。所有其他寫者必須依靠兩階段?Paxos。
由于寫入者在將值提交給其他副本之前必須與?leader 溝通，因此我們將寫入者延遲降至最低。我們根據(jù)大多數(shù)應(yīng)用程序重復(fù)提交來自同一地區(qū)的寫操作的觀察，設(shè)計(jì)了選擇下一個(gè)寫操作負(fù)責(zé)人的策略。這就產(chǎn)生了一個(gè)簡單但有效的啟發(fā)式方法：使用最近的副本。
?
4.4.3?副本類型
到目前為止，所有副本都是完全副本，這意味著它們包含所有實(shí)體和索引數(shù)據(jù)，并且能夠服務(wù)于當(dāng)前讀取。我們也支持?witness?副本的概念。witness?在?Paxos?輪次中投票并存儲(chǔ)寫前日志，但不應(yīng)用日志，也不存儲(chǔ)實(shí)體數(shù)據(jù)或索引，因此存儲(chǔ)成本較低。它們實(shí)際上是平局決勝者，在沒有足夠的完整副本來形成法定人數(shù)時(shí)使用。因?yàn)樗鼈儧]有協(xié)調(diào)器，所以當(dāng)它們未能確認(rèn)寫入時(shí)，不會(huì)強(qiáng)制執(zhí)行額外的往返。
只讀副本（Read-only replicas）與?witness?副本相反：它們是非投票副本，包含數(shù)據(jù)的完整快照。對(duì)這些副本的讀取反映了最近某個(gè)時(shí)間點(diǎn)的一致的視圖。對(duì)于可以容忍這種過時(shí)的讀取，只讀副本有助于在廣泛的地理區(qū)域傳播數(shù)據(jù)，而不會(huì)影響寫入延遲。
?
?
4.5?架構(gòu)
圖?5?顯示了具有兩個(gè)完整副本和一個(gè)?witness?副本的實(shí)例的?Megastore 的關(guān)鍵組件。
Megastore 是通過客戶端庫和輔助服務(wù)器部署的。應(yīng)用程序鏈接到客戶端庫，該庫實(shí)現(xiàn)?Paxos?和其他算法：選擇一個(gè)副本進(jìn)行讀取，追趕一個(gè)落后的副本，等等。每個(gè)應(yīng)用服務(wù)器都有一個(gè)指定的本地副本。客戶端庫通過直接向本地?Bigtable?提交事務(wù)，使該副本上的?Paxos?操作持久。為了最小化廣域往返，庫將遠(yuǎn)程?Paxos?操作提交給與本地?Bigtable?通信的無狀態(tài)中間復(fù)制服務(wù)器。客戶端、網(wǎng)絡(luò)或?Bigtable?故障可能會(huì)導(dǎo)致寫操作以不確定的狀態(tài)被放棄。復(fù)制服務(wù)器定期掃描未完成的寫入，并通過?Paxos?建議無操作值以完成寫入。
?
?
4.6?數(shù)據(jù)結(jié)構(gòu)和算法
本節(jié)詳細(xì)介紹了從對(duì)單個(gè)值的共識(shí)到正常運(yùn)行的復(fù)制日志的飛躍所需的數(shù)據(jù)結(jié)構(gòu)和算法。
4.6.1?復(fù)制的日志
每個(gè)副本存儲(chǔ)組已知的日志條目的突變信息和元數(shù)據(jù)。為了確保復(fù)制副本即使在從以前的中斷中恢復(fù)時(shí)也能參與寫入仲裁，我們?cè)试S復(fù)制副本接受無序建議。我們將日志條目作為獨(dú)立的單元格存儲(chǔ)在?Bigtable?中。
當(dāng)日志副本包含不完整的日志前綴時(shí)，我們稱之為"漏洞"。圖?6?展示了這個(gè)場景，其中有一個(gè)?Megastore 實(shí)體組的一些代表性日志副本。日志位置?0-99?已被完全清除，位置?100?被部分清除，因?yàn)槊總€(gè)副本都被告知其他副本將永遠(yuǎn)不會(huì)請(qǐng)求拷貝。日志位置?101?被所有副本接受。日志位置?102?在?A?和?C?中發(fā)現(xiàn)了一個(gè)空的法定人數(shù)。位置?103?值得注意，因?yàn)樗呀?jīng)被?A?和?C?接受，給?B?留下了一個(gè)?103?的洞。副本?A?和副本?B?上的位置?104?發(fā)生了沖突的寫入嘗試，導(dǎo)致無法達(dá)成一致。
?
4.6.2 Reads
在為當(dāng)前讀取（以及寫入之前）做準(zhǔn)備時(shí)，必須至少更新一個(gè)副本：必須將之前提交給日志的所有變化復(fù)制到該副本并應(yīng)用到該副本。我們稱這個(gè)過程為追趕（較為重要的概念）。
省略了一些期限管理，當(dāng)前讀取的算法（如圖?7?所示）如下：
(1) 查詢本地：查詢本地副本的協(xié)調(diào)器，以確定實(shí)體組在本地是否是最新的。
(2) 查找位置：確定可能實(shí)現(xiàn)的最高日志位置，并選擇已通過該日志位置應(yīng)用的副本。
? ? ? ? (a)（本地讀取）如果步驟?1?表明本地副本是最新的，則從本地副本中讀取最高可接受的日志位置和時(shí)間戳。
? ? ? ? (b)（多數(shù)讀取）如果本地復(fù)制副本不是最新的（或者如果步驟?1?或步驟?2a?超時(shí)），從多數(shù)復(fù)制副本中讀取，以找到任何復(fù)制副本看到的最大日志位置，并選擇要讀取的復(fù)制副本。我們選擇響應(yīng)速度最快或最新的副本，而不總是本地副本。
(3) 捕捉：選擇復(fù)制副本后，立即將其捕捉到最大已知日志位置，如下所示：
? ? ? ? (a) 對(duì)于所選副本不知道一致的值的每個(gè)日志位置，從另一個(gè)副本讀取該值。對(duì)于任何沒有已知提交值的日志位置，調(diào)用?Paxos?來建議一個(gè)無操作寫入（no-op write）。Paxos?將驅(qū)動(dòng)大多數(shù)副本聚合到一個(gè)值上，要么是無操作，要么是以前建議的寫入。
? ? ? ? (b) 順序應(yīng)用所有未應(yīng)用日志位置相一致的值，以將副本的狀態(tài)提升到分布式一致性狀態(tài)。如果失敗，請(qǐng)?jiān)诹硪粋€(gè)副本上重試。
(4) 驗(yàn)證：如果選擇了本地復(fù)制副本，并且以前不是最新的，則向協(xié)調(diào)器發(fā)送驗(yàn)證消息，聲明（實(shí)體組、復(fù)制副本）對(duì)反映了所有提交的寫入。不要等待回復(fù)——如果請(qǐng)求失敗，下一次讀取將重試。
(5) 查詢數(shù)據(jù)：使用選定日志位置的時(shí)間戳讀取選定的副本。如果選定的復(fù)制副本不可用，請(qǐng)選擇一個(gè)備用復(fù)制副本，執(zhí)行捕獲，然后改為從中讀取。單個(gè)大型查詢的結(jié)果可以從多個(gè)副本透明地組裝。
注意，實(shí)際上?1?和?2a?是并行執(zhí)行的。
?
4.6.3 Writes
完成讀算法后，Megastore 觀察下一個(gè)未使用的日志位置、最后一次寫的時(shí)間戳和下一個(gè) leader?副本。在提交時(shí)，將對(duì)狀態(tài)的所有掛起的更改打包并提出，并使用時(shí)間戳和下一個(gè)?leader?指定，作為下一個(gè)日志位置的共識(shí)值。如果這個(gè)值贏得了分布式共識(shí)，它將應(yīng)用于所有完全副本的狀態(tài)；否則，整個(gè)事務(wù)將中止，必須從讀取階段開始重試。
如上所述，協(xié)調(diào)器跟蹤在其副本中最新的實(shí)體組。如果復(fù)制副本上的寫入不被接受，我們必須從該復(fù)制副本的協(xié)調(diào)器中刪除實(shí)體組的密鑰。這個(gè)過程叫做失效（invalidation，較為重要的概念）。在寫入被視為已提交并準(zhǔn)備好應(yīng)用之前，所有完整復(fù)制副本必須已接受該實(shí)體組，或者其協(xié)調(diào)器已失效。寫算法（如圖?8?所示）如下：
(1) Accept Leader：要求領(lǐng)導(dǎo)接受該值作為零號(hào)建議（proposal number zero）。如果成功，請(qǐng)?zhí)讲襟E 3。
(2) Prepare：在所有副本上運(yùn)行?Paxos?準(zhǔn)備階段，該副本的建議編號(hào)高于目前在此日志位置看到的任何副本。用發(fā)現(xiàn)的最高編號(hào)的建議（如果有）替換正在寫入的值。
(3) Accept：要求剩余的副本接受該值。如果大多數(shù)副本都失敗了，請(qǐng)?jiān)陔S機(jī)回退后返回步驟?2。
(4) Invalidate：使不接受該值的所有完整副本上的協(xié)調(diào)器無效。下面第?4.7?節(jié)描述了這一步驟的故障處理。
(5) Apply：在盡可能多的副本上應(yīng)用改變的值。如果選擇的值不同于最初建議的值，則返回沖突錯(cuò)誤。
步驟?1?實(shí)現(xiàn)了第?4.4.2?節(jié)中的"快速寫入"。寫者通過使用單階段 Paxos?在建議編號(hào)為零時(shí)發(fā)送接受命令來跳過準(zhǔn)備消息。在日志位置?n?選擇的下一個(gè)?leader?副本仲裁用于?n + 1?處的提議零的值。由于多個(gè)建議者可能提交建議編號(hào)為零的值，因此在此副本中進(jìn)行序列化可確保只有一個(gè)值與特定日志位置的建議編號(hào)相對(duì)應(yīng)。
在傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)中，提交點(diǎn)（更改是持久的）與可見點(diǎn)（visibility point）（讀取可以看到更改，寫入器可以收到成功通知）是相同的。在我們的寫算法中，當(dāng)寫程序贏得?Paxos?回合時(shí)，提交點(diǎn)是在步驟?3?之后，但可見性點(diǎn)是在步驟?4?之后。只有在所有完整副本已經(jīng)接受或其協(xié)調(diào)器失效后，寫入才能被確認(rèn)并應(yīng)用更改。在步驟?4?之前的確認(rèn)可能會(huì)違反我們的一致性保證：在副本上的當(dāng)前讀取，如果無效被跳過，則可能無法觀察到已確認(rèn)的寫入。
?
?
4.7 Coordinator Availability
協(xié)調(diào)器進(jìn)程在每個(gè)數(shù)據(jù)中心運(yùn)行，并且只保持關(guān)于其本地副本的狀態(tài)。在上面的寫算法中，每個(gè)完整副本必須接受或使其協(xié)調(diào)器無效，因此任何單個(gè)副本故障（Bigtable 和協(xié)調(diào)器）都可能導(dǎo)致不可用。實(shí)際上，這不是一個(gè)常見的問題。協(xié)調(diào)器是一個(gè)簡單的過程，沒有外部依賴性，也沒有持久存儲(chǔ)，因此它往往比?Bigtable?服務(wù)器穩(wěn)定得多。然而，網(wǎng)絡(luò)和主機(jī)故障仍然會(huì)使協(xié)調(diào)器不可用。
4.7.1?故障檢測
為了解決網(wǎng)絡(luò)分區(qū)問題，協(xié)調(diào)器使用帶外協(xié)議來識(shí)別其他協(xié)調(diào)器何時(shí)啟動(dòng)、運(yùn)行正常并且通常可以訪問。我們使用谷歌的?Chubby?鎖服務(wù)：協(xié)調(diào)器在啟動(dòng)時(shí)在遠(yuǎn)程數(shù)據(jù)中心獲得特定的?Chubby ?鎖。為了處理請(qǐng)求，協(xié)調(diào)器必須持有其大部分鎖。如果它在崩潰或網(wǎng)絡(luò)分區(qū)中丟失了大部分鎖，它會(huì)將其狀態(tài)恢復(fù)為保守的默認(rèn)狀態(tài)，認(rèn)為其權(quán)限內(nèi)的所有實(shí)體組都已過時(shí)。復(fù)制副本上的后續(xù)讀取必須從大多數(shù)復(fù)制副本中查詢?nèi)罩疚恢?#xff0c;直到鎖被重新獲得并且其協(xié)調(diào)器條目被重新驗(yàn)證。
通過測試協(xié)調(diào)器是否丟失了鎖，寫入器與協(xié)調(diào)器故障隔離開來：在這種情況下，寫入器知道協(xié)調(diào)器在重新獲得鎖時(shí)會(huì)認(rèn)為自己無效。當(dāng)包含實(shí)時(shí)協(xié)調(diào)器的數(shù)據(jù)中心突然變得不可用時(shí)，此算法可能會(huì)導(dǎo)致短暫（幾十秒）的寫入中斷——所有寫入者都必須等待協(xié)調(diào)器的?Chubby?鎖到期，然后才能完成寫入（很像等待主故障切換觸發(fā)）。與主節(jié)點(diǎn)故障轉(zhuǎn)移后不同，當(dāng)協(xié)調(diào)器的狀態(tài)被重建時(shí)，讀取和寫入可以順利進(jìn)行。這種短暫而罕見的停機(jī)風(fēng)險(xiǎn)是由它所允許的快速本地讀取的穩(wěn)定狀態(tài)所證明的。
協(xié)調(diào)器活性協(xié)議易受不對(duì)稱網(wǎng)絡(luò)分區(qū)的影響。如果協(xié)調(diào)器可以維護(hù)其?Chubby?鎖的租約，但是已經(jīng)與提議者失去聯(lián)系，那么受影響的實(shí)體組將經(jīng)歷寫中斷。在這種情況下，操作員執(zhí)行手動(dòng)步驟來禁用部分隔離的協(xié)調(diào)器。我們只遇到過幾次這種情況。
?
4.7.2 Validation Races
除了可用性問題，讀寫協(xié)調(diào)器的協(xié)議必須應(yīng)對(duì)各種競爭條件。無效消息總是安全的，但是驗(yàn)證消息必須小心處理。協(xié)調(diào)器通過始終發(fā)送與操作相關(guān)聯(lián)的日志位置來保護(hù)早期寫入的驗(yàn)證和后期寫入的無效之間的競爭。編號(hào)較高的無效總是勝過編號(hào)較低的有效。（Races between validates for earlier writes and invalidates for later writes?are protected in the coordinator by?always sending the log?position associated with the action. Higher numbered invalidates always trump lower numbered validates）還存在與寫入器在位置?n?的無效和在位置?m < n?的驗(yàn)證之間的崩潰相關(guān)聯(lián)的競爭。我們使用協(xié)調(diào)器的每個(gè)化身的唯一時(shí)期號(hào)來檢測崩潰：只有在最近讀取協(xié)調(diào)器的?epoch?保持不變時(shí)，validates?才允許修改協(xié)調(diào)器狀態(tài)。總之，就對(duì)可用性的影響而言，使用協(xié)調(diào)器允許從任何數(shù)據(jù)中心進(jìn)行快速本地讀取并不是免費(fèi)的。但實(shí)際上，運(yùn)行協(xié)調(diào)器的大多數(shù)問題都可以通過以下因素得到緩解：
(1) 協(xié)調(diào)器是比大型服務(wù)器簡單得多的過程，具有更少的依賴性，因此自然更加可用。
(2) 協(xié)調(diào)器簡單、同質(zhì)的工作負(fù)載使其成本低廉且可預(yù)測。
(3) 協(xié)調(diào)器的輕網(wǎng)絡(luò)流量允許使用具有可靠連接的高網(wǎng)絡(luò)服務(wù)質(zhì)量。
(4) 操作員可以集中禁用維護(hù)或不健康期間的協(xié)調(diào)器。對(duì)于某些監(jiān)控信號(hào)，這是自動(dòng)的。
(5) Chubby?鎖的法定數(shù)量檢測到大多數(shù)網(wǎng)絡(luò)分區(qū)和節(jié)點(diǎn)不可用。
?
?
4.8?寫吞吐量
我們的?Paxos?實(shí)現(xiàn)在系統(tǒng)行為上有著有趣的權(quán)衡。多個(gè)數(shù)據(jù)中心中的應(yīng)用服務(wù)器可以同時(shí)啟動(dòng)對(duì)同一實(shí)體組和日志位置的寫入。除了一個(gè)之外，所有的都將失敗，需要重試它們的事務(wù)。對(duì)于給定的每個(gè)實(shí)體組提交速率，同步復(fù)制數(shù)量的增加提升了延遲增加的沖突的可能性。
將該速率限制為每個(gè)實(shí)體組每秒幾個(gè)寫入，會(huì)產(chǎn)生微不足道的沖突率。對(duì)于實(shí)體一次被少數(shù)用戶操縱的應(yīng)用程序，這種限制通常不是問題。我們的大多數(shù)目標(biāo)客戶通過更精細(xì)地分割實(shí)體組或確保將副本放在同一區(qū)域來擴(kuò)展寫吞吐量，從而降低延遲和沖突率。
具有一些服務(wù)器"粘性"的應(yīng)用程序能夠很好地將用戶操作批處理到更少的?Megastore 事務(wù)中。大容量存儲(chǔ)隊(duì)列消息的批量處理是一種常見的批處理技術(shù)，可以降低沖突率并提高聚合吞吐量。對(duì)于必須經(jīng)常超過每秒幾次寫入的組，應(yīng)用程序可以使用協(xié)調(diào)服務(wù)器分配的細(xì)粒度咨詢鎖。對(duì)事務(wù)進(jìn)行背靠背序列化可以避免與重試相關(guān)的延遲，并在檢測到?jīng)_突時(shí)恢復(fù)到兩階段?Paxos。
?
?
4.9 Operational Issues
當(dāng)一個(gè)特定的完整副本變得不可靠或失去連接時(shí)，Megastore 的性能可能會(huì)下降。我們有許多方法來應(yīng)對(duì)這些失敗，包括：路由用戶遠(yuǎn)離有問題的副本、禁用其協(xié)調(diào)器，或完全禁用它。在實(shí)踐中，我們依賴于技術(shù)的組合，每一種技術(shù)都有自己的權(quán)衡。
對(duì)中斷的第一個(gè)也是最重要的響應(yīng)是通過將流量重新路由到其他副本附近的應(yīng)用服務(wù)器來禁用受影響副本上的?Megastore 客戶端。這些客戶端通常會(huì)經(jīng)歷相同的中斷，影響其下方的存儲(chǔ)堆棧，并且可能無法從外部世界訪問。
如果不健康的協(xié)調(diào)服務(wù)器可能繼續(xù)持有它們的?Chubby?鎖，僅僅重新路由流量是不夠的。下一個(gè)響應(yīng)是禁用復(fù)制副本的協(xié)調(diào)器，確保問題對(duì)寫入延遲的影響最小。（第?4.7?節(jié)更詳細(xì)地描述了這個(gè)過程。）一旦免除了寫入者使復(fù)制副本的協(xié)調(diào)器無效的責(zé)任，不健康的復(fù)制副本對(duì)寫入延遲的影響就會(huì)受到限制。只有寫入算法中最初的"accept leader"步驟依賴于副本，我們?cè)诨氐絻呻A段?Paxos?并為下一次寫入指定更健康的?leader?之前保持一個(gè)嚴(yán)格的截止日期。
一個(gè)更嚴(yán)厲且很少使用的操作是完全禁用副本：無論是客戶端還是復(fù)制服務(wù)器都不會(huì)嘗試與其通信。雖然隔離副本看起來很有吸引力，但主要影響是可用性：少一個(gè)副本就有資格幫助寫入者形成法定人數(shù)。有效的用例是當(dāng)嘗試的操作可能造成傷害時(shí)——例如，當(dāng)?shù)讓拥?/span>?Bigtable 嚴(yán)重過載時(shí)。
?
?
4.10 生產(chǎn)指標(biāo)
Megastore 已經(jīng)在?Google?內(nèi)部部署了好幾年；超過?100?個(gè)生產(chǎn)應(yīng)用程序?qū)⑺米鞔鎯?chǔ)服務(wù)。在本節(jié)中，我們將報(bào)告對(duì)其規(guī)模、可用性和性能的一些衡量。
圖?9?顯示了可用性的分布，以每個(gè)應(yīng)用程序、每個(gè)操作為基礎(chǔ)進(jìn)行衡量。盡管機(jī)器故障、網(wǎng)絡(luò)故障、數(shù)據(jù)中心中斷和其他故障源源不斷，但我們的大多數(shù)客戶都看到了極高的可用性（至少五個(gè)?9）。我們樣本的底端包括一些仍在測試的生產(chǎn)前應(yīng)用和具有較高故障容限的批處理應(yīng)用。
根據(jù)數(shù)據(jù)量，平均讀取延遲為幾十毫秒，表明大多數(shù)讀取是本地的。根據(jù)數(shù)據(jù)中心之間的距離、寫入數(shù)據(jù)的大小和完整副本的數(shù)量，大多數(shù)用戶的平均寫入延遲為?100-400?毫秒。圖?10?顯示了讀取和提交操作的平均延遲分布。
?
?
5?經(jīng)驗(yàn)
對(duì)可測試性的強(qiáng)調(diào)有助于系統(tǒng)的開發(fā)。代碼被大量（但廉價(jià)）的斷言和日志記錄所裝備，并且具有徹底的單元測試覆蓋。但是最有效的?Bug?發(fā)現(xiàn)工具是我們的網(wǎng)絡(luò)模擬器：偽隨機(jī)測試框架。它能夠探索模擬節(jié)點(diǎn)或線程之間通信的所有可能順序和延遲的空間，并在給定相同種子的情況下確定性地再現(xiàn)相同行為。Bug?是通過發(fā)現(xiàn)觸發(fā)斷言失敗（或不正確結(jié)果）的有問題的事件序列而暴露出來的，通常有足夠的日志和跟蹤信息來診斷問題，然后將其添加到單元測試套件中。雖然不可能對(duì)調(diào)度狀態(tài)空間進(jìn)行窮舉搜索，但偽隨機(jī)模擬探索的內(nèi)容比通過其他方式實(shí)際探索的內(nèi)容要多。通過每晚運(yùn)行數(shù)千小時(shí)的模擬操作，測試發(fā)現(xiàn)了許多令人驚訝的問題。
在實(shí)際部署中，我們觀察到了預(yù)期的性能：我們的復(fù)制協(xié)議優(yōu)化確實(shí)在大多數(shù)情況下提供了本地讀取，而寫入的開銷只有一次廣域網(wǎng)往返的開銷。大多數(shù)應(yīng)用發(fā)現(xiàn)延遲是可以容忍的。有些應(yīng)用程序旨在對(duì)用戶隱藏寫入延遲，有些應(yīng)用程序必須謹(jǐn)慎選擇實(shí)體組邊界，以最大化其寫入吞吐量。這種努力產(chǎn)生了主要的操作優(yōu)勢：Megastore 的延遲尾部比底層的延遲尾部短得多，大多數(shù)應(yīng)用程序可以承受計(jì)劃內(nèi)和計(jì)劃外停機(jī)，幾乎沒有或根本沒有手動(dòng)干預(yù)。
大多數(shù)應(yīng)用程序使用?Megastore 模式語言來建模它們的數(shù)據(jù)。一些應(yīng)用程序在?Megastore 模式語言中實(shí)現(xiàn)了它們自己的實(shí)體屬性值模型，然后使用它們自己的應(yīng)用程序邏輯建模它們的數(shù)據(jù)（最顯著的是，谷歌應(yīng)用引擎）。一些人混合使用兩種方法。在靜態(tài)模式之上構(gòu)建動(dòng)態(tài)模式，而不是相反，允許大多數(shù)應(yīng)用程序享受靜態(tài)模式的性能、可用性和完整性好處，同時(shí)仍然為那些需要它的人提供動(dòng)態(tài)模式的選項(xiàng)。
術(shù)語"高可用性"通常表示屏蔽故障的能力，使系統(tǒng)集合比單個(gè)系統(tǒng)更可靠。雖然容錯(cuò)是一個(gè)非常理想的目標(biāo)，但它也有自己的陷阱：它經(jīng)常隱藏持久的潛在問題。我們組里有句話："容錯(cuò)就是故障屏蔽"。我們系統(tǒng)的彈性加上對(duì)跟蹤潛在故障的警惕性不足，往往會(huì)導(dǎo)致意想不到的問題：持續(xù)未糾正問題之上的微小瞬時(shí)錯(cuò)誤會(huì)導(dǎo)致更大的問題。
另一個(gè)問題是流量控制。一個(gè)容忍有缺陷的參與者的算法可能會(huì)忽視慢參與者。理想情況下，一個(gè)由不同機(jī)器組成的集合只能和能力最差的成員一樣快地取得進(jìn)展。如果慢被解釋為一種錯(cuò)誤，并被容忍，大多數(shù)最快的機(jī)器將按照自己的速度處理請(qǐng)求，只有當(dāng)被努力追趕的落后者的負(fù)載拖慢時(shí)，才會(huì)達(dá)到平衡。我們稱這種異常現(xiàn)象為鏈狀團(tuán)伙扼制，喚起了一群逃跑的罪犯的形象，他們只能盡可能快地拖住掉隊(duì)者。
Megastore 的預(yù)寫日志的一個(gè)好處是易于集成外部系統(tǒng)。任何冪等運(yùn)算都可以成為應(yīng)用日志條目的一個(gè)步驟。
要為更復(fù)雜的查詢獲得良好的性能，需要注意?Bigtable?中的物理數(shù)據(jù)布局。當(dāng)查詢速度較慢時(shí)，開發(fā)人員需要檢查?Bigtable?跟蹤，以了解為什么他們的查詢執(zhí)行速度低于預(yù)期。?Megastore 不強(qiáng)制實(shí)施關(guān)于塊大小、壓縮、表拆分、位置組的特定策略，也不強(qiáng)制實(shí)施?Bigtable?提供的其他調(diào)優(yōu)控制。相反，我們公開這些控件，為應(yīng)用程序開發(fā)人員提供優(yōu)化性能的能力（和負(fù)擔(dān)）。
?
?
6?相關(guān)工作
最近，人們對(duì)?NoSQL?數(shù)據(jù)存儲(chǔ)系統(tǒng)越來越感興趣，以滿足大型網(wǎng)絡(luò)應(yīng)用的需求。代表作品包括?Bigtable，Cassandra，雅虎?PNUTS。在這些系統(tǒng)中，可伸縮性是通過犧牲傳統(tǒng)關(guān)系數(shù)據(jù)庫管理系統(tǒng)的一個(gè)或多個(gè)屬性來實(shí)現(xiàn)的，例如事務(wù)、模式支持、查詢能力。這些系統(tǒng)通常將事務(wù)的范圍縮小到單個(gè)鍵訪問的粒度，因此給構(gòu)建應(yīng)用程序設(shè)置了一個(gè)很大的障礙。有些系統(tǒng)將事務(wù)的范圍擴(kuò)展到單個(gè)表中的多行，例如?Amazon SimpleDB?使用域的概念作為事務(wù)單元。然而，這種努力仍然有限，因?yàn)?/span>事務(wù)不能跨越表格或任意縮放。此外，目前大多數(shù)可擴(kuò)展的數(shù)據(jù)存儲(chǔ)系統(tǒng)缺乏關(guān)系數(shù)據(jù)庫管理系統(tǒng)的豐富數(shù)據(jù)模型，這增加了開發(fā)人員的負(fù)擔(dān)。結(jié)合了數(shù)據(jù)庫和可擴(kuò)展數(shù)據(jù)存儲(chǔ)的優(yōu)點(diǎn)，?Megastore 在一個(gè)實(shí)體組中提供了事務(wù)性?ACID?保證，并提供了一個(gè)靈活的數(shù)據(jù)模型，具有用戶定義的模式、數(shù)據(jù)庫樣式和全文索引以及隊(duì)列。
跨地理分布的數(shù)據(jù)中心的數(shù)據(jù)復(fù)制是提高最新存儲(chǔ)系統(tǒng)可用性的不可或缺的手段。大多數(shù)流行的數(shù)據(jù)存儲(chǔ)系統(tǒng)使用具有較弱一致性模型的異步復(fù)制方案。例如，Cassandra、HbPase、CouchDB?和?Dynamo?使用最終一致性模型，PNUTS?使用"時(shí)間線"一致性。相比之下，同步復(fù)制保證了廣域網(wǎng)上強(qiáng)大的事務(wù)語義，并提高了當(dāng)前讀取的性能。
傳統(tǒng)關(guān)系數(shù)據(jù)庫管理系統(tǒng)的同步復(fù)制帶來了性能挑戰(zhàn)，并且難以擴(kuò)展。一些建議的變通辦法允許通過異步復(fù)制實(shí)現(xiàn)強(qiáng)一致性。一種方法是在復(fù)制更新效果之前完成更新，將同步延遲傳遞給需要讀取更新狀態(tài)的事務(wù)。另一種方法是將寫操作路由到單個(gè)主機(jī)，同時(shí)在一組副本之間分配只讀事務(wù)。更新被異步傳播到剩余的副本，讀取或者被延遲，或者被發(fā)送到已經(jīng)同步的副本。最近一個(gè)關(guān)于高效同步復(fù)制的提議引入了一個(gè)排序預(yù)處理器，它可以確定性地調(diào)度傳入的事務(wù)，這樣它們就可以獨(dú)立地應(yīng)用于多個(gè)副本，并得到相同的結(jié)果。同步負(fù)擔(dān)被轉(zhuǎn)移到預(yù)處理器上，預(yù)處理器本身必須是可伸縮的。
直到最近，很少有人使用?Paxos?來實(shí)現(xiàn)同步復(fù)制。SCALARIS?是一個(gè)使用?Paxos?提交協(xié)議來實(shí)現(xiàn)分布式哈希表復(fù)制的例子。Keyspace?還使用?Paxos?在通用鍵值存儲(chǔ)上實(shí)現(xiàn)復(fù)制。然而，這些系統(tǒng)的可擴(kuò)展性和性能并不為人所知。Megastore 可能是第一個(gè)跨數(shù)據(jù)中心實(shí)施基于?Paxos?的復(fù)制，同時(shí)滿足云中可擴(kuò)展網(wǎng)絡(luò)應(yīng)用程序的可擴(kuò)展性和性能要求的大型存儲(chǔ)系統(tǒng)。
傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)提供了成熟和復(fù)雜的數(shù)據(jù)管理功能，但在為本文所針對(duì)的大規(guī)模交互式服務(wù)提供服務(wù)方面存在困難。MySQL?等開源數(shù)據(jù)庫系統(tǒng)無法擴(kuò)展到我們要求的水平，而?Oracle ?等昂貴的商業(yè)數(shù)據(jù)庫系統(tǒng)會(huì)顯著增加云中大型部署的總擁有成本。此外，它們都沒有提供容錯(cuò)同步復(fù)制機(jī)制，這是在云中構(gòu)建交互式服務(wù)的關(guān)鍵部分。
?
?
7?結(jié)論
在本文中，我們介紹了?Megastore，這是一個(gè)可擴(kuò)展、高可用性的數(shù)據(jù)存儲(chǔ)，旨在滿足交互式互聯(lián)網(wǎng)服務(wù)的存儲(chǔ)要求。我們使用?Paxos?進(jìn)行同步廣域復(fù)制，為單個(gè)操作提供輕量級(jí)和快速的故障轉(zhuǎn)移。單個(gè)系統(tǒng)映像的便利性和運(yùn)營商級(jí)可用性的操作優(yōu)勢抵消了跨廣泛分布的副本進(jìn)行同步復(fù)制的延遲損失。我們使用?Bigtable?作為我們的可擴(kuò)展數(shù)據(jù)存儲(chǔ)，同時(shí)添加更豐富的原語，如?ACID?事務(wù)、索引和隊(duì)列。將數(shù)據(jù)庫劃分為實(shí)體組子數(shù)據(jù)庫為大多數(shù)操作提供了熟悉的事務(wù)特性，同時(shí)允許存儲(chǔ)和吞吐量的可伸縮性。
Megastore 生產(chǎn)中有?100?多個(gè)應(yīng)用程序，面向內(nèi)部和外部用戶，并提供更高級(jí)別的基礎(chǔ)架構(gòu)。這些應(yīng)用程序的數(shù)量和多樣性證明了兆存的易用性、通用性和強(qiáng)大。我們希望?Megastore 能夠展示當(dāng)今可擴(kuò)展存儲(chǔ)系統(tǒng)在功能集和復(fù)制一致性方面的中間立場的可行性。
總結(jié)
以上是生活随笔為你收集整理的Megastore：为交互式服务提供可扩展的高可用性存储的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Go 语言学习笔记(三)：类型系统
- 下一篇： Dynamo：亚马逊的高可用键值存储