原文標題：Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)

OpenAI 10 月 23 日公布 Habitat 線上儲存平台的第二篇工程實務文章。Habitat 負責讓 ChatGPT、API、Codex 與內部服務快速取得需要的資料，官方描述其服務對象已超過十億使用者，分布在四十個地理區域，儲存資料規模超過 500 PB。這些是平台層級的規模資訊，不代表每位使用者的個別資料量或單一資料庫容量。

報告說明，OpenAI 一開始由簡單的用戶端程式庫與資料庫逐步演化出全球分散式儲存服務。第二篇聚焦底層 Azure Cosmos DB 的擴充方法，並提到與 Azure 團隊密切合作，最終採用由雙方共同管理的容器與多租戶模式，以改善大規模下的讀取效能和可靠度。

OpenAI 將儲存平台的擴充過程拆成幾個階段：早期依賴 Cosmos DB 原生分割區機制，遇到單一邏輯分割鍵限制、熱門租戶影響其他租戶及分割區配置不均等問題；之後嘗試工作負載隔離與單租戶配置，卻發現整體容量成長與規劃更難管理；後續改為預設多租戶，同時保留必要時移動資料的能力。

在新的設計下，平台需要處理熱門鍵限流、服務品質與無伺服器模式等差異，並依各種資料的讀取頻率與延遲需求決定配置。OpenAI 也提出資料應盡量靠近使用者、僅對最小且最需要低延遲的資料集進行廣泛複寫，其餘盡量利用整合式快取，並藉由 Rust 減少代理層開銷的方向。

從公開的架構圖可見，Habitat 除 Cosmos DB 外也包含 Nanobase、Valkey 快取、Blob 儲存，以及將變更資料擷取（CDC）送往 Databricks、Rockset 與 Kafka 等服務的能力。這些元件各自承擔不同需求，文章主軸並非宣稱某一資料庫可以單獨解決所有全球規模的儲存問題。

OpenAI 指出，擴充平台時必須在可靠性、全球效能與開發者操作速度間反覆取捨。這份案例呈現高成長服務如何在既有雲端資料庫之上建立額外的隔離、路由、授權、快取與資料駐留控制，而不是單純提高機器規格。

發生了什麼事

OpenAI 公開 Habitat 第二篇架構報告，說明其如何使用 Azure Cosmos DB、多租戶與快取設計服務逾十億使用者。

為什麼重要

在數百 PB 與多區域條件下，資料分割、熱門租戶隔離及跨區域延遲都會影響服務品質；案例提供大型線上服務的實際設計取捨。

影響哪些人

雲端平台工程師、資料庫架構師、SRE、分散式系統開發者，以及需要規劃多租戶 SaaS 儲存平台的企業。

已確認與未確認

已確認官方公布的逾十億使用者、四十個區域與超過 500 PB，以及 Cosmos DB 多租戶設計方向。個別產品的資料量、所有配置參數與單一客戶效能不在本篇公告可驗證範圍。