Блог

У меня возникли некоторые проблемы с оптимизацией DynamoDB. Я считаю, что мне не нужно показывать здесь какой-либо код, поэтому я просто задаю свой вопрос,

У моих элементов есть атрибут «список». Что мне нужно сделать, это повторить эту таблицу, добавить новые значения в атрибут списка каждого элемента. Поскольку каждая операция обновления отличается друг от друга, для этой операции требуется много единиц записи. Чтобы уменьшить это, я группирую элементы по 25 и обновляю их с помощью TransactionWriteItem. Я не мог точно сравнить значения, но чувствовал, что это не имеет никакого эффекта.

У меня также есть еще один вопрос: если мои данные составляют 100 байт (меньше 4 КБ), будет ли какая-то разница, если я их заархивирую? Я имею в виду, есть ли разница между 100 байтами и 10 байтами с точки зрения потребляемых единиц записи? Спасибо.

API транзакций не предназначен для ускорения работы или использования меньшей емкости: он предназначен для разрешения атомарных операций с несколькими элементами (это означает, что либо все обновления завершаются успешно, либо все завершаются неудачей, как единое целое).

Сравните это с выполнением 25 обновлений самостоятельно или с использованием API BatchWriteItem — в этих случаях некоторые обновления могут завершиться неудачей, в то время как другие будут успешными. Или все они могут быть успешными, но при обновлении ваших элементов могут произойти другие чтения, что приведет к противоречивым представлениям о ваших данных.

Итак, чтобы лучше понять потребляемую емкость записи, это выглядит следующим образом: любой обновляемый элемент (включая создание нового, удаление существующего или обновление существующего) будет потреблять не менее 1 единицы емкости. Обновление элемента не может использовать дробные единицы емкости (т.Е. если ваши обновления действительно крошечные). Но одно обновление элемента может потреблять более 1 WCU, если элемент больше 1 КБ.

Таким образом, сжатие ваших элементов окупается, если они большие (er), чем 1 КБ.

На самом деле, даже если размер меньше 1 КБ, стоит стремиться к небольшим элементам, потому что в отличие от операций записи, которые всегда занимают не менее 1 КБ, при запросе или сканировании потребляемая емкость вычисляется для совокупной суммы возвращенных результатов запроса или сканирования. Например, если ваш запрос извлекает 10 элементов, и каждый элемент равен 200B, вам будет начислен только 1 RCU; но если тот же запрос возвращает 10 элементов, и каждый элемент равен 1 КБ, тогда вы потребите 3RCU (10 КБ / 4 КБ = 2,5, округлено до 3)