文章系列

1. 為什么要關(guān)心一致性？
2. 可能出現(xiàn)哪些問(wèn)題？
3. 采用一致性數(shù)據(jù)庫(kù)的障礙是什么？
4. 新算法如何提供幫助？

如今，越來(lái)越多的新產(chǎn)品旨在對(duì)全球市場(chǎng)產(chǎn)生影響，而用戶(hù)體驗(yàn)正迅速成為決定其成敗的關(guān)鍵因素。以下幾個(gè)方面會(huì)顯著影響應(yīng)用程序的用戶(hù)體驗(yàn)：

1. 性能和低延遲
2. 應(yīng)用程序按預(yù)期運(yùn)行
3. 安全性
4. 功能和UI

讓我們開(kāi)始追求完美的用戶(hù)體驗(yàn)之旅吧！

1) 性能與低延遲

正如其他人之前所說(shuō)：性能即用戶(hù)體驗(yàn)(1, 2)。當(dāng)您吸引到潛在訪客的注意后，即使是輕微的延遲增加也可能再次使您失去他們的關(guān)注。

2) 應(yīng)用程序按預(yù)期運(yùn)行

“按預(yù)期運(yùn)行”究竟是什么意思？這意味著，如果我在應(yīng)用程序中將我的名字更改為“Robert”，然后重新加載應(yīng)用程序，我的名字將是Robert而不是Brecht。應(yīng)用程序提供這些保證似乎很重要，對(duì)吧？

應(yīng)用程序能否兌現(xiàn)這些保證取決于數(shù)據(jù)庫(kù)。在追求低延遲和高性能時(shí)，我們最終會(huì)進(jìn)入分布式數(shù)據(jù)庫(kù)領(lǐng)域，其中只有少數(shù)較新的數(shù)據(jù)庫(kù)能夠提供這些保證。在分布式數(shù)據(jù)庫(kù)領(lǐng)域，除非我們選擇強(qiáng)一致性（與最終一致性相對(duì)）數(shù)據(jù)庫(kù)，否則可能潛伏著各種問(wèn)題。在本系列文章中，我們將詳細(xì)介紹這意味著什么，哪些數(shù)據(jù)庫(kù)提供這種稱(chēng)為強(qiáng)一致性的功能，以及它如何幫助您輕松構(gòu)建超快速的應(yīng)用程序。

3) 安全性

安全性起初似乎并不總是會(huì)影響用戶(hù)體驗(yàn)。但是，一旦用戶(hù)注意到安全漏洞，關(guān)系可能會(huì)受到無(wú)法彌補(bǔ)的損害。

4) 功能和UI

令人印象深刻的功能和出色的UI會(huì)對(duì)用戶(hù)的意識(shí)和潛意識(shí)產(chǎn)生重大影響。通常，人們只有在體驗(yàn)到產(chǎn)品的外觀和感覺(jué)后才會(huì)想要某個(gè)特定產(chǎn)品。

如果數(shù)據(jù)庫(kù)可以節(jié)省設(shè)置和配置時(shí)間，那么我們的其他工作就可以集中在提供令人印象深刻的功能和出色的UI上。好消息是：如今，有一些數(shù)據(jù)庫(kù)可以滿(mǎn)足上述所有要求，無(wú)需配置或服務(wù)器配置，并提供易于使用的API，例如開(kāi)箱即用的GraphQL。

這種新型數(shù)據(jù)庫(kù)有什么不同之處？讓我們退一步，看看對(duì)更低延遲和更好用戶(hù)體驗(yàn)的持續(xù)追求，以及數(shù)據(jù)庫(kù)研究的進(jìn)步，最終如何導(dǎo)致了一種新型數(shù)據(jù)庫(kù)的出現(xiàn)，它們是現(xiàn)代應(yīng)用程序的理想構(gòu)建塊。

對(duì)分布式的追求

I. 內(nèi)容分發(fā)網(wǎng)絡(luò)

