構(gòu)建Worker應(yīng)用的開發(fā)人員專注于他們正在創(chuàng)建的內(nèi)容，無需關(guān)注所需的基礎(chǔ)設(shè)施，并從Cloudflare的全球網(wǎng)絡(luò)中獲益。從個(gè)人項(xiàng)目到關(guān)鍵業(yè)務(wù)工作負(fù)載，許多應(yīng)用都需要持久數(shù)據(jù)。Workers提供各種根據(jù)開發(fā)人員的需求量身定制的數(shù)據(jù)庫和存儲選項(xiàng)，例如鍵值和對象存儲。

關(guān)系數(shù)據(jù)庫是當(dāng)今許多應(yīng)用程序的支柱。D1——Cloudflare的關(guān)系數(shù)據(jù)庫——現(xiàn)已正式推出。從2022年底alpha版到2024年4月正式發(fā)布，我們一直專注于讓開發(fā)人員能夠通過熟悉的關(guān)系數(shù)據(jù)和SQL來構(gòu)建生產(chǎn)工作負(fù)載。

什么是D1？

D1是Cloudflare內(nèi)置的無服務(wù)器關(guān)系數(shù)據(jù)庫。對于Worker應(yīng)用程序，D1利用SQLite的SQL方言提供SQL的表達(dá)能力，并提供開發(fā)人員工具集成，包括對象關(guān)系映射器（ORM），例如Drizzle ORM?？赏ㄟ^Workers或HTTP API訪問D1。

無服務(wù)器意味著無需配置，基于Time Travel的默認(rèn)災(zāi)難恢復(fù)，以及基于使用量的定價(jià)。D1包括一個(gè)慷慨的免費(fèi)層，允許開發(fā)人員試用D1，然后將這些試用升級到生產(chǎn)環(huán)境。

如何使數(shù)據(jù)全球化？

D1正式版注重可靠性和開發(fā)人員體驗(yàn)。現(xiàn)在我們計(jì)劃擴(kuò)展D1，以更好地支持全球分布式應(yīng)用程序。

在Workers模式中，入站請求會在最接近的數(shù)據(jù)中心調(diào)用無服務(wù)器執(zhí)行。Worker應(yīng)用程序可根據(jù)用戶請求進(jìn)行擴(kuò)展到全球。然而，應(yīng)用數(shù)據(jù)依然存儲在集中式數(shù)據(jù)庫中，全球用戶流量必須考慮到數(shù)據(jù)位置的訪問往返。例如，現(xiàn)在的D1數(shù)據(jù)庫位于單一位置。

Workers支持Smart Placement，以考慮頻繁訪問的數(shù)據(jù)位置。Smart Placement會調(diào)用更靠近中央后端服務(wù)（如數(shù)據(jù)庫）的Worker，以降低延遲并提高應(yīng)用程序性能。我們已經(jīng)解決了全球應(yīng)用程序中Workers的放置問題，但還需要解決數(shù)據(jù)放置問題。

那么問題來了，作為Cloudflare的內(nèi)置數(shù)據(jù)庫解決方案，D1如何才能更好地支持全球應(yīng)用程序的數(shù)據(jù)放置？答案就是異步讀復(fù)制。

什么是異步讀復(fù)制？

在基于服務(wù)器的數(shù)據(jù)庫管理系統(tǒng)（如Postgres、MySQL、SQL Server或Oracle）中，讀副本是一個(gè)單獨(dú)的數(shù)據(jù)庫服務(wù)器，作為主數(shù)據(jù)庫服務(wù)器的一個(gè)只讀、幾乎最新的副本。管理員創(chuàng)建讀副本的方法是，從主服務(wù)器的快照啟動一個(gè)新服務(wù)器，并配置主服務(wù)器以異步方式向副本服務(wù)器發(fā)送更新。由于更新是異步的，因此讀取副本可能會滯后于主服務(wù)器的當(dāng)前狀態(tài)。主服務(wù)器和副本之間的差異稱為副本延遲。讀副本可以不止一個(gè)。

異步讀復(fù)制是一種久經(jīng)考驗(yàn)的數(shù)據(jù)庫性能提高解決方案：

-通過在多個(gè)副本之間分配負(fù)載可以提高吞吐量。

-當(dāng)副本靠近進(jìn)行查詢的用戶時(shí)，就有可能降低查詢延遲。

