產品更新：Cloudflare D1數(shù)據庫的最新進展

我們很高興地向大家宣布，D1 Alpha版用戶(包括任何Workers用戶)可以通過以下命令立即使用全新存儲后端創(chuàng)建新數(shù)據庫：

$wrangler d1 create your-database--experimental-backend

在接下來的幾周內，它將成為每個人的默認體驗，但我們希望邀請開發(fā)人員立即開始嘗試新版本的D1。我們也將進一步分享如何構建D1新存儲子系統(tǒng)以及它如何從Cloudflare的分布式網絡中受益。

我們來快速回顧一下：什么是D1？

D1是Cloudflare的原生無服務器數(shù)據庫，在去年11月發(fā)布Alpha版。開發(fā)人員一直在使用Workers、KV、Durable Objects等構建復雜的應用程序，但是他們一致要求我們做一件事情：一個可以查詢的數(shù)據庫。

我們還收到一致的反饋：這個數(shù)據庫應該基于SQL，自動縮放，并且(和Workers本身一樣)，采用全球(“Region:Earth”)復制方式。因此，我們接受了這些反饋并開始構建D1，SQLite為我們提供了一種熟悉的SQL方言、強大的查詢引擎和經過最充分實戰(zhàn)考驗的代碼庫之一。

我們將D1的第一個版本以Alpha版進行了發(fā)布：這是我們公開開發(fā)的一種方式，可以直接從開發(fā)人員那里收集反饋，并更好地優(yōu)先考慮重要的事情。名副其實，這個alpha版存在bug和性能問題，而且“理想路徑”相當狹窄。

盡管如此，我們已經看到開發(fā)人員啟動了數(shù)千個數(shù)據庫，進行了數(shù)十億次查詢，流行的ORM(例如Drizzle和Kysely)增加對D1的支持，且Remix和Nuxt模板直接圍繞它構建。

不斷完善

如果您已經使用過Alpha版的D1：經過完善的版本將進一步刷新您對D1的已有認知。D1現(xiàn)已顯著提速，我們剛將著名的Northwind Traders演示數(shù)據庫遷移到使用我們的全新存儲后端，速度提高了20倍：

我們的新架構還提高了寫入性能：一個插入1000行（每行約200字節(jié)寬）的簡單基準測試比先前版本的D1快大約6.8倍。

更大的批次(每批1萬行，每行約200字節(jié)寬)看到更大的改進：達到10-11倍，而且新存儲后端的延遲也明顯更加一致。我們還沒有開始優(yōu)化總體寫吞吐量，因此D1只會變得更快。

通過我們的新存儲后端，我們不斷將其性能與其他無服務器數(shù)據庫進行基準測試。對一個50萬行的鍵值對表進行查詢（認識到基準測試本質上是合成的），D1的性能比流行的無服務器數(shù)據庫Postgres快大約3.2倍：

我們運行了多次Postgres查詢來預熱頁面緩存，然后采用服務器測量的中位數(shù)查詢時間。后續(xù)開發(fā)中，我們將繼續(xù)提高性能優(yōu)勢。

已有數(shù)據庫的開發(fā)人員可以按照文檔中的步驟將數(shù)據導入到由該存儲引擎支持的新數(shù)據庫中，方法是先將數(shù)據庫導出，然后將其導入。

逐步優(yōu)化D1的開發(fā)人員體驗

我們還一直在努力改進D1的開發(fā)人員體驗：

新增控制臺界面，可直接從儀表板發(fā)出查詢，更易開始使用和/或發(fā)出一次性查詢。

正式支持JSON函數(shù)，通過JSON在數(shù)據庫中直接查詢。

Location Hints，允許影響leader(負責寫入)在全球范圍內的位置。

