簡體   English   中英

關於 Cosmos DB 物理和邏輯分區的一些問題

[英]Some questions about Cosmos DB Physical and Logical Partitions

我試圖了解 Azure Cosmos DB 中物理/邏輯分區和吞吐量可用性之間的關系,並有幾個問題。

參考文檔: https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview

根據文檔,這是我的理解:

  1. 每個物理分區可以容納 50GB 數據,而每個邏輯分區可以容納 20GB。
  2. 總預置吞吐量均勻分布在所有物理分區中。
  3. 每個物理分區最多可以有 10000 RU/s。
  4. Cosmos DB 引擎會在需要時自動創建物理分區,並相應地移動邏輯分區。

現在我的問題是:

  • 創建額外物理分區背后的邏輯是什么?

它是基於邏輯分區占用的空間還是基於物理分區中所有邏輯分區消耗的吞吐量或完全其他的東西。 例如,

  1. 如果我提供 20000 RU/s 的吞吐量(無論我是否使用它),Cosmos DB 引擎會自動創建 2 個物理分區嗎?
  2. Cosmos DB 引擎會先創建一個物理分區(我剛剛創建了一個容器,里面沒有數據,並且預配的吞吐量小於 10000 RU/s)嗎?
  3. 如果預配的總吞吐量小於 10000 RU/s 和/或邏輯分區的總大小低於 50 GB,Cosmos DB 引擎是否會自動刪除物理分區。

對此的任何見解都將受到高度贊賞。

更新

根據評論,我將原始問題分為兩部分。 可以在此處找到問題的第二部分: 物理分區在 Cosmos DB 中的邏輯分區之間拆分的可用吞吐量如何? .

一些答案。

  1. 如果你配置一個 20K RU/s 的新容器,Cosmos 實際上會創建 3 個分區。 但是,如果您從較少開始,例如 5K RU,然后按比例放大它將創建 1 個分區,然后增加到 2 個分區。 造成差異的原因是我們試圖減少初始分區拆分的數量,因為用戶傾向於在初始配置期間攝取數據,通常伴隨着吞吐量的額外增加。 為了減少分區拆分的數量,我們以大約 10K RU/s 的 60% 配置了一個物理分區。 但是,我們並沒有普遍應用這 60%,因為它很浪費。 這只是我們在初始配置期間根據觀察到的用戶模式進行的優化。 這也是您應該關心物理分區而是關注邏輯分區鍵的眾多原因之一。 這里的 60% 是一個實現細節,可以隨時更改。

  2. 是的。

  3. 還沒有,但即將到來。 沒有預計到達時間。

吞吐量總是均勻分布的,所以是的,18K 分布在 3 個分區中,每個分區將獲得 6K RU/s。

是基於邏輯分區占用的空間還是基於所有邏輯分區消耗的吞吐量

物理分區的拆分基於提供的吞吐量以及單個分區上消耗的存儲。 Cosmos 何時創建新物理分區的示例

  1. 如果您配置 6000RU/s 的數據庫並攝取 60GB 的數據。
  2. 您配置 15000RU/s 的數據庫並攝取 10GB 的數據。 您可以將物理分區想象成一台最大可以處理 50GB 存儲和 10K RU/s 的計算機。 除此之外的任何事情都會導致分裂。 數據庫吞吐量在物理分區而不是邏輯分區之間平均分配。

從文檔來看,邏輯分區的大小或利用率似乎並不重要,我可以讓一些邏輯分區獲得比其他分區更多的請求,但只要我不超過物理分區的可用吞吐量,我應該沒問題。 這個對嗎?

這是真的。 邏輯分區大小確實很重要,這意味着它不能超過 20GB。 利用率也限制在 10K RU/s。 我們無法控制如何將邏輯分區拆分為物理分區,因此您無法真正知道您的邏輯分區位於哪個物理分區。同樣,無法確保您不超過 10K物理分區的吞吐量。 這就是為什么 MS 建議您選擇分區鍵以便適當平衡利用率的原因。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM