Единицы записи емкости, предоставленные DynamoDB, слишком часто и неожиданно превышаются

Question

Мне кажется, я понимаю единицы емкости записи / чтения, как они работают и рассчитываются в DynamoDB.Доказательством этого является то, что я полностью понимаю эту статью, а также документацию aws .Тем не менее, я испытываю непредвиденное поведение при записи элементов в мою таблицу.

У меня есть таблица DynamoDB со следующими настройками.В частности, 5 единиц емкости записи / чтения

Я помещаю в эту таблицу показания датчиков, подключенных к Raspberry Pi, которые я получаю и отправляю с помощью python2.7 в «Динамо» с мой сценарий .

Этот элемент наверняка меньше 1 КБ.Они выглядят следующим образом:

{
    "reading_id": "<current_time>",
    "sensor_id": "<SENSORS_IDS[i]>",
    "humidity": "<humidity>",
    "temperature": "<temperature>"
}

Мой сценарий выполняет итерацию по датчикам, считывает данные с одного и отправляет показания / данные датчика в DynamoDB с table.put_item каждые 5 секунд.То есть, если считывание с датчиков прошло успешно, в противном случае произойдет произвольное ожидание 30 с.

Теперь, согласно моим расчетам, я пишу элементу DynamoDB объемом 1 КБ каждые 5 секунд, что должно быть хорошо, так как моя таблица настроенас 5WCU = (5items * 1KB) / Вторая скорость записи.

Итак, мои вопросы:

1 .Как получается, что эта небольшая нагрузка (если происходит так, как я полагаю, происходит) превышает мои 5 WCU, как показано здесь ?:

2 .Я работаю с этой настройкой без изменений около года (бесплатный уровень заканчивается 30 сентября 2018 года).Как это так, он начал меняться несколько месяцев назад, еще до того, как закончился уровень бесплатного пользования, как показано здесь:

Мой единственный подозреваемый до сих пор - time.sleep(), поскольку в документации сказано:

time.sleep (secs)

Приостановить выполнение текущего потока на указанное количество секунд.Аргумент может быть числом с плавающей запятой, чтобы указать более точное время сна.Фактическое время приостановки может быть меньше запрошенного, потому что любой перехваченный сигнал прервет режим сна () после выполнения процедуры перехвата этого сигнала.Кроме того, время приостановки может быть больше, чем запрошено на произвольную величину из-за планирования других действий в системе.

Я не очень знаком с python, что заставляет меня думать, что это может быть что-тов моем коде.Это не объясняет тот факт, что у меня не было этой проблемы ранее в этом году.

Кто-нибудь имеет какое-либо представление об ответах на вопросы выше или где я должен исследовать эту проблемув дальнейшем?

Примечание: Я искал в Google и другие связанные вопросы здесь.Похоже, что никто не относится к моему делу.

Спасибо.

Answer 1

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

Когда вы предоставляете таблицу с 5 WCU, это означает, что вы можете записать только до 5 элементов размером 1 КБ каждый секунду.Фактически, это дает вам в общей сложности до 300 WCU, которые вы могли бы использовать в каждую минуту.

Так что, если вы видите точки данных 6 или около того, это вполне нормально.

Следует отметить, что сумма подготовленной пропускной способности записи (оранжевая линия) на самом деле не является суммой.Это кажется ошибкой в ​​CloudWatch: вместо этого указывается пропускная способность в секунду.

Небольшое замечание: вы показываете 5-6 единиц в минуту, что означает, что вы на самом деле спите ближе к 10 секундаммежду записями, а не 5.

Наконец, с «Динамо» вы платите за резервируемую емкость, а не за потребляемую.Поэтому до тех пор, пока ваш стол не будет ограничен, даже если вы немного превысите выделенную емкость (которую в некоторых случаях допускает «Динамо»), с вас не будет взиматься дополнительная плата.

Answer 2

Возможно, ваша таблица была разбита неравномерно.Возможно, вы захотите прочитать о разделах DynamoDB и распределении данных .