盡管D1是專為在Cloudflare Workers內原生運行而設計的，但我們意識到，在進行原型設計或僅探索一個數(shù)據庫時，通常需要快速通過CLI或Web編輯器發(fā)出一次性查詢。除了支持在wrangler內支持執(zhí)行查詢(和文件)外，我們還引入了控制臺編輯器，用于發(fā)出查詢、檢查表格，甚至可以實時編輯數(shù)據：

JSON函數(shù)讓您可以查詢D1數(shù)據庫TEXT列存儲的JSON：這使您可以靈活地確定哪些數(shù)據與您的關系數(shù)據庫模式嚴格相關，哪些不相關，同時仍然能夠通過SQL查詢所有數(shù)據(在數(shù)據到達您的應用程序之前)。

例如，假設您將最后登錄時間戳以JSON數(shù)組格式存儲在login_history TEXT列：我可以通過提供到其鍵的路徑直接查詢(和提取)子對象或數(shù)組項：

SELECT user_id,json_extract(login_history,'$.【0】')as latest_login FROM users

D1對JSON函數(shù)的支持非常靈活，并利用了構建D1的SQLite核心。

當您首次使用D1創(chuàng)建數(shù)據庫時，我們會根據您當前連接的位置自動推斷位置。然而，某些情況下，您可能希望影響數(shù)據庫的位置——也許您正在旅行，或者您的分布式團隊不同于您預期大多數(shù)寫入來自的地區(qū)。

D1對Location Hints的支持

#Automatically inferred based your location

$wrangler d1 create user-prod-db--experimental-backend

#Indicate a preferred location to create your database

$wrangler d1 create eu-users-db--location=weur--experimental-backend

Location Hints也可通過Cloudflare儀表板使用：

我們還發(fā)布了更多文檔，不僅能幫助開發(fā)人員入門，還能利用D1的高級特性。未來幾個月內，預計D1的文檔將繼續(xù)大幅增加。

合理的定價策略

自從宣布alpha版以來，已經有許多開發(fā)人員問到D1價格的問題，現(xiàn)在我們準備介紹一下定價。我們知道，在開始使用某個產品進行構建之前了解其定價很重要，這樣您就不會在6個月后感到吃驚了。

簡而言之：

我們準備宣布定價，以便您可以提前預估D1將為您的用例帶來多少成本。最終定價可能會有所變化，但我們預計變化幅度會比較小。

我們將在今年晚些時候才開始計費，而且我們將提前通過電子郵件通知現(xiàn)有客戶。在那之前，D1將依然免費使用。

D1將包括一個永遠免費的級別，包括作為5美元/月Workers訂閱的一部分使用，并根據讀、寫和存儲量收費。

如果您已經訂閱了Workers，那么您不會受到任何影響：在我們未來啟用計費時，您的現(xiàn)有訂閱將包括D1使用。

總結如下：

重要的是，當我們啟用全球讀取復制時，您將不需要支付額外費用，復制也不會使您的存儲消耗倍增。我們認為內置、自動的復制很重要，開發(fā)人員不應該支付倍乘費用(副本x存儲費)，以使其數(shù)據庫在每一個地方都能快速運行。

除此之外，我們希望確保D1具有無服務器產品定價的優(yōu)點——可以根據需求進行自動縮放和按使用量付費，這樣您就不需要嘗試確定工作負載所需的CPU和/或內存數(shù)量，也不需要編寫腳本在負載較低的時間段縮小基礎架構規(guī)模。

D1的讀取定價基于“讀取單位”（每4KB讀?。┖汀皩懭雴挝弧保?KB寫入）的熟悉概念。查詢（掃描）大約10000行，每行64個字節(jié)，將消耗160個讀取單位。在“blog_posts”表中寫入一個大的3KB行，其中包含大量Markdown，這將消耗3個寫入單位。如果您為最常用的查詢創(chuàng)建索引以提高性能并減少這些查詢需要掃描的數(shù)據量，您還可以進一步減少計費。我們認為通過默認使快速路徑更具成本效益是正確的方法。

