DynamoDB batch_write был ограничен даже при высокой пропускной способности

В настоящее время у меня проблема с пропускной способностью записи DynamoDB. Я установил пропускную способность записи равной 10000, и у меня есть 6 процессов, которые запускают batch_write (количество сохраняемых записей: 500 миллионов +). Средняя потребляемая пропускная способность записи очень низкая (около 500), но я все равно получил регулирование записи, а среднее количество регулируемых запросов составляет 800 (все в масштабе 5 минут).

Мне интересно, почему это происходит и как этого избежать.

Спасибо!


person milodky    schedule 29.10.2014    source источник


Ответы (1)


Это могло произойти из-за разделения таблиц:

Как объяснено здесь, даже если вы предоставили определенную емкость записи для таблицы (или глобального вторичного индекса) фактический предел пропускной способности запросов может быть намного ниже. Как описано в здесь AWS, DynamoDB автоматически разделяет ваши таблицы за кулисами, и распределяет их выделенную емкость поровну между этими меньшими разделами.

Когда некоторые элементы запрашиваются очень часто, у них есть «горячие клавиши», создающие крайне неравномерную схему доступа. Когда таблицы становятся большими, они сильно секционируются. Например, если вы подготовили 1000 операций записи в секунду для определенной таблицы, и эта таблица фактически разделена на 10 разделов, то записи будут регулироваться в лучшем случае со скоростью 100 запросов в секунду, даже если выделенная пропускная способность других разделов не используется. много.

Это усложняет то, что консоль AWS не показывает количество разделов в таблице DynamoDB (даже если разделение хорошо задокументировано). Чтобы предотвратить регулирование горячих клавиш, вы можете оценить количество разделов, которые вы можете ожидать для таблицы, используя формулу, описанную в документации AWS. Затем вы можете рассчитать предел пропускной способности каждого раздела, разделив общую выделенную емкость записи на ожидаемое количество разделов.

Надеюсь, это поможет :)

person J.M.    schedule 24.09.2015