Скопируйте таблицу dynamoDB в другую учетную запись aws без S3

Ответ 1

Если вы не возражаете использовать Python и добавляете библиотеку boto3 (sudo python -m pip install boto3), то я бы сделал это так (я полагаю, вы знаете, как заполнять ключи, регионы и имена таблиц в коде соответственно ):

import boto3
import os

dynamoclient = boto3.client('dynamodb', region_name='eu-west-1',
    aws_access_key_id='ACCESS_KEY_SOURCE',
    aws_secret_access_key='SECRET_KEY_SOURCE')

dynamotargetclient = boto3.client('dynamodb', region_name='us-west-1',
    aws_access_key_id='ACCESS_KEY_TARGET',
    aws_secret_access_key='SECRET_KEY_TARGET')

dynamopaginator = dynamoclient.get_paginator('scan')
tabname='SOURCE_TABLE_NAME'
targettabname='TARGET_TABLE_NAME'
dynamoresponse = dynamopaginator.paginate(
    TableName=tabname,
    Select='ALL_ATTRIBUTES',
    ReturnConsumedCapacity='NONE',
    ConsistentRead=True
)
for page in dynamoresponse:
    for item in page['Items']:
        dynamotargetclient.put_item(
            TableName=targettabname,
            Item=item
        )

Ответ 2

Попробуйте этот модуль nodejs

npm i copy-dynamodb-table

Ответ 3

Простое резервное копирование и восстановление для Amazon DynamoDB с помощью boto

https://github.com/bchew/dynamodump

который может делать следующее:

• Резервное копирование/восстановление одной таблицы
• Резервное копирование/восстановление нескольких таблиц
• Резервное копирование/восстановление нескольких таблиц, но между различными средами (например, таблицы production- * в таблицы development- *)
• Резервное копирование всех таблиц и восстановление только данных (не удаляет и не воссоздает схему)
• Создать дамп всех схем таблиц и создать схемы (например, создать пустые таблицы в другой учетной записи AWS)
• Резервное копирование всех таблиц на основе тега AWS ключ = значение
• Резервное копирование всех таблиц на основе тегов AWS, сжатие и сохранение в указанном сегменте S3.
• Восстановление из корзины S3 в указанную таблицу назначения

Ответ 4

Чтение и запись на S3 не будет вашим узким местом.

Хотя сканирование из Dynamo будет очень быстрым, запись элементов в таблицу назначения будет медленной. Вы можете записывать до 1000 элементов в секунду для каждого раздела. Поэтому я бы не стал беспокоиться о промежуточном хранилище S3.

Однако Data Pipeline также не является наиболее эффективным способом копирования таблицы в другую таблицу.

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

В Java есть реализация с открытым исходным кодом, которую вы можете использовать в качестве отправной точки в репозитории лабораторий AWS.

https://github.com/awslabs/dynamodb-cross-region-library

Ответ 5

Вы можете использовать потоки DynamoDb и Lambda для достижения этого. http://searchaws.techtarget.com/tip/DynamoDB-Streams-keep-database-tables-in-sync

Ответ 6

S3 определенно не является узким местом. Я бы почти утверждал, что для 99% сценариев использования вы должны делать это с помощью Data Pipeline + S3, который рекомендован AWS для наилучшей практики. Я предоставил более подробный ответ по этому вопросу здесь: fooobar.com/info/15914097/...

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