Azure Cosmos DB 的重寫分區鍵策略

Question

我們在生產中使用 CosmosDB 來存儲 HTTP 請求/響應審計數據。 這些數據的結構一般如下：

{
    "id": "5ff4c51d3a7a47c0b5697520ae024769",
    "Timestamp": "2019-06-27T10:08:03.2123924+00:00",
    "Source": "Microservice",
    "Origin": "Client",
    "User": "SOME-USER",
    "Uri": "GET /some/url",
    "NormalizedUri": "GET /SOME/URL",
    "UserAgent": "okhttp/3.10.0",
    "Client": "0.XX.0-ssffgg;8.1.0;samsung;SM-G390F",
    "ClientAppVersion": "XX-ssffgg",
    "ClientAndroidVersion": "8.1.0",
    "ClientManufacturer": "samsung",
    "ClientModel": "SM-G390F",
    "ResponseCode": "OK",
    "TrackingId": "739f22d01987470591556468213651e9",
    "Response": "[ REDACTED ],   <— Usually quite long (thousands of chars)
    "PartitionKey": 45,
    "InstanceVersion": 1,
    "_rid": "TIFzALOuulIEAAAAAACACA==",
    "_self": "dbs/TIFzAA==/colls/TIFzALOuulI=/docs/TIFzALOuulIEAAAAAACACA==/",
    "_etag": "\"0d00c779-0000-0d00-0000-5d1495830000\"",
    "_attachments": "attachments/",
    "_ts": 1561630083
}

我們目前每天編寫大約 150,000 - 200,000 個與上述類似的文檔，其中/PartitionKey作為在容器上配置的分區鍵路徑。 PartitionKey 的值是 C#.net 中隨機生成的一個介於 0 到 999 之間的數字。

但是，我們看到每日熱點，其中單個物理分區的最大值可以達到 2.5K - 4.5K RU/s，而其他的則非常低（大約 200 RU/s）。 這會影響成本，因為我們需要為最大的使用分區提供吞吐量。

第二個因素是我們存儲了相當多的數據，接近 1TB 的文檔，我們每天增加幾 GB。 因此，我們目前有大約 40 個物理分區。

結合這兩個因素意味着我們最終必須至少提供 120,000 - 184,000 RU/s 之間的某個地方。

我應該提一下，我們幾乎不需要查詢這些數據； 除了在 Cosmos 數據瀏覽器中非常偶然的臨時手動構造查詢。

我的問題是……通過簡單地使用“id”列作為我們的分區鍵（或隨機生成的 GUID），然后設置一個合理的 TTL，我們會在需要的 RU/s 和數據分布方面做得更好嗎？所以我們沒有不斷增長的數據集？

我知道這需要我們重新創建集合。

非常感謝。

每個物理分區的最大吞吐量

Answer 1

雖然使用 id 或 GUID 會為您提供比您今天擁有的隨機數更好的基數，但您運行的任何查詢都將非常昂貴，因為它總是跨分區並且需要處理大量數據。

我認為更好的選擇是使用一個合成鍵，它結合了多個屬性，這些屬性既具有高基數，又用於查詢數據。 可以在此處了解有關這些的更多信息， https://docs.microsoft.com/en-us/azure/cosmos-db/synthetic-partition-keys

至於 TTL，我肯定會為您需要的數據保留設置它。 Cosmos 將使用未使用的吞吐量對數據進行 TTL 處理，因此永遠不會妨礙。

最后，您還應該考慮（如果您還沒有）使用自定義索引策略並排除任何從未查詢過的路徑。 特別是“響應”屬性，因為您說它有數千個字符長。 這可以在像您這樣的大量寫入場景中節省大量 RU/s。

Answer 2

根據我的經驗，我看到宇宙會隨着新數據而退化。 更多的數據意味着更多的物理分區。 因此，您需要將更多的吞吐量分配給它們中的每一個。 目前我們開始將舊數據歸檔到 blob 存儲中，以避免此類問題並保持物理分區的數量不變。 我們使用 cosmos 作為熱存儲，然后舊數據進入 blob 存儲作為冷存儲。 我們減少了分配給每個物理分區的 RU，從而節省了資金。