物理分區 - Azure CosmosDB

Question

我們正在評估用於MongoDB替換的Azure Cosmos DB。我們擁有500萬份文檔，每份文檔大小約20 KB。由於JSON的規模，Mongo的收藏總大小約爲50 GB，我們預計它在Cosmos中的收藏量將增加15％。此外，還有一個160萬個文件的早期增加。我們的吞吐量要求是每秒大約10000個查詢。查詢可以是單個文檔，也可以是一組文檔。查詢單個文檔大約需要5 RU，並且需要10到20 RU左右的多個文檔。 爲了獲得所需的吞吐量，我們需要對集合進行分區。

想獲得以下問題的答案嗎？

1. Cosmos DB內部使用了多少個物理分區？門戶網站指標只顯示10個分區。情況總是如此嗎？
2. 每個物理分區的最大大小是多少？門戶網站指標稱它爲10 GB。我們如何存儲超過100 GB的數據？
3. 每個分區的最大RU是多少？當單個分區變得非常熱以查詢時，我們是否會受到限制？

這些是我們想要克服的首要障礙，然後才能真正着手進一步推進Cosmos DB的採用。

Answer 1

1. 物理分區的數量由Cosmos服務管理。一般來說，你從10開始，但如果需要更多，系統會透明地爲你添加它們。

2. 物理分區的最大大小不應該成爲應用程序的問題。當你創建一個分區集合時，你正在處理「邏輯分區」而不是物理分區。 Cosmos將確保作爲邏輯分區一部分的所有文檔（具有相同的分區鍵）始終放在其中一個物理分區上。但是，如第1部分所述，Cosmos將負責確保您擁有適當數量的物理分區來存儲您的數據。換句話說，任何給定的物理分區都將包含許多邏輯分區，並且這些分區可以根據需要進行負載均衡和移動。

3. 每個物理分區的最大RU數是您的總RU/s除以物理分區數。因此，如果您擁有10個物理分區的10000 RU集合，則實際上每個物理分區的容量限制爲1000 RU。出於這個原因，爲您的文檔選擇合適的邏輯分區鍵很重要。如果您創建熱點，則可以在總配置的RU之下進行節流。

我建議你花一些時間閱讀關於分區和與宇宙的規模。 The documentation and video available on this page相當有幫助。這裏是直接從網頁複製一些額外的信息：/

• 您提供有T請求宇宙DB集裝箱吞吐量
• 在幕後，所需昌隆DB規定分區服務牛逼的請求/秒。如果T高於每個分區的最大吞吐量t，則Cosmos DB提供N = T/t分區
• Cosmos DB在N個分區間均勻分配分區密鑰散列的密鑰空間。因此，每個分區（物理分區）承載1-N分區鍵值（邏輯分區）
• 當物理分區p達到其存儲限制時，Cosmos DB將p無縫拆分成兩個新分區p1和p2，並將大致對應的值一半是每個分區的密鑰。這種拆分操作對於您的應用程序是不可見的。
• 同樣，當您提供高於t * N吞吐量的吞吐量時，Cosmos DB將分割您的一個或多個分區以支持更高的吞吐量