Как бороться с предельным размером при достижении AWS DynamoDB? - PullRequest
Новая
       31

Как бороться с предельным размером при достижении AWS DynamoDB?

0 голосов
/ 27 марта 2019

Мы пытаемся использовать огромное преимущество AWS * DynamoDB '* NoSQL с IoT , но мы не уверены в том, какие передовые практики касаются длины элемента или вставки элемента.

Идет процесс, каждое устройство может читать данные среды, в зависимости от типа захваченных данных,устройство отправляет это "событие" JSON сообщение на IoT брокер , а затем на Lambda функцию для сопоставления этой полезной нагрузки,обработайте его и запишите в DynamoDB таблицу.

Затем существует одна таблица для каждого типа захваченного события и элемент для каждого сообщения о событии, полученного от устройств.Но мы осознали, что это просто еще один псевдо-реляционный подход.

Прочитайте документы и подумайте только об одной таблице как о лучшей практике, и об одном элементе на устройство, растущем внутри, с массивомэти JSON события, классифицируемые по имени ключа.

Что-то вроде: 

    {
        "partition":"<str_an_id>"",
        "range":<uint_maybe_a_timestamp>,
        "event_soil":[
            {<<object with variable length #0},
            {<<object with variable length #1}
            ...
            {<<object with variable length #n}
        ],
        "event_humidity":[
            {<<object with variable length #0},
            {<<object with variable length #1}
            ...
            {<<object with variable length #n}
        ],
        "event_light":[
            {<<object with variable length #0},
            {<<object with variable length #1}
            ...
            {<<object with variable length #n}
        ],
        "event_temperature":[
            {<<object with variable length #0},
            {<<object with variable length #1}
            ...
            {<<object with variable length #n}
        ]
    }

В настоящее время у нас есть два устройства, поэтому мы ожидаем, что два элемента будут расти вместе с JSONполезная нагрузка от устройств.Но в какой-то момент порог памяти достигнут, и код ошибки 400 из DynamoDB повышается.

Правильный ли этот подход?Или совершенно не так?

Есть ли какой-нибудь подход к тому, чтобы узнать, когда достичь этого предела?Например, какая-то нумерация страниц или что-то в этом роде?

Трудно привести математику вычисления размера элемента, потому что JSON объекты в настоящее время различаются по длине и могут измениться в будущем.

Такжемы начали думать о создании элементов каждые один или два месяца (теоретически, так как мы ускоряем устройства) для каждого устройства.Но не уверен.

1 Ответ

2 голосов
/ 27 марта 2019

и один элемент на устройство, растущее внутри, с массивом событий JSON, классифицированных по имени ключа.

Если я понимаю выше, и пример кода ...

Я бы сказал, что вы все делаете неправильно. Повторное обновление нескольких записей не очень хорошая идея. Помимо нехватки места в элементе, который вы, кажется, узнаете, вам придется платить за вдвое больше необходимых операций ввода-вывода (1 чтение + 1 запись). Не уверен, откуда вы взяли идею ...

Для устройств IoT кажется, что вы имеете дело с данными временных рядов, поэтому обязательно поймите Рекомендации по обработке данных временных рядов в DynamoDB

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

Моим первым проходом будет ключ раздела: "имя_устройства # дата", ключ сортировки: "время"

«дата» в этом случае может быть полной датой, ГГГГ-ММ-ДД, или просто ГГГГ-ММ, или даже ГГГГ. Перемещение левой части даты к ключу сортировки. Все зависит от того, сколько данных вы ожидаете. Следует учитывать, что данный раздел (ключ) может хранить только 10 ГБ данных.

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

Редактировать
Ключевые моменты

  1. Понять, сколько данных будет сгенерировано (записано)
  2. Понять, как ваше приложение представит эти данные пользователю (-ам)
  3. Раздел обеспечивает 10 ГБ хранилища данных и 3000 RCU / 1000 WCU
  4. Вы можете только запросить () данный раздел. (PartitionKey == "Что-то")

2 действительно важно, предполагая, что вы выбираете заданный период (последние 24 часа, последняя неделя и т. Д.), Когда вы собираетесь работать со всеми событиями для данного устройства, всеми событиями определенного типа, всеми событиями для всех устройств, или ....

Не то, чтобы вы не могли сделать все вышеперечисленное, но каков основной доступ?

"Дайте мне все данные за все время" каждый раз будет Scan () ... конечно, не экономически эффективным методом доступа.

...