如前所述，性能對(duì)用戶(hù)體驗(yàn)有重大影響。有幾種方法可以改善延遲，最明顯的方法是優(yōu)化應(yīng)用程序代碼。一旦您的應(yīng)用程序代碼得到充分優(yōu)化，網(wǎng)絡(luò)延遲和數(shù)據(jù)庫(kù)的讀寫(xiě)性能通常仍然是瓶頸。為了滿(mǎn)足我們的低延遲要求，我們需要確保我們的數(shù)據(jù)盡可能靠近客戶(hù)端，方法是將數(shù)據(jù)全局分發(fā)。我們可以通過(guò)讓多臺(tái)機(jī)器一起工作來(lái)實(shí)現(xiàn)第二個(gè)要求（讀寫(xiě)性能），或者換句話說(shuō)，復(fù)制數(shù)據(jù)。

分布式帶來(lái)更好的性能，從而帶來(lái)良好的用戶(hù)體驗(yàn)。我們已經(jīng)看到了廣泛使用的分布式解決方案，它可以加快靜態(tài)數(shù)據(jù)的交付速度；它被稱(chēng)為內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN)。 Jamstack 社區(qū)高度重視CDN，以減少其應(yīng)用程序的延遲。他們通常使用Next.js/Now、Gatsby 和Netlify 等框架和工具將前端React/Angular/Vue 代碼預(yù)組裝成靜態(tài)網(wǎng)站，以便他們可以從CDN 提供這些網(wǎng)站。

不幸的是，CDN 并非適用于所有用例，因?yàn)槲覀儾荒芤蕾?lài)靜態(tài)生成的HTML 頁(yè)面來(lái)處理所有應(yīng)用程序。有許多類(lèi)型的動(dòng)態(tài)應(yīng)用程序，您無(wú)法預(yù)先靜態(tài)生成所有內(nèi)容。例如：

1. 需要實(shí)時(shí)更新才能在用戶(hù)之間進(jìn)行即時(shí)通信的應(yīng)用程序（例如，聊天應(yīng)用程序、協(xié)作繪圖或?qū)懽?、游戲）?/li>
2. 通過(guò)過(guò)濾、聚合、排序以及以多種方式操作數(shù)據(jù)來(lái)呈現(xiàn)數(shù)據(jù)的應(yīng)用程序，以至于您無(wú)法預(yù)先生成所有內(nèi)容。

II. 分布式數(shù)據(jù)庫(kù)

通常，高度動(dòng)態(tài)的應(yīng)用程序需要分布式數(shù)據(jù)庫(kù)來(lái)提高性能。與CDN 一樣，分布式數(shù)據(jù)庫(kù)也旨在成為全球網(wǎng)絡(luò)而不是單個(gè)節(jié)點(diǎn)。從本質(zhì)上講，我們希望從具有單個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)的場(chǎng)景……

……轉(zhuǎn)變?yōu)閿?shù)據(jù)庫(kù)成為網(wǎng)絡(luò)的場(chǎng)景。當(dāng)用戶(hù)從特定大陸連接時(shí)，他將自動(dòng)被重定向到最近的數(shù)據(jù)庫(kù)。這將導(dǎo)致更低的延遲和更快樂(lè)的最終用戶(hù)。

如果數(shù)據(jù)庫(kù)是等待電話的員工，數(shù)據(jù)庫(kù)員工會(huì)告訴您附近有更近的員工，然后轉(zhuǎn)發(fā)電話。幸運(yùn)的是，分布式數(shù)據(jù)庫(kù)會(huì)自動(dòng)將我們引導(dǎo)到最近的數(shù)據(jù)庫(kù)員工，因此我們不必再麻煩其他大陸的數(shù)據(jù)庫(kù)員工。

分布式數(shù)據(jù)庫(kù)是多區(qū)域的，您總是會(huì)被重定向到最近的節(jié)點(diǎn)。

除了延遲之外，分布式數(shù)據(jù)庫(kù)還提供了第二個(gè)和第三個(gè)優(yōu)勢(shì)。第二個(gè)是冗余，這意味著如果網(wǎng)絡(luò)中的一個(gè)數(shù)據(jù)庫(kù)位置被哥斯拉襲擊完全摧毀，您的數(shù)據(jù)不會(huì)丟失，因?yàn)槠渌?jié)點(diǎn)仍然擁有您的數(shù)據(jù)的副本。

