Устройства чтения и записи Dynamodb

Я читал различные статьи об Amazon DynamoDB, но я все еще немного запутался в блоках чтения/записи о том, как они используются. Например, используя бесплатную версию, у меня есть 5 единиц записи и 10 единиц считывания в секунду, каждый блок представляет 1kb данных. Но что это значит?

Означает ли это, что максимум 10 запросов на чтение могут выполняться за секунды или максимум 10 Кб данных можно запрашивать в секундах (независимо от того, есть ли 10 или 100 запросов)? Потому что этот аспект не ясен для меня. Итак, если у меня есть 20 пользователей, которые одновременно получают доступ к странице на моем веб-сайте (что приводит к 20 запросам, выполняемым для извлечения данных), что произойдет? Будут ли 10 из них сразу видеть данные, а остальные 10 - через 1 секунду? Или все они сразу видят данные, если запрашиваемые данные (умноженные на 20) меньше 10kb?

Кроме того, если блоков чтения недостаточно, и 100 пользователей запрашивают одновременно 1 кб данных каждый, означает ли это, что для всех запросов потребуется 10 секунд для завершения?

Кроме того, цена немного запутанна, поскольку я не понимаю, оплачиваются ли цены за зарезервированные или потребляемые единицы? Так, например, они говорят, что цена "Write Throughput: $0.00735 в час на каждые 10 единиц мощности записи". Означает ли это, что вы будете платить ($ 0,00735 * 24 = $0,176), даже если в течение дня не будут подаваться письменные запросы?

Ответ 1

Вы правы в том, что емкость жестко связана с размером считываемых/записанных объектов.

Февраль 2016 Обновления

AWS обновила способ расчета пропускной способности, и они увеличили с 1 КБ объектов до 4 КБ для своих вычислений. Нижеприведенное обсуждение остается в силе, но некоторые вычисления сейчас различны.

Всегда обращайтесь к последней документации DynamoDB для получения последней информации и примеров расчета пропускной способности.

Старая документация

Из документации AWS DynamoDB (по состоянию на 1/8/14):

Единицы емкости, необходимые для записи = Количество записей элементов за каждый второй размер элемента x (округленный до ближайшего КБ)

Единицы мощности, необходимые для чтения * = Количество прочитанных элементов за второй размер элемента x (округленный до ближайшего КБ)

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

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

Обратите внимание, что определяется требуемое количество единиц считываемой емкости по количеству элементов, считанных в секунду, а не количеству API звонки. Например, если вам нужно читать 500 единиц в секунду с вашего стол, а если ваши предметы составляют 1 КБ или меньше, то вам понадобится 500 единиц Читайте Емкость. Не имеет значения, если вы делаете 500 индивидуальных GetItem звонки или 50 вызовов BatchGetItem, каждый из которых возвращает 10 элементов.

Для вашего 20 пользовательского примера имейте в виду, что данные округляются до ближайшего КБ. Поэтому, даже если ваши 20 пользователей запросят 0,5 КБ данных, вам понадобится 20 модулей чтения для одновременного обслуживания всех них. Если у вас есть только 10 единиц чтения, тогда остальные 10 запросов будут дросселированы. Если вы используете библиотеки Amazon DynamoDB, у них есть логика автозапуска, испеченная, чтобы снова попробовать запрос, чтобы в конечном итоге их обслуживали.

Для вашего вопроса о 100 пользователях некоторые из этих запросов могут быть просто дросселированы, и логика повторения может в конечном итоге потерпеть неудачу (код будет повторять запрос столько раз, прежде чем он перестанет пытаться), поэтому вам нужно быть готовым к обработке эти 400 кодов ответа от DynamoDB и соответственно реагировать. Очень важно контролировать ваше приложение, когда вы используете DynamoDB, и убедитесь, что вы не будете дросселированы на критических транзакциях приложения.

Ваш последний вопрос о ценах - вы платите почасово за то, что вы резервируете. Если вы зарезервируете 1000 единиц чтения, и ваш сайт абсолютно не имеет трафика, то слишком плохо, вы по-прежнему будете платить почасово за 1000 единиц чтения.

Для полноты - имейте в виду, что пропускная способность - это обеспечение PER TABLE. Поэтому, если у вас есть три таблицы DynamoDB: "Пользователи", "Фотографии", "Друзья", вам необходимо предоставить емкость для каждой таблицы, и вам нужно определить, что подходит для каждой таблицы. В этом тривиальном примере, возможно, в вашем приложении менее часто обращаются к фотографиям, поэтому вы можете обеспечить меньшую пропускную способность по сравнению с таблицей ваших пользователей.

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

Ответ 2

Подумайте об этом как о диаметре трубы: вы платите за возможную пропускную способность данных в секунду. Количество запросов не имеет значения.

Кроме того, если вы попросите 10 единиц чтения, то вы действительно заплатите 10 единиц, независимо от вашего фактического трафика.

Если ваш трафик должен был превысить лимит, вы должны сначала получить предупреждение (скажем, на 80% вашего резервного прохода). Затем запросы начинают занимать больше времени. Если вы все еще превышаете лимит на значительное количество времени, на новые соединения можно отказаться в течение нескольких минут.

Надеюсь, что поможет

Ответ 3

• Добавляя и обновляя элементы, потребляющие вашу пропускную способность для записи, а запрашивающие/запрашивающие элементы потребляют вашу производительность чтения в dynamo db. Максимальный размер для одного элемента в таблице DynamoDB составляет 400 kb, чем больше ваши товары, тем больше пропускной способности вы потребляете и больше ваших затрат будет. Если вы выполняете поиск в DynamoDB с помощью ключа, сканирование таблицы не произойдет, и вам потребуется пропускная способность, эквивалентная размеру вашего элемента, например, если ваш размер элемента 4kb, тогда вам нужно 1 единица измерения чтения (1 единица эквивалентна 4 КБ/сек) если вы хотите читать 40 Кбайт данных в секунду, вам понадобится 10 Read Units. Неважно, если вы делаете 10 запросов на 4 КБ данных или если вы делаете один запрос для 40 КБ данных. Вы ограничены 40 КБ/с. Но если вы ищете отдельно от ключа, тогда DynamoDB сканирует полные данные из таблицы, в то время как сканирование db будет пересекать заданный предел пропускной способности, когда данные высоки в базе данных, мы можем увеличить пропускную способность таблицы до максимального значения, необходимого во время сканирования, но это увеличит и в большинстве случаев будет зависеть от базы данных.

Ответ 4

Пожалуйста, прочитайте эту статью, все детали есть:

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ProvisionedThroughput.html#ItemSizeCalculations.Reads

Как правило, вы платите за каждый элемент, где размер каждого элемента округляется до следующих 1 КБ /4 КБ для операций записи/чтения.

Единственное исключение для этого правила - когда вы выполняете запрос/сканируете вызовы:

Все возвращаемые элементы обрабатываются как одна операция чтения, где DynamoDB вычисляет общий размер всех элементов, а затем округляет до следующей границы в 4 КБ. Если запрос возвращает 1500 элементов по 64 байта каждый, совокупный размер составляет 96 КБ.