在此需要強調的是：在開始收費前，我們將繼續(xù)接受有關定價的反饋。

Time Travel

我們還引入了新的備份功能：時間點恢復，并將其稱為“Time Travel(時間旅行)”，因為這就是它給人的感覺。Time Travel允許您將D1數(shù)據庫恢復到過去30天內的任何一分鐘，并且將內置于使用我們新存儲系統(tǒng)的D1數(shù)據庫中。我們預計在不久的將來為新的D1數(shù)據庫開啟Time Travel功能。

使Time Travel真正強大的地方在于，您不再需要驚慌地想“噢，等等，我在做這個重大更改之前是否備份了數(shù)據庫？”——因為我們已經為您做了這件事。我們保留了對您的數(shù)據庫所有更改的流(Write-Ahead Log)，允許您通過按順序重放這些更改，從而將您的數(shù)據庫恢復到某個時間點。

這里是一個示例(API可能會有一些小的變化)：

#Using a precise Unix timestamp(in UTC):

$wrangler d1 time-travel my-database--before-timestamp=1683570504

#Alternatively,restore prior to a specific transaction ID:

$wrangler d1 time-travel my-database--before-tx-id=01H0FM2XHKACETEFQK2P5T6BWD

盡管時間點恢復并非新的想法，但它通常是一個付費的附加功能，甚至根本不提供。在進行了刪除或犯了錯誤之后才意識到應該打開它，通常為時已晚。

例如，想象一下我犯了這個經典錯誤：在一條UPDATE語句中忘記了WHERE：

--Don't do this at home

UPDATE users SET email='matt example.com'--missing:WHERE id="abc123"

如果沒有Time Travel，我只能祈禱最近運行了計劃備份，或者記得在之前進行了手動備份。有了Time Travel，我可以將數(shù)據庫恢復到在犯錯誤前一分鐘左右的某個時間點（并希望下次能吸取教訓）。

我們還在探索一些功能，以顯示數(shù)據庫狀態(tài)的更大變化，包括使識別模式更改、表數(shù)、存儲數(shù)據的重大變化，甚至特定查詢(通過事務ID)，以幫助您更好地了解恢復數(shù)據庫的確切時間點。

路線圖

那么D1的下一步？

·開放beta：我們正在確保，在將新的存儲子系統(tǒng)作為所有“d1 create”命令的默認設置之前，在負載（和實際使用）下觀察它的表現(xiàn)。即使是“beta”，我們對耐久性和可用性也有很高的要求，并且我們還意識到備份功能（Time Travel）對于人們信任一個新數(shù)據庫是很重要的。接下來的幾周內，歡迎關注Cloudflare博客以獲取更多相關消息！

·更大的數(shù)據庫：這是很多人的重要需求，我們已經非常接近實現(xiàn)了。使用Workers Paid計劃的開發(fā)人員將在不久的將來獲得1 GB數(shù)據庫的使用權限，我們也將繼續(xù)提升每個數(shù)據庫的最大容量。

·運行參數(shù)及數(shù)據可視性：您將能夠通過D1儀表板和我們的GraphQL API檢查每個數(shù)據庫的總體查詢量、失敗查詢、消耗的存儲空間以及讀/寫單位數(shù)，從而可以更高效便捷地調試問題和跟蹤支出。

·自動讀取復制：我們的新存儲子系統(tǒng)在構建時就考慮到了復制，并且我們正在努力確保復制層足夠快速和可靠，然后才提供給開發(fā)人員使用。讀取復制不僅旨在通過在接近用戶的多個地點存儲副本來改善查詢延遲，還將允許我們橫向擴展具有更大工作負載的D1數(shù)據庫。

與此同時，您可以立即開始使用D1構建原型和進行試驗，探索我們的D1+Drizzle+Remix示例項目，或加入Cloudflare Developers Discord服務器上的#d1頻道，與D1團隊和其他正在利用D1構建的人進行直接交流。