最后但并非最不重要的一點(diǎn)是，使用分布式數(shù)據(jù)庫(kù)的第三個(gè)優(yōu)勢(shì)是可擴(kuò)展性。在一個(gè)服務(wù)器上運(yùn)行的數(shù)據(jù)庫(kù)很快就會(huì)成為應(yīng)用程序的瓶頸。相反，分布式數(shù)據(jù)庫(kù)在多臺(tái)服務(wù)器上復(fù)制數(shù)據(jù)，并且可以根據(jù)應(yīng)用程序的需求自動(dòng)擴(kuò)展和縮減。在一些高級(jí)分布式數(shù)據(jù)庫(kù)中，這方面完全由您負(fù)責(zé)。這些數(shù)據(jù)庫(kù)被稱(chēng)為“無(wú)服務(wù)器”，這意味著您甚至不必配置數(shù)據(jù)庫(kù)何時(shí)應(yīng)該擴(kuò)展和縮減，您只需為應(yīng)用程序的使用付費(fèi)，僅此而已。

分發(fā)動(dòng)態(tài)數(shù)據(jù)使我們進(jìn)入分布式數(shù)據(jù)庫(kù)領(lǐng)域。如前所述，可能存在各種問(wèn)題。與CDN 相比，數(shù)據(jù)是高度動(dòng)態(tài)的；數(shù)據(jù)可以快速更改，并且可以進(jìn)行過(guò)濾和排序，這會(huì)帶來(lái)額外的復(fù)雜性。數(shù)據(jù)庫(kù)世界檢查了實(shí)現(xiàn)這一目標(biāo)的不同方法。早期的方法不得不做出犧牲才能達(dá)到所需的性能和可擴(kuò)展性。讓我們看看分布式搜索是如何演變的。

傳統(tǒng)數(shù)據(jù)庫(kù)的分布式方法

一個(gè)合乎邏輯的選擇是基于傳統(tǒng)數(shù)據(jù)庫(kù)（MySQL、PostgreSQL、SQL Server）構(gòu)建，因?yàn)橐呀?jīng)投入了大量的精力在其中。但是，傳統(tǒng)數(shù)據(jù)庫(kù)并非為分布式而構(gòu)建，因此采用了一種相當(dāng)簡(jiǎn)單的分布式方法。擴(kuò)展讀取的典型方法是使用讀取副本。讀取副本只是您的數(shù)據(jù)的副本，您可以從中讀取但不能寫(xiě)入。這樣的副本（或復(fù)制品）會(huì)將查詢(xún)從包含原始數(shù)據(jù)的節(jié)點(diǎn)中卸載。這種機(jī)制非常簡(jiǎn)單，因?yàn)閿?shù)據(jù)會(huì)隨著數(shù)據(jù)的到來(lái)而逐漸復(fù)制到副本中。

由于這種相對(duì)簡(jiǎn)單的方法，副本的數(shù)據(jù)總是比原始數(shù)據(jù)舊。如果您在特定時(shí)間點(diǎn)從副本節(jié)點(diǎn)讀取數(shù)據(jù)，您可能會(huì)獲得比從主節(jié)點(diǎn)讀取更舊的值。這稱(chēng)為“陳舊讀取”。使用傳統(tǒng)數(shù)據(jù)庫(kù)的程序員必須意識(shí)到這種可能性并考慮到這種限制來(lái)進(jìn)行編程。還記得我們一開(kāi)始給出的例子嗎？我們?cè)谄渲袑?xiě)入一個(gè)值并重新讀取它？使用傳統(tǒng)數(shù)據(jù)庫(kù)副本時(shí)，您無(wú)法期望讀取您寫(xiě)入的內(nèi)容。

