Я бы хотел скопировать все таблицы dynamoDB в другую учетную запись aws без s3 для сохранения данных. Я видел решения для копирования таблицы с конвейером данных, но все они используют s3 для сохранения данных. Я хотел бы пропустить шаг s3, так как таблица содержит большой объем данных, поэтому может потребоваться время для чтения s3 и процесса чтения s3. Поэтому мне нужно напрямую скопировать таблицу из одной учетной записи в другую.
Скопируйте таблицу 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.
Ответ 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, прежде чем наконец переключить клиентов, которые пишут данные. Пара других ароматов этого плана миграции также возможны.