亚马逊推荐的在生产DynamoDB中更改大表架构的方式是什么？
假设有一个假设案例，我们有一个表Person，具有主哈希键SSN。该表可能包含1000万个项目。
现在有消息传出，由于身份盗用的数量非常之大，这个假想国家的政府引入了另一个个人身份证明:唯一个人身份证明(UPI)。
我们必须添加一个UPI列并更改Person表的架构，以便现在的主要哈希键是UPI。 我们要在一段时间内同时支持使用SSN的当前系统和使用UPI 的新系统，因此我们需要将这两列同时存在于Person表中。
亚马逊推荐的进行此架构更改的方法是什么？
有两种方法，但是首先您必须了解您不能更改现有表的架构。要获得其他架构，您必须创建一个新表。您也许可以重用现有的表，但是结果将与创建其他表相同。
无需数据流即可懒惰地迁移到同一表。每次您修改Person表中的条目时，都使用UPI而不是SSN作为哈希键的值在Person表中创建一个新项，并删除以SSN为键的旧项。假设UPI从与SSN不同的值范围中提取。如果SSN看起来像XXX-XX-XXXX，那么只要UPI的位数与SSN的位数不同，那么您将永远不会重叠。 使用Streams延迟迁移到同一表。当流普遍可用时，您将能够为您的Person表打开Stream。创建具有NEW_AND_OLD_IMAGES流 View 类型的流，并且每当您检测到对将“UPI”添加到“人员”表中现有人员的项目的更改时，创建一个Lambda函数，该函数将删除以SSN键为键的人员，并添加具有相同名称的人员。以UPI为关键的属性。此方法具有竞争条件，可以通过向项目添加原子反版本属性并在version属性上限制DeleteItem调用来缓解这些竞争条件。 使用Streams抢先(脚本式)迁移到其他表。运行一个脚本，该脚本扫描您的表并将唯一的UPI添加到Person表中的每个Person项。在具有NEW_AND_OLD_IMAGES流 View 类型的Person表上创建流，并在该lambda函数检测到具有UPI的Person被更改时，或者向该流订阅一个lambda函数，该函数将所有新Person写入新的Person_UPI表中。 UPI已添加。基表上的突变通常需要数百毫秒才能作为流记录出现在流中，因此您可以对应用程序中的新Person_UPI表进行热故障转移。拒绝请求几秒钟，在这段时间内将您的应用程序指向Person_UPI表，然后重新启用请求。