您可以通過(guò)在所有副本都了解寫(xiě)入之前樂(lè)觀地應(yīng)用寫(xiě)入結(jié)果到前端來(lái)稍微改善用戶(hù)體驗(yàn)。但是，如果更新尚未到達(dá)副本，則網(wǎng)頁(yè)的重新加載可能會(huì)將UI 返回到之前的狀態(tài)。然后，用戶(hù)會(huì)認(rèn)為他的更改從未保存。

第一代分布式數(shù)據(jù)庫(kù)

在傳統(tǒng)數(shù)據(jù)庫(kù)的復(fù)制方法中，明顯的瓶頸是所有寫(xiě)入都轉(zhuǎn)到同一個(gè)節(jié)點(diǎn)。機(jī)器可以向上擴(kuò)展，但最終會(huì)遇到上限。隨著您的應(yīng)用程序越來(lái)越受歡迎以及寫(xiě)入次數(shù)的增加，數(shù)據(jù)庫(kù)將不再能夠快速接受新數(shù)據(jù)。為了水平擴(kuò)展讀取和寫(xiě)入，發(fā)明了分布式數(shù)據(jù)庫(kù)。分布式數(shù)據(jù)庫(kù)也保存數(shù)據(jù)的多個(gè)副本，但您可以寫(xiě)入這些副本中的每一個(gè)。由于您通過(guò)每個(gè)節(jié)點(diǎn)更新數(shù)據(jù)，因此所有節(jié)點(diǎn)都必須相互通信并互相告知新數(shù)據(jù)。換句話說(shuō)，它不再像傳統(tǒng)系統(tǒng)那樣是單向的了。

但是，這些類(lèi)型的數(shù)據(jù)庫(kù)仍然可能遭受前面提到的陳舊讀取，并引入許多其他與寫(xiě)入相關(guān)的潛在問(wèn)題。它們是否遭受這些問(wèn)題取決于他們?cè)诳捎眯院鸵恢滦苑矫孀龀龅臎Q定。

第一代分布式數(shù)據(jù)庫(kù)通常被稱(chēng)為“NoSQL 運(yùn)動(dòng)”，這個(gè)名稱(chēng)受到MongoDB 和Neo4j 等數(shù)據(jù)庫(kù)的影響，這些數(shù)據(jù)庫(kù)也為SQL 提供了替代語(yǔ)言和不同的建模策略（文檔或圖形而不是表）。 NoSQL 數(shù)據(jù)庫(kù)通常不具備典型的傳統(tǒng)數(shù)據(jù)庫(kù)功能，例如約束和聯(lián)接。隨著時(shí)間的推移，這個(gè)名稱(chēng)似乎是一個(gè)糟糕的名稱(chēng)，因?yàn)樵S多被認(rèn)為是NoSQL 的數(shù)據(jù)庫(kù)確實(shí)提供了某種形式的SQL。出現(xiàn)了多種解釋?zhuān)暦Q(chēng)NoSQL 數(shù)據(jù)庫(kù)：

• 不提供SQL 作為查詢(xún)語(yǔ)言。
• 不僅提供SQL（NoSQL = Not Only SQL）
• 不提供典型的傳統(tǒng)功能，例如聯(lián)接、約束、ACID 保證。
• 以不同的方式建模其數(shù)據(jù)（圖形、文檔或時(shí)間模型）

然后，一些較新的非關(guān)系型數(shù)據(jù)庫(kù)但提供SQL 的數(shù)據(jù)庫(kù)被稱(chēng)為“NewSQL”，以避免混淆。

對(duì)CAP 定理的錯(cuò)誤解釋

