数据库DynamoDB的迁徙全环节详解

最近许多组织都在寻求 的代替方案。其关键要素除了最常提到的老本要素之外，节流、硬限度（ ）和供应商锁定等方面，也是迁徙的各种动机。那么，当你须要将数据从 迁徙到另一个数据库时，你能否会方便地从概念上以为，只有从一个数据源读取，转为写入另一个数据源即可呢？当你被要求坚持迁徙的分歧性和安保性时，你能否会思考到“双重写入（Dual-Write）”？鉴于一旦疏忽了某个关键细节，就或许前功尽弃，你能否会想到决定工具，来协助处置此类疑问？其中又有哪些典型的留意事项呢？

上方，我将从概述数据库迁徙的原理登程，向你引见与 迁徙关系的各项特定和关键特色，而后讨论用于与其余数据库集成、以及无缝迁徙到其余数据库所驳回的关系战略。

数据库迁徙的上班原理

大少数数据库的迁徙都遵照如下严厉的步骤：

首先，捕捉曾对源数据库做过的一切更改，以保障任何数据的 修正都可以被后续予以重放（replay）。

其次，经过从源数据库读取并写入目的数据库的模式，启动数据复制。当然，你也可以先导出源数据库的备份，再方便地将其旁路加载（

至此，在初始数据被加载之后，目的数据库将会蕴含源数据库中的大局部记载。之所以称为“大局部”，是由于那些在此时期出现数据更改，将无法被加载出来。对此，下一步便是将源数据库生成的一切增量，重放到目的数据库中。一旦成功，这两个数据库便齐全同步了。后续，你就可以开局切换运行了。

数据库迁徙的上班原理

迁徙，那么你或许据说过经常使用“双重写入”来成功迁徙上班的倡导。也就是说，你须要将代理源数据库中的每个写入器突变（ ），以相反的记载写入目的数据库。

不过，并非每个数据库都成功了像 协定那样，准许写入器检索或操作记载时期戳的概念。这将阻止你在经常使用历史数据回填（back-filling）目的数据库时，对运行实施双重写入。毕竟，此举或许最终造成迁徙的不分歧，即：某些目的项或许无法反映其在源数据库中的最新形态。

迁徙中经常使用双重写入属于失误之举呢？当然不是！思考到你的 小时过时一次性。在这种状况下，经常使用方便地双重写入，并在 到期之后切换读取器的模式，去回填数据库确实没无心义。不过，假设你的 更长（比如一年），那么期待其过时显然不是移动数据的有效方法。

虽然回填历史数据是大少数迁徙中的强迫步骤，但究竟能否须要，则关键取决于你的用例。通常，你可以经过如下

之类的工具会从扫描数据表开局，逐页读取结果，并经常使用结果来推断源表的架构（ 数据表的生成读取器，而写入器会将检索到的数据摄入到目的数据库中。

这种方法十分适宜口头那些方便的迁徙，同时准许你在启动环节中转换（也就是 ）数据。不过，此举容易出现如下疑问：

望文生义，数据表的扫描只会在数据被加载到目的数据库之后，才从源 表中检索一切的记载。与前面的 方法不同，这种方法的“提取”和“加载”局部是耦合的。数据会随着环节的推动而被写入，而且这里的每个步骤都是以分阶段的模式口头的。

好信息是该方法十分方便，你只有运转如下单个命令即可。一旦成功，你就获取了一切数据。

$ aws dynamodb scan --table-name source > output.json

而后，你将最终获取一个蕴含了源表中一切现有项的 文件。据此，你可以方便地实施迭代并写入目的。除非你方案转换数据，否则你无需担忧数据架构，毕竟你已事前通晓了一切键的属性。

留意，此方法仅实用于中小型数据表。与之前的 方法相似，它在扫描较大的数据表时，或许耗时较长，而且尚未包括你对其解析，以及后续将其加载到目的数据库所破费的时期。

假设你领有大型数据集，或许是担忧 的经常使用会对实时流量发生影响的话，则可以将 。此举可以让你轻松地转储数据表的所有内容，而不会影响 表的性能。此外，假设你的回填环节的用时超越了 小时，那么你可以到后续再恳求增量导出。

$ aws dynamodb export-table-to-point-in-time --table-arnarn:aws:dynamodb:REGION:ACCOUNT:table/TABLE_NAME --s3-bucket BUCKET_NAME --s3-prefix PREFIX_NAME --export-format DYNAMODB_JSON

存储桶的话，导出环节将在后盾运转。你可以运转如下命令，来审核其成功状况。

$ aws dynamodb list-exports --table-arn arn:aws:dynamodb:REGION:ACCOUNT:table/source{"ExportSummaries": [{"ExportArn": "arn:aws:dynamodb:REGION:ACCOUNT:table/TABLE_NAME/export/01706834224965-34599c2a","ExportStatus": "COMPLETED","ExportType": "FULL_EXPORT"}]}

该环节成功后，源表中的数据将会在之前指定的 前缀中可用。在外面，你将可以找到一个名为 的目录，其结构如下相似：

$ tree AWSDynamoDB/AWSDynamoDB/└── 01706834981181-a5d17203├── _started├──>

那么，咱们又该如何从这些文件中复原呢？在此，你须要经常使用 API。值得庆幸的是，你无需深化钻研其详细信息，由于作为一种入门的模式，AWS 已提供了 LoadS3toDynamoDB 的示例代码。你只有经常使用目的数据库的写入器逻辑，去笼罩 Dynamo

无论你能否须要回填数据，或许都宿愿从 处捕捉事情，以确保两者彼此同步。对此， 数据流可被用于捕捉在源

提供了 DynamoDB Streams Kinesis Adapter ，以便你经过 Amazon Kinesis 客户端库 ，比如 Apache Spark 中的 kinesis-asl 模块，处置来自 DynamoDB Streams 的各种事情。除了历史数据的迁徙，你只有将事情从 DynamoDB 数据传达输到目的数据库，便 可成功两个数据存储的同步。

虽然这种方法或许会引入峻峭的学习曲线，但作为迄今为止最灵敏的方法，它甚至准许你经常使用 生态系统的外部事情。而这关于想要切换到不同的提供商尤为关键 。对此，AWS 提供了无关如何经常使用源 DynamoDB 表到目的表中的事情的一套 演示流程

函数既易于上手，又可自行处置一切审核点的逻辑，还能与 生态系统无缝集成。经常使用该方法，你只有将运行逻辑封装在 函数中即可。这可以让你将事情写入目的数据库，而无需处置诸如审核点或流中的分片数等

经过该方法，你可以将捕捉到的事情间接加载到目的数据库中。而假设 存在 24 小时保管限度的疑问，你也可以方便地在等其余服务中，流式传输和保管这些记载，以便后续启动重放。无关如何经常使用 Lambda 函数的示例，请参阅 AWS 文档

迁徙的上班原理，以及它与其余数据库的区别。咱们也讨论了回填历史数据，并将数据流更改传输到另一个数据库的不同方法。最后，咱们还应用你或许相熟的 工具讨论了端到端迁徙。综上所述，鉴于咱们有着多种不同的方法来成功迁徙，而且每一种都会存在一系列的优缺陷，因此在开局数据库迁徙之前，咱们须要细心布局，综合比拟迁徙所需的一切工具和战略，并对环节中触及的各个步骤有着透彻的了解。

社区编辑，具备十多年的 名目实施阅历，擅长对内外部资源与危险实施管控，专一传达网络与信息安保常识与阅历。

原文题目： DynamoDB: How To Move Out ，作者：Pratik Patel