Стоимость и масштабирование Dynamodb по требованию в горячем разделе (адаптивное масштабирование) - PullRequest
0 голосов
/ 20 февраля 2020

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

При оценке OnDemand учитывается только сумма WRU, используемая каждым разделом, или общая WRU для таблицы на основе шаблон использования, который будет использоваться каждым разделом.

при наличии горячего раздела OnDemand увеличивает WRU только для этого раздела или увеличивает общий WRU таблицы.

работает адаптивная емкость с БД OnDemand

Например: БД OnDemand с 10 разделами и текущим пиком в 1000WRU. если двум горячим перегородкам потребуется более 300WRU, будет ли он использовать адаптивную емкость или увеличит общую WRU до 3000WRU, что приведет к высокой стоимости?

1 Ответ

0 голосов
/ 20 февраля 2020

Я не инсайдер из DynamoDB, поэтому могу отвечать только из того, что я понимаю из их документации.

В ценообразовании по требованию (см. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html#HowItWorks .OnDemand ) вы платить точно по количеству и размеру ваших запросов. Если вы сделаете миллион запросов, вы будете платить одинаково, независимо от того, были ли эти запросы миллиону разных разделов, или все они были в одном и том же разделе.

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

На подготовленной странице ценообразования Amazon заявляет, что если вы зарезервируете 1000 WCU, вы сможете использовать это количество единиц записи, за которые вы заплатили, в секунду, и если вы попытаетесь использовать больше, вы будете душить. Нет никаких упоминаний или предупреждений о несбалансированных нагрузках или горячих разделах ... Но люди обнаружили, что это не совсем так - у Amazon была ошибка в их коде регулирования: подсчет использования не был выполнен по всему весь кластер. Вместо этого, если ваши данные распределены по 10 узлам, резервирование 1000 будет равномерно распределено между ними, поэтому каждый из 10 узлов начнет ограничивать вас после 100 (1000/10) запросов в секунду. Это разделение работало хорошо для хорошо сбалансированных нагрузок, но с горячими перегородками оно не работало хорошо. Люди платили за бронирование 1000, но когда они измерили, сколько они получают, они увидели удушение после 800 (например) запросов в секунду. Amazon признал, что это была ошибка, и исправил ее с помощью своей техники «адаптивной емкости», когда каждый из узлов выбирает разные ограничения регулирования, изменяемые до тех пор, пока общее использование пользователя не приблизится к тому, за что он заплатил. Эта техника объясняется в этом превосходном официальном выступлении https://www.youtube.com/watch?v=yvBR71D0nAQ - см. Время 19:38. До недавнего времени эта «адаптивная способность» была очень тупым инструментом, который хорошо работал, только если ваша рабочая нагрузка не меняется быстро, но с тех пор эта проблема также была исправлена ​​- как описано в
https://aws.amazon.com/blogs/database/how-amazon-dynamodb-adaptive-capacity-accommodates-uneven-data-access-patterns-or-why-what-you-know-about-dynamodb-might-be-outdated/

...