2016-03-29 2 views
1

Мы используем Couchbase около двух лет, но мы, наконец, решили переключиться на сервис Amazon DynamoDB по многим причинам.
Теперь я начал миграцию данных в dynamodb. Во-первых, все было в порядке и пошло так, как ожидалось, но через некоторое время время отклика от динамома становится все выше и выше, и процесс миграции постепенно замедляется.
Я попытался изменить свои стратегии, но не повезло.
Что я могу сделать, чтобы увеличить время отклика?Улучшение времени отклика AWS Dynamodb

В основном я просматриваю таблицу SQL, получая по 100 элементов на запрос, а затем запрашивая Couchbase для получения данных, которые я хочу об этих 100 элементах. Сначала я получал большое время отклика (как показано на рисунке ниже).

Следующая информация может помочь:

  • Я бегу код миграции на сервере ec2 микро работает Ubuntu 14,04 с узлом V 4.4.1.
  • Посмотрев на графики, я начал измерять время для каждого запроса dynamodb (так что я не знаю, что среднее изначально было), среднее время отклика составляет 800 мс для примерно 150 000 запросов (получите только &, нет командных команд или запросов)
  • Я сохраняю элементы в двух таблицах один с целым хеш-ключом, а другой - с целыми хэшами и ключами сортировки
  • Вторая таблица является огромной (имеет около 4,4 миллиона элементов и считая)

An image shows how the consumed capacity decreased overtime

+0

Вы "сканируете таблицу SQL"? Но вы только перечислите Couchbase и DynamoDB, которые не являются базами данных SQL. Вы хотите сказать, что вы выполняете полное сканирование таблицы DynamoDB? Мне кажется, что вся ваша проблема просто связана с тем, что пропускная способность на DynamoDB слишком низкая. Ваши заданные параметры пропускной способности, вероятно, являются самой важной информацией, связанной с этим вопросом, и вы не указали эту информацию. –

+0

Благодаря нашей системе мы используем Mysql и Couchbase вместе, в Mysql мы храним простые данные, но в Couchbase мы сохраняем весь объект json. Теперь мы хотим избавиться от couchbase и переместиться в Dynamodb. И как показано на прилагаемом изображении, пропускная способность для этой таблицы составляет 125 (красная горизонтальная линия), а потребляемая пропускная способность становится все ниже и ниже (она начиналась около 100, а затем уменьшалась до 20, а затем уменьшалась до 5). – Sami

+0

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

ответ

0

Благодаря @Vor для упоминания «Горячих ключей разделов» я сделал дальнейшие чтения и ссылался на Guidelines for Working with Tables. Я следовал тому, что они рекомендуют, а также распределял запросы в пакетных запросах.
Спасибо вам за помощь.

Смежные вопросы