Конструкция ключа раздела Dynamo DB: несколько отдельных ключей раздела, но всегда уникальный ключ сортировки - PullRequest
0 голосов
/ 31 января 2019

Я новичок в DynamoDB и изо всех сил пытаюсь создать хороший ключ раздела.Я читал, что хороший DynamoDB использует ключ раздела с почти различными значениями.Тем не менее, я подумал, смогу ли я использовать DynamoDB только с ~ 10 (разными) значениями для ключа раздела, если я всегда могу использовать ключ сортировки в качестве уникального идентификатора (например, не начинается с).Буду ли я сталкиваться с проблемами с этим подходом?

Мои проблемы (ы) выглядит так:

1.Допустим, я хочу визуализировать комнаты в нескольких домах .В каждой комнате есть устройства IoT, которые должны быть видны в виде «карты комнаты». Визуализация выполняется и хранится в формате json локально на данный момент.Я хочу сохранить эту конфигурацию в DynamoDB.Мой ключ раздела будет дома , а ключ сортировки будет префиксом с roomMap_, за которым следует имя комнаты (разумеется, уникальное для ключа раздела)

| partition key | sort key            | room map json |
|---------------|---------------------|---------------|
|        House1 | roomMap_livingRoom1 |         {...} |
|        House1 | roomMap_livingRoom2 |         {...} |
|        House1 | roomMap_kitchen     |         {...} |
|        House2 | roomMap_livingRoom1 |         {...} |

2.Теперь я также хочу хранить информационные панели для устройств IoT в DynamoDB. Идентификаторы устройств уникальны для дома (по дизайну), но могут быть такими же в других домах .Например, устройство 'fridgeSensor' может существовать более чем в 1 доме.Конфигурация приборной панели также сохраняется как json.

| partition key              | dashboard config json |
|----------------------------|-----------------------|
| House1::fridgeSensor       |                 {...} |
| House1::temperatureSensor1 |                 {...} |
| House2::fridgeSensor       |                 {...} |

Когда я читал, что в хорошем дизайне DynamoDB используется только 1 таблица Я подумал о следующей таблице, используя PartitionKey первого дизайна таблицы, и адаптировал ключ сортировки:

| partition key | sort key            | room map json | dashboard config json |
|---------------|---------------------|---------------|-----------------------|
|        House1 | roomMap_livingRoom1 |         {...} | null            
|        House1 | roomMap_livingRoom2 |         {...} | null
|        House1 | roomMap_kitchen     |         {...} | null
|        House2 | roomMap_livingRoom1 |         {...} | null
|        House1 | device_fridgeSensor |          null | {...}
|        House2 | device_fridgeSensor |          null | {...}

Теперь я часто читаю один и тот же ключ раздела. Это плохой дизайн? И если да, как я могу сделать лучше?

1 Ответ

0 голосов
/ 31 января 2019

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

Например, каждый ключ раздела ограничен одним разделом хранилища (отсюда и название) с максимальным размером 10 ГБ.Это означает, что у вас возникнут проблемы, если у определенного ключа есть, например, много ключей сортировки, в результате чего ему требуется более 10 ГБ памяти.

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html

Кроме того, если у вас есть только несколько ключей разделов, и один из них очень популярен и поэтому называется много, у вас есть «горячий» раздел.А поскольку ваши возможности чтения / записи распределяются равномерно по всем вашим разделам, вы либо заплатите слишком много (если вы установите достаточно высокий уровень чтения / записи, предоставив горячему разделу достаточно R / W, а другим слишком много), либополучить душу

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-uniform-load.html

Обратите внимание, что в нескольких случаях, таких как re: Invent 2018, AWS сказал, что они автоматически пытаются компенсировать горячие разделы без каких-либо дополнительных затрат.к клиенту.Но не рассчитывайте на это слишком много.

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html#bp-partition-key-throughput-bursting

В вашем случае, однако, я действительно не вижу проблемы, если в одном доме не будет тысяч устройств / комнатили если данные для одного или нескольких домов чрезвычайно популярны.

Следует обратить внимание на размер файлов json (карта комнаты, конфигурация панели мониторинга).Если эти файлы становятся слишком большими, обычный подход в AWS - сохранить их в S3 и добавить их местоположение / идентификатор в DynamoDB.В этом случае, если вам нужны эти файлы, вы получаете идентификатор и переходите к S3, чтобы найти его.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...