第一代數(shù)據(jù)庫(kù)受到CAP 定理的強(qiáng)烈啟發(fā)，該定理規(guī)定在網(wǎng)絡(luò)分區(qū)期間，您無(wú)法同時(shí)擁有一致性和可用性。網(wǎng)絡(luò)分區(qū)本質(zhì)上是發(fā)生某些事情導(dǎo)致兩個(gè)節(jié)點(diǎn)無(wú)法再互相告知新數(shù)據(jù)的情況，并且可能由于多種原因而出現(xiàn)（例如，據(jù)報(bào)道，鯊魚(yú)有時(shí)會(huì)咬斷谷歌的電纜）。一致性意味著數(shù)據(jù)庫(kù)中的數(shù)據(jù)始終正確，但不一定對(duì)您的應(yīng)用程序可用。可用性意味著您的數(shù)據(jù)庫(kù)始終在線，并且您的應(yīng)用程序始終能夠訪問(wèn)該數(shù)據(jù)，但這并不保證數(shù)據(jù)正確或在多個(gè)節(jié)點(diǎn)中相同。我們通常談?wù)摳呖捎眯裕驗(yàn)椴淮嬖?00% 的可用性?？捎眯砸? 位數(shù)字表示（例如99.9999% 的可用性），因?yàn)榭傆锌赡芤幌盗惺录?dǎo)致停機(jī)。

但是，如果沒(méi)有網(wǎng)絡(luò)分區(qū)會(huì)發(fā)生什么？數(shù)據(jù)庫(kù)供應(yīng)商對(duì)CAP 定理的理解過(guò)于籠統(tǒng)，要么選擇接受潛在的數(shù)據(jù)丟失，要么選擇可用，無(wú)論是否存在網(wǎng)絡(luò)分區(qū)。雖然CAP 定理是一個(gè)良好的開(kāi)端，但它并沒(méi)有強(qiáng)調(diào)在沒(méi)有網(wǎng)絡(luò)分區(qū)的情況下，可以實(shí)現(xiàn)高可用性和一致性。大多數(shù)時(shí)候，不存在網(wǎng)絡(luò)分區(qū)，因此通過(guò)將CAP 定理擴(kuò)展到PACELC 定理來(lái)描述這種情況是有意義的。關(guān)鍵的區(qū)別在于最后三個(gè)字母(ELC)，它們代表Else Latency Consistency（其他延遲一致性）。該定理規(guī)定，如果沒(méi)有網(wǎng)絡(luò)分區(qū)，數(shù)據(jù)庫(kù)必須平衡延遲和一致性。

簡(jiǎn)單來(lái)說(shuō)：如果沒(méi)有網(wǎng)絡(luò)分區(qū)，當(dāng)一致性保證提高時(shí)，延遲也會(huì)提高。但是，我們將看到現(xiàn)實(shí)比這還要微妙。

這與用戶(hù)體驗(yàn)有什么關(guān)系？

讓我們來(lái)看一個(gè)放棄一致性如何影響用戶(hù)體驗(yàn)的例子?？紤]一個(gè)應(yīng)用程序，它為您提供了一個(gè)友好的界面來(lái)組成人員團(tuán)隊(duì)；您可以將人員拖放到不同的團(tuán)隊(duì)中。

一旦您將一個(gè)人拖放到一個(gè)團(tuán)隊(duì)中，就會(huì)觸發(fā)一個(gè)更新來(lái)更新該團(tuán)隊(duì)。如果數(shù)據(jù)庫(kù)不能保證您的應(yīng)用程序能夠立即讀取此更新的結(jié)果，則UI 必須樂(lè)觀地應(yīng)用這些更改。在這種情況下，可能會(huì)發(fā)生不好的事情：

• 用戶(hù)刷新頁(yè)面，不再看到他的更新，并認(rèn)為他的更新消失了。當(dāng)他再次刷新時(shí)，它突然又回來(lái)了。
• 由于與另一個(gè)更新沖突，數(shù)據(jù)庫(kù)未成功存儲(chǔ)更新。在這種情況下，更新可能會(huì)被取消，用戶(hù)永遠(yuǎn)不會(huì)知道。他可能只會(huì)在下次重新加載時(shí)注意到他的更改消失了。

這種一致性和延遲之間的權(quán)衡引發(fā)了前端和后端開(kāi)發(fā)人員之間許多激烈的討論。第一組希望獲得出色的用戶(hù)體驗(yàn)，在用戶(hù)執(zhí)行操作時(shí)會(huì)收到反饋，并且可以100% 確定一旦他們收到此反饋并對(duì)其做出響應(yīng)，其操作的結(jié)果就會(huì)始終如一地保存。第二組希望構(gòu)建一個(gè)可擴(kuò)展且高性能的后端，并且認(rèn)為除了犧牲前面提到的用戶(hù)體驗(yàn)要求來(lái)實(shí)現(xiàn)這一點(diǎn)之外別無(wú)他法。