請注意，有些數(shù)據(jù)庫系統(tǒng)也提供同步復(fù)制功能。在同步復(fù)制系統(tǒng)中，寫入必須等到所有副本都確認(rèn)寫入后才能進(jìn)行。同步復(fù)制系統(tǒng)的運(yùn)行速度只能達(dá)到最慢復(fù)制的速度，當(dāng)一個(gè)復(fù)制失敗時(shí)，系統(tǒng)就會停止運(yùn)行。如果我們要在全球規(guī)模上提高性能，就必須盡可能避免同步復(fù)制！

一致性模型&讀副本

大多數(shù)數(shù)據(jù)庫系統(tǒng)都提供讀已提交、快照隔離或可序列化的一致性模型，具體取決于配置。例如，Postgres默認(rèn)為讀已提交模型，但可以配置為使用更強(qiáng)的模型。SQLite在WAL模型下提供快照隔離?？煺崭綦x或可序列化等較強(qiáng)模型更易于編程，因?yàn)樗鼈兿拗屏嗽试S的系統(tǒng)并發(fā)情景和程序員需要擔(dān)心的并發(fā)競態(tài)條件。

讀副本是獨(dú)立更新的，因此每個(gè)副本的內(nèi)容在任何時(shí)刻都可能不同。如果所有查詢都在同一臺服務(wù)器上進(jìn)行，無論是主服務(wù)器還是讀取副本，那么查詢結(jié)果都會根據(jù)底層數(shù)據(jù)庫提供的任何一致性模型保持一致。如果您使用的是讀副本，結(jié)果可能會有點(diǎn)過時(shí)。

如果一個(gè)基于服務(wù)器的數(shù)據(jù)庫使用讀副本，一個(gè)會話中的所有查詢都使用同一個(gè)服務(wù)器是很重要的。如果在同一會話中切換不同的讀副本，就會破壞應(yīng)用程序提供的一致性模型，這可能會違反您對數(shù)據(jù)庫運(yùn)行方式的假設(shè)，并導(dǎo)致應(yīng)用程序返回不正確的結(jié)果！

示例

例如，有兩個(gè)副本A和B。副本A比主數(shù)據(jù)庫滯后100毫秒，副本B比主數(shù)據(jù)庫滯后2秒。假設(shè)用戶希望

1.執(zhí)行查詢1

1a.根據(jù)查詢1的結(jié)果進(jìn)行計(jì)算

2.根據(jù)(1a)中的計(jì)算結(jié)果執(zhí)行查詢2

在t=10秒時(shí)，查詢1進(jìn)入副本A并返回。查詢1可以看到主數(shù)據(jù)庫在t=9.9秒時(shí)的樣子。假設(shè)計(jì)算需要500毫秒，那么在t=10.5秒時(shí)，查詢2訪問副本B。請記住，副本B比主數(shù)據(jù)庫滯后2秒，因此在t=10.5秒時(shí)，查詢2看到的是數(shù)據(jù)庫在t=8.5秒時(shí)的樣子。就應(yīng)用程序而言，查詢2的結(jié)果看起來就像數(shù)據(jù)庫在時(shí)間上倒退了！

從形式上看，這就是讀已提交一致性，因?yàn)槟愕牟樵冎荒芸吹揭烟峤坏臄?shù)據(jù)，但沒有其他保證，甚至不能保證你能讀取自己寫入的數(shù)據(jù)。雖然讀已提交是一種有效的一致性模型，但很難推理讀已提交模型所允許的所有可能競態(tài)條件，因此很難正確的編寫應(yīng)用程序。

D1的一致性模型&讀副本

默認(rèn)情況下，D1使用SQLite所提供的快照隔離。

快照隔離是一種熟悉的一致性模型，大多數(shù)開發(fā)人員都認(rèn)為這種模型易于使用。我們在D1中實(shí)現(xiàn)這種一致性模型的方法是，確保D1數(shù)據(jù)庫只有一個(gè)活動副本，并將所有HTTP請求路由到該單一數(shù)據(jù)庫。雖然確保D1數(shù)據(jù)庫最多只有一個(gè)活動副本是一個(gè)棘手的分布式系統(tǒng)問題，但我們通過使用Durable Objects構(gòu)建D1解決了這個(gè)問題。Durable Objects保證了全局唯一性，因此一旦我們依賴Durable Objects，路由HTTP請求就變得非常簡單了：只需將它們發(fā)送到D1 Durable Object即可。

