Как избежать горячих разделов при использовании контроля доступа на уровне строк DyanmoDB?

Question

Я смотрю на добавление разрешений на уровне строк к таблице DynamoDB, используя dynamodb:LeadingKeys для ограничения доступа по идентификатору провайдера.В настоящее время у меня есть только один идентификатор провайдера, но я знаю, что у меня будет больше.Однако их поставщики будут различаться по размеру, причем эти размеры будут очень несбалансированными.

Если я использую идентификатор провайдера в качестве ключа раздела, мне кажется, что моя БД будет иметь очень горячие разделы для крупных поставщиков и в основном неиспользуемые разделы для более мелких поставщиков.До добавления контроля доступа на уровне строк я использовал deviceId в качестве ключа раздела, так как это более случайное имя, поэтому разделы хорошо, но теперь я думаю, что мне нужно перенести это на ключ сортировки.

Текущее разделение, которое работает хорошо:

HASHKEY: DeviceId

С разрешениями я думаю, что мне нужно перейти к:

HASHKEY: ProviderID (only a handful of them)
RangeKey: DeviceId

Любые предложения относительно лучшего способа установить этодо

Answer 1

Расширение комментария Майкла ...

Если вам не нужен ключ диапазона сейчас ... зачем добавлять его?

Единственная причина иметь ключ диапазона - это то, что вынеобходимо Query DDB и вернуть несколько записей.

Если все, что вам когда-либо понадобится, это отдельная запись, использующая GetItem, то вам не нужна клавиша диапазона.

Просто объедините ${ProviderId}.${DeviceId} вместе, чтобы составить свой хэш-ключ.

Редактировать
Поскольку вы хотите иметь возможность перечислять идентификаторы устройств для одного поставщика,тогда вам нужен идентификатор провайдера в качестве ключа раздела и идентификатор устройства в качестве ключа диапазона.

Как отмечается в ответе Айсхорна, «горячие разделы» не так важны, как раньше.Если только вы не ожидаете, что данные для одного идентификатора провайдера превысят 10 ГБ, я бы начал с простой реализации hashKey (providerID).

Если вы ожидаете более 10 ГБ данных или в результате вы получаете горячийраздел ... затем рассмотрите конкатенацию (1..n) целого числа с идентификатором провайдера.

Это будет означать, что вам придется запросить несколько разделов, чтобы получить все идентификаторы устройств.

Этот подходподробно изложено в Многопользовательские стратегии хранения SaaS

Answer 2

Как правило, вам больше не нужно беспокоиться о горячих разделах в DynamoDB, особенно если ключи разделов, которые запрашиваются чаще всего, остаются относительно постоянными.

Дополнительная информация: https://aws.amazon.com/blogs/database/how-amazon-dynamodb-adaptive-capacity-accommodates-uneven-data-access-patterns-or-why-what-you-know-about-dynamodb-might-be-outdated/