兩組都有合理的論點(diǎn)，但沒(méi)有萬(wàn)能的解決方案來(lái)同時(shí)滿(mǎn)足兩者。當(dāng)事務(wù)增加并且數(shù)據(jù)庫(kù)成為瓶頸時(shí)，他們唯一的選擇是選擇傳統(tǒng)數(shù)據(jù)庫(kù)復(fù)制或犧牲強(qiáng)一致性以換取所謂的“最終一致性”的分布式數(shù)據(jù)庫(kù)。在最終一致性中，對(duì)數(shù)據(jù)庫(kù)的更新最終將應(yīng)用于所有機(jī)器，但不能保證下一個(gè)事務(wù)能夠讀取更新的值。換句話說(shuō)，如果我將我的名字更新為“Robert”，那么如果我在更新后立即查詢(xún)我的名字，我無(wú)法保證我實(shí)際上會(huì)收到“Robert”。

一致性稅

為了處理最終一致性，開(kāi)發(fā)人員需要了解這種數(shù)據(jù)庫(kù)的局限性并做大量額外的工作。程序員經(jīng)常求助于用戶(hù)體驗(yàn)技巧來(lái)隱藏?cái)?shù)據(jù)庫(kù)的局限性，并且后端必須編寫(xiě)許多額外的代碼層來(lái)適應(yīng)各種故障場(chǎng)景。圍繞這些限制尋找和構(gòu)建創(chuàng)造性解決方案極大地影響了前端和后端開(kāi)發(fā)人員完成工作的方式，大大增加了技術(shù)復(fù)雜性，同時(shí)仍然無(wú)法提供理想的用戶(hù)體驗(yàn)。

我們可以將確保數(shù)據(jù)正確性所需的額外工作視為應(yīng)用程序開(kāi)發(fā)人員必須支付的“稅款”，以提供良好的用戶(hù)體驗(yàn)。這就是使用不提供在當(dāng)今Web 規(guī)模并發(fā)環(huán)境中有效的保證一致性的軟件系統(tǒng)的稅款。我們稱(chēng)之為一致性稅。

值得慶幸的是，新一代數(shù)據(jù)庫(kù)已經(jīng)出現(xiàn)，它不需要您支付一致性稅，并且可以在不犧牲一致性的情況下進(jìn)行擴(kuò)展！

第二代分布式數(shù)據(jù)庫(kù)

第二代分布式數(shù)據(jù)庫(kù)已經(jīng)出現(xiàn)，以提供強(qiáng)一致性（而不是最終一致性）。這些數(shù)據(jù)庫(kù)可以很好地?cái)U(kuò)展，不會(huì)丟失數(shù)據(jù)，也不會(huì)返回陳舊的數(shù)據(jù)。換句話說(shuō)，它們按預(yù)期運(yùn)行，不再需要了解限制或支付一致性稅。如果您更新一個(gè)值，那么下次讀取該值時(shí)，它始終會(huì)反映更新的值，并且不同的更新將按照寫(xiě)入的相同時(shí)間順序應(yīng)用。在撰寫(xiě)本文時(shí)，F(xiàn)aunaDB、Spanner 和FoundationDB 是唯一提供無(wú)限制強(qiáng)一致性（也稱(chēng)為嚴(yán)格串行化）的數(shù)據(jù)庫(kù)。

PACELC 定理重訪

第二代分布式數(shù)據(jù)庫(kù)已經(jīng)實(shí)現(xiàn)了一些以前被認(rèn)為是不可能的事情；它們偏向一致性，并且仍然提供低延遲。這成為可能，這要?dú)w功于諸如Calvin、Spanner 和Percolator 等智能同步機(jī)制，我們將在本系列文章的第4 篇中詳細(xì)討論。雖然舊的數(shù)據(jù)庫(kù)仍然難以在較低的延遲下提供高一致性保證，但在這些新智能算法上構(gòu)建的數(shù)據(jù)庫(kù)則沒(méi)有此類(lèi)限制。