如果數(shù)據(jù)庫有多個(gè)活動副本，這種方法就不管用了，因?yàn)闆]有100%可靠的方法來查看傳入的HTTP請求，并將其100%地路由到相同的副本。不幸的是，正如我們在上一節(jié)的示例中看到的，如果我們不能在100%的時(shí)間內(nèi)將相關(guān)請求路由到同一個(gè)副本，那么我們所能提供的最佳一致性模型就是讀已提交。

鑒于不可能一致地路由到特定副本，另一種方法是將請求路由到任何副本，并確保所選副本根據(jù)對程序員"有意義"的一致性模型響應(yīng)請求。如果我們愿意在請求中包含Lamport時(shí)間戳，就可以使用任何副本實(shí)現(xiàn)順序一致性。順序一致性模型具有“讀取我自己的寫入”、“寫入跟隨讀取”以及寫入全排序等重要屬性。寫入全排序意味著每個(gè)副本都會看到事務(wù)以相同的順序提交，這正是我們在事務(wù)系統(tǒng)中希望看到的行為。順序一致性有一個(gè)限制條件，那就是系統(tǒng)中的任何單個(gè)實(shí)體都可能任意過時(shí)，但這一限制條件對我們來說是一個(gè)特征，因?yàn)樗试S我們在設(shè)計(jì)API時(shí)考慮副本滯后的問題。

我們的想法是，如果D1為應(yīng)用程序的每次數(shù)據(jù)庫查詢提供一個(gè)Lamport時(shí)間戳，而這些應(yīng)用程序告訴D1它們看到的最后一個(gè)Lamport時(shí)間戳，我們就可以讓每個(gè)副本根據(jù)順序一致性模型來決定如何讓查詢工作。

對副本實(shí)現(xiàn)順序一致性，一種穩(wěn)健且簡單的方法是：

-將Lamport時(shí)間戳與對數(shù)據(jù)庫的每一個(gè)請求相關(guān)聯(lián)。單調(diào)遞增的提交令牌就很好地解決了這個(gè)問題。

-將所有寫入查詢發(fā)送到主數(shù)據(jù)庫，以確保寫入全排序。

-向任意副本發(fā)送讀取查詢，但讓副本滯后服務(wù)查詢，直到副本從主數(shù)據(jù)庫接收到晚于查詢中Lamport時(shí)間戳的更新。

這種實(shí)現(xiàn)方式的優(yōu)點(diǎn)是，在讀取量大的工作負(fù)載總是訪問同一個(gè)副本的常見用例中，速度很快，而且即使請求被路由到不同的副本，它也能正常工作。

搶先劇透：使用會話將讀復(fù)制引入D1

為了將讀復(fù)制引入D1，我們將使用一個(gè)新概念來擴(kuò)展D1 API：會話。會話封裝了代表應(yīng)用的一個(gè)邏輯會話的所有查詢。例如，一個(gè)會話可能代表來自特定Web瀏覽器的所有請求或來自移動應(yīng)用程序的所有請求。如果使用會話，您的查詢將使用對您的請求最有意義的D1數(shù)據(jù)庫副本，無論是主數(shù)據(jù)庫還是附近的副本。D1的會話實(shí)現(xiàn)將確保會話中所有查詢的順序一致性。

由于會話API改變了D1的一致性模型，開發(fā)人員必須選擇使用新的API。現(xiàn)有的D1 API方法不變，仍將采用與以前相同的快照隔離一致性模型。不過，只有使用新的會話API進(jìn)行的查詢才會使用副本。

下面是D1會話API的示例：

D1的會話實(shí)現(xiàn)使用提交令牌。提交令牌標(biāo)識了已提交到數(shù)據(jù)庫的特定查詢。在會話中，D1使用提交令牌確保查詢按順序排列。在上面的示例中，D1會話確?！癝ELECT COUNT( )”查詢發(fā)生在新順序的“INSERT”之后，即使我們在等待之間切換副本也是如此。

關(guān)于如何在Workers fetch handler中啟動會話，有幾個(gè)選項(xiàng)。

db.withSession(<condition>)接受這些參數(shù)：

通過“往返”會話的最后一個(gè)查詢的提交令牌，并使用它來啟動一個(gè)新會話，可以讓一個(gè)會話跨多個(gè)請求。這使得每個(gè)用戶代理，例如Web應(yīng)用或移動應(yīng)用，都能夠確保用戶看到的所有查詢都是順序一致的。

