Стратегия с разделением ключей для записи на Azure Cosmos DB - PullRequest
Новая
       39

Стратегия с разделением ключей для записи на Azure Cosmos DB

1 голос
/ 05 февраля 2020

Мы используем 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,5. K RU / s и другие очень низкие (около 200 RU / с). Это влияет на стоимость, так как нам необходимо обеспечить пропускную способность для нашего самого большого используемого раздела.

Второй фактор заключается в том, что мы храним довольно много данных, около 1 ТБ документов, и добавляем несколько ГБ каждый день. В результате в настоящее время у нас имеется около 40 физических разделов.

Сочетание этих двух факторов означает, что нам в конечном итоге придется обеспечить как минимум где-то между 120 000 - 184 000 RU / с.

Я должен упомянуть что нам едва нужно запрашивать эти данные; кроме очень случайных для ad-ho c запросов, созданных вручную в проводнике данных Cosmos.

Мой вопрос: ... мы были бы намного лучше с точки зрения требуемых RU / s и распределения данных просто используя столбец «id» в качестве ключа раздела (или случайно сгенерированный GUID) - и затем устанавливая разумный TTL, чтобы у нас не было постоянно растущего набора данных?

Я понимаю, что это потребовало бы от нас -создание коллекции.

Большое спасибо.

Максимальная пропускная способность на физический раздел

1 Ответ

0 голосов
/ 05 февраля 2020

Хотя использование идентификатора или идентификатора GUID даст вам большую мощность, чем случайное число, которое вы используете сегодня, любой выполняемый вами запрос будет очень дорогим, поскольку он всегда будет кросс-секционным и содержит огромное количество данных.

Я думаю, что лучшим выбором было бы использование синтетического ключа c, который сочетает в себе несколько свойств, которые оба имеют большую мощность, а также используются для запроса данных. Подробнее об этом можно узнать здесь: https://docs.microsoft.com/en-us/azure/cosmos-db/synthetic-partition-keys

Что касается TTL, я бы определенно установил это для любого хранения этих данных. Cosmos отключит данные TTL с неиспользованной пропускной способностью, поэтому никогда не будет мешать.

Наконец, вам также следует рассмотреть (если вы этого еще не сделали) использование собственной политики индексации и исключить любые пути, которые никогда не запрашиваются. за. Особенно свойство «response», так как вы говорите, что это тысячи символов. Это может сэкономить значительные RU / s в сценарии с интенсивной записью ios, как у вас.

...