Резервное копирование только новых записей из DynamoDB в S3 и загрузка их в RedShift

Я видел, что подобные вопросы уже существуют:

Резервное копирование AWS Dynamodb на S3

Копирование только новых записей из AWS DynamoDB в AWS Redshift

Загрузка данных из Amazon DynamoDB в красное смещение

К сожалению, большинство из них устарели (поскольку Amazon представила новые услуги) и / или имеют разные ответы.

В моем случае у меня две базы данных (RedShift и DynamoDB), и я должен:

  • Регулярно обновляйте базу данных RedShift
  • Хранить резервную копию базы данных на S3

Для этого я хочу использовать этот подход:

  1. Резервное копирование только новых / измененных записей из DynamoDB в S3 в конце дня. (1 файл в день)
  2. Обновить базу данных RedShift, используя файл из S3

Итак, мой вопрос: как это сделать наиболее эффективно?

Я прочитал это руководство, но я не уверен, что AWS Data Pipeline можно настроить так, чтобы «ловить» только новые записи из DynamoDB. Если это невозможно, сканировать всю базу данных каждый раз нельзя.

Заранее спасибо!


amazon-web-services amazon-s3 amazon-dynamodb amazon-redshift amazon-data-pipeline
person bpavlov    schedule 22.03.2016    source источник

Ответы (1)


arrow_upward
3
arrow_downward

вы можете использовать Amazon Lambda с потоком Dynamodb (документация)

вы можете настроить свою лямбда-функцию для получения обновленных записей (из потока Dynamodb), а затем обновить базу данных красного смещения

person Eyal Ch    schedule 22.03.2016
comment
В этом примере они используют функцию Lambda, прикрепленную к DynamoDB Stream. Lambda вызывается при каждом изменении DynamoDB (вставка / изменение). Таким образом, я должен прочитать весь файл журнала из S3, а затем обновить его. Возможно, мне нужно запланировать выполнение Lambda только один раз в конце дня. - person bpavlov; 22.03.2016
comment
Я не понимаю, как использовать файл журнала s3. с лямбдой она вам не нужна - person Eyal Ch; 22.03.2016
comment
Я использую файл s3 в качестве резервной копии базы данных. Другая причина: COPY загружает большие объемы данных намного эффективнее, чем использование инструкций INSERT, а также сохраняет данные более эффективно. Также, если мне нужно восстановить некоторые данные, мне не нужно читать их снова из DynamoDb - person bpavlov; 22.03.2016
comment
да, поэтому в этом случае вы можете записывать в файл все обновления Dynamodb, а затем загружать его из s3 в Dynamodb - person Eyal Ch; 22.03.2016
comment
Да, это то, что я хочу. И я думал, что смогу добиться этого с помощью Data Pipeline. Но если других ответов нет - я должен написать лямбду (ы), которые это сделают. - person bpavlov; 22.03.2016
comment
@bpavlov Я до сих пор не понимаю, зачем вам нужно задействовать S3 во всем этом. В чем проблема запуска обновления RedShift для каждого обновления DynamoDB? - person Matias Cicero; 22.03.2016
comment
Если я чего-то не упускаю - согласно документации COPY более эффективен, чем оператор INSERT, и также более эффективно хранит данные. Но главная причина в том, что у меня была бы резервная копия базы данных на S3. Затем эти данные можно было бы перенести в Amazon Glacier и т. Д. - person bpavlov; 22.03.2016
comment
@EyalCh Я столкнулся с проблемой, описанной здесь: stackoverflow.com / questions / 31912168 /, пока я читаю ленту. NextShardIterator всегда НЕ равен нулю, поэтому я получаю бесконечный цикл. Как лучше всего подходить в этой ситуации? Я делал итерацию только в закрытых сегментах и ​​сохранял в журнале последний ShardId, но это совсем не хорошее решение. - person bpavlov; 13.06.2016
comment
Возможно, стоит открыть новую тему: stackoverflow.com/questions / 37814516 / - person bpavlov; 14.06.2016
comment
Просто чтобы ответить. В чем проблема запуска обновления RedShift для каждого обновления DynamoDB ?. Это не будет масштабироваться, поскольку одиночная вставка является операцией ведущего узла, что означает, что она станет узким местом по мере того, как вы обрабатываете больше данных. Настолько, что запись может занять много секунд, в зависимости от объема данных, в какой-то момент время записи начнет истекать вместе, так как ведущий узел оказывается захламленным в INSERTS. Только команда COPY может масштабироваться в течение длительного времени, поскольку она получает все узлы в кластере во вставляемых данных. - person phill.tomlinson; 17.11.2016