D1的讀復(fù)制將是內(nèi)置功能，不會產(chǎn)生額外的使用成本或存儲成本，并且不需要配置副本。Cloudflare將監(jiān)控應(yīng)用程序的D1流量，并自動創(chuàng)建數(shù)據(jù)庫副本，將用戶流量分散到離用戶更近的多個(gè)服務(wù)器上。與我們的無服務(wù)器模式相一致，D1開發(fā)人員無需擔(dān)心副本的配置和管理。相反，開發(fā)人員應(yīng)該專注于設(shè)計(jì)應(yīng)用，以實(shí)現(xiàn)復(fù)制和數(shù)據(jù)一致性的權(quán)衡。

我們正積極開發(fā)全局讀復(fù)制和實(shí)現(xiàn)上述方案（歡迎在我們的開發(fā)人員Discord服務(wù)器#d1頻道中分享您的任何反饋）。在實(shí)現(xiàn)上述功能之前，D1正式版會包含幾個(gè)令人興奮的新功能。

了解D1正式版

自2023年10月D1開放測試版發(fā)布以來，我們一直專注于D1的可靠性、可擴(kuò)展性以及開發(fā)人員對關(guān)鍵服務(wù)的體驗(yàn)要求。我們投資開發(fā)了多項(xiàng)新功能，使開發(fā)人員能夠更快地使用D1構(gòu)建和調(diào)試應(yīng)用程序。

利用更大的數(shù)據(jù)庫構(gòu)建更大型的系統(tǒng)

我們聽取了開發(fā)人員對更大數(shù)據(jù)庫的需求?，F(xiàn)在，D1支持高達(dá)10 GB的數(shù)據(jù)庫，Workers Paid計(jì)劃中支持5萬個(gè)數(shù)據(jù)庫。通過D1的橫向擴(kuò)展，應(yīng)用程序可以建立每個(gè)業(yè)務(wù)實(shí)體獨(dú)立數(shù)據(jù)庫的模型。自測試版發(fā)布以來，新的D1數(shù)據(jù)庫在給定時(shí)間內(nèi)處理的請求量是D1 alpha數(shù)據(jù)庫的40倍。

導(dǎo)入&導(dǎo)出批量數(shù)據(jù)

開發(fā)人員導(dǎo)入和導(dǎo)出數(shù)據(jù)有多種原因：

-不同數(shù)據(jù)庫系統(tǒng)之間的數(shù)據(jù)庫遷移測試

-用于本地開發(fā)或測試的數(shù)據(jù)副本

-針對合規(guī)性等定制要求進(jìn)行手動備份

雖然以前可以針對D1執(zhí)行SQL文件，但我們正在改進(jìn)wrangler d1 execute–file=&lt;filename&gt;以確保大型導(dǎo)入是原子操作，不會讓數(shù)據(jù)庫處于中途狀態(tài)。wrangler d1 execute現(xiàn)在默認(rèn)為優(yōu)先本地執(zhí)行，以保護(hù)您的遠(yuǎn)程生產(chǎn)數(shù)據(jù)庫。

要導(dǎo)入我們的Northwind Traders演示數(shù)據(jù)庫，您可以下載模式&數(shù)據(jù)并執(zhí)行SQL文件。

D1數(shù)據(jù)庫數(shù)據(jù)&模式、純模式或純數(shù)據(jù)可通過以下方式導(dǎo)出為SQL文件：

調(diào)試查詢性能

了解SQL查詢性能和調(diào)試緩慢的查詢是生產(chǎn)工作負(fù)載的關(guān)鍵步驟。我們添加了實(shí)驗(yàn)性的wrangler d1 insights來幫助開發(fā)人員分析查詢性能指標(biāo)，這些指標(biāo)也可通過GraphQLAPI獲取。

開發(fā)人員工具

各種社區(qū)開發(fā)者項(xiàng)目都支持D1。新增項(xiàng)目包括Prisma ORM，版本為5.12.0，現(xiàn)在支持Workers和D1。

有關(guān)后續(xù)

正式版現(xiàn)在提供的功能和我們的全局讀復(fù)制設(shè)計(jì)只是滿足開發(fā)人員的應(yīng)用程序SQL數(shù)據(jù)庫需求的開始。如果您還沒有使用過D1，可以立即開始，訪問D1的開發(fā)人員文檔來激發(fā)一些想法，或者在我們的開發(fā)人員Discord服務(wù)器上加入#d1頻道，與其他D1開發(fā)人員和我們的產(chǎn)品工程團(tuán)隊(duì)進(jìn)行交流。