Надежность атомных счетчиков в DynamoDB - PullRequest
26 голосов
/ 21 февраля 2012

Я собирался использовать Amazon DynamoDB в своем приложении, и у меня возник вопрос относительно надежности атомных счетчиков .

Я создаю распределенное приложение, которое должно одновременно и последовательно , увеличивать / уменьшать счетчик, хранящийся в атрибуте «Динамо». Мне было интересно, насколько надежен атомный счетчик «Динамо» в тяжелой параллельной среде, где уровень параллелизма чрезвычайно высок (скажем, например, средняя скорость одновременных обращений 20 тыс. - чтобы понять, что это будет увеличение почти на 52 млрд. / уменьшений в месяц).

Счетчик должен быть сверхнадежным и никогда не пропустить удар. Кто-нибудь тестировал DynamoDB в таких критических средах?

Спасибо

Ответы [ 3 ]

18 голосов
/ 23 февраля 2012

DynamoDB получает свои свойства масштабирования, распределяя ключи между несколькими серверами.Это похоже на то, как масштабируются другие распределенные базы данных, такие как Cassandra и HBase.В то время как вы можете увеличить пропускную способность на DynamoDB, которая просто перемещает ваши данные на несколько серверов, и теперь каждый сервер может обрабатывать общее количество одновременных подключений / количество серверов.Взгляните на их часто задаваемые вопросы для объяснения того, как достичь максимальной пропускной способности:

В: Всегда ли я смогу достичь своего уровня подготовленной пропускной способности?

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

При хранении данных Amazon DynamoDB делит таблицу на несколько разделов и распределяет данные на основе хешаключевой элемент первичного ключа.Предоставленная пропускная способность, связанная с таблицей, также делится между разделами;Пропускная способность каждого раздела управляется независимо на основе выделенной ему квоты.Нет разделения выделенной пропускной способности между разделами.Следовательно, таблица в Amazon DynamoDB лучше всего может соответствовать выделенным уровням пропускной способности, если рабочая нагрузка распределена довольно равномерно по значениям хеш-ключа.Распределение запросов по значениям хеш-ключей распределяет запросы по разделам, что помогает достичь уровня полной предоставляемой пропускной способности.

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

Это означает, что наличие одного ключа, который увеличивается напрямую, не будетмасштаб, так как этот ключ должен жить на одном сервере.Существуют и другие способы решения этой проблемы, например, при агрегации памяти с инкрементом сброса в DynamoDB (хотя это может привести к проблемам с надежностью) или счетчиком с разделением на сегменты, где приращения распределяются по нескольким ключам и считываются путем вытягивания всех ключей из сегментированногосчетчик (http://whynosql.com/scaling-distributed-counters/).

8 голосов
/ 24 февраля 2012

В дополнение к ответу gigq о масштабируемости атомные приращения DynamoDB не являются идемпотентными и, следовательно, ненадежными: если соединение разорвано после выдачи запроса UpdateItem ADD, у вас нет возможности узнать, было ли добавление зафиксировано илинет, поэтому вы не знаете, следует ли вам повторить попытку или нет.

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

1 голос
/ 21 марта 2018

Если вы собираетесь написать один ключ динамо-базы данных, вы будете страдать от проблемы hot partition . Горячая проблема раздела начинается около 300 TPS на индекс. Таким образом, если у вас есть 5 индексов в таблице, вы можете увидеть проблему с горячим разделом около 300/5 ~ 60 TPS.

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

...