數(shù)據(jù)庫(kù)設(shè)計(jì)極大地影響了高一致性下可達(dá)到的延遲。

由于這些新算法允許數(shù)據(jù)庫(kù)同時(shí)提供強(qiáng)一致性和低延遲，因此通常沒(méi)有充分的理由放棄一致性（至少在沒(méi)有網(wǎng)絡(luò)分區(qū)的情況下）。您這樣做的情況僅當(dāng)極低的寫(xiě)入延遲是唯一真正重要的事情，并且您愿意丟失數(shù)據(jù)以實(shí)現(xiàn)它時(shí)。

這些數(shù)據(jù)庫(kù)仍然是NoSQL 嗎？

對(duì)這一代分布式數(shù)據(jù)庫(kù)進(jìn)行分類(lèi)已不再是微不足道的事情。人們?nèi)栽谂Γ?, 2）解釋NoSQL 的含義，但它們都沒(méi)有完全說(shuō)得通，因?yàn)镹oSQL 和SQL 數(shù)據(jù)庫(kù)正在相互靠近。新的分布式數(shù)據(jù)庫(kù)借鑒了不同的數(shù)據(jù)模型（文檔、圖形、關(guān)系型、時(shí)間型），其中一些數(shù)據(jù)庫(kù)提供ACID 保證甚至支持SQL。它們與NoSQL 仍然有一點(diǎn)共同點(diǎn)：它們是為了解決傳統(tǒng)數(shù)據(jù)庫(kù)的局限性而構(gòu)建的。一個(gè)詞永遠(yuǎn)無(wú)法描述數(shù)據(jù)庫(kù)的行為。將來(lái)，通過(guò)回答以下問(wèn)題來(lái)描述分布式數(shù)據(jù)庫(kù)更有意義：

• 它是一致的嗎？
• 分布式是否依賴(lài)于讀取副本，或者它是真正分布式的？
• 它借鑒了哪些數(shù)據(jù)模型？
• 查詢(xún)語(yǔ)言的表達(dá)能力如何，它的局限性是什么？

結(jié)論

我們解釋了應(yīng)用程序現(xiàn)在如何從新一代全球分布式數(shù)據(jù)庫(kù)中受益，這些數(shù)據(jù)庫(kù)可以像CDN 一樣從最近的位置提供動(dòng)態(tài)數(shù)據(jù)。我們簡(jiǎn)要回顧了分布式數(shù)據(jù)庫(kù)的歷史，并發(fā)現(xiàn)這并非一帆風(fēng)順。開(kāi)發(fā)了許多第一代數(shù)據(jù)庫(kù)，它們的一致性選擇（主要由CAP 定理驅(qū)動(dòng)）要求我們編寫(xiě)更多代碼，同時(shí)仍然會(huì)降低用戶(hù)體驗(yàn)。直到最近，數(shù)據(jù)庫(kù)社區(qū)才開(kāi)發(fā)出允許分布式數(shù)據(jù)庫(kù)將低延遲與強(qiáng)一致性結(jié)合起來(lái)的算法。一個(gè)新時(shí)代已經(jīng)到來(lái)，一個(gè)我們不再需要在數(shù)據(jù)訪問(wèn)和一致性之間做出權(quán)衡的時(shí)代！

此時(shí)，您可能希望看到最終一致性數(shù)據(jù)庫(kù)潛在陷阱的具體示例。在本系列文章的下一篇文章中，我們將介紹這一點(diǎn)。敬請(qǐng)期待即將發(fā)表的文章：

文章系列

1. 為什么要關(guān)心一致性？
2. 可能出現(xiàn)哪些問(wèn)題？
3. 采用一致性數(shù)據(jù)庫(kù)的障礙是什么？
4. 新算法如何提供幫助？

以上是一致的后端和UX：您為什么要關(guān)心？的詳細(xì)內(nèi)容。更多信息請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！