考虑DynamoDB的高级恢复能力，每个客户的DynamoDB表

Question

我正在决定是否为每个客户提供一张桌子，或者客户是否与其他人共享一张桌子。为每个客户创建一个表似乎有问题，因为这只是另一件需要管理的事情。

但后来我考虑备份数据库。可能会出现这样的情况，即客户没有强大的IT安全性，甚至没有一个不满的员工，而此人会删除客户的一大堆重要数据。

在这种情况下，如果所有客户都在同一个表中，例如，不能仅从2天前的DynamoDB快照恢复，因为所有其他客户都会丢失过去2天的数据。在云计算之前，这在我看来并不是一个普遍的考虑因素，因为备份并不是那么直接地为那些不是第1层业务的客户提供这样的功能，而这些客户并没有真正考虑到这一点。

但是这个功能对于我的SAAS应用程序来说可能是一个巨大的卖点，所以现在我认为每个客户都有桌子是值得的。这是正确的思路吗？

Answer 1

单独的表格：

• 最大表数。这可能是一个软限制，但您必须经常联系支持人员，这对您来说是额外的开销，因为他们更喜欢以小的（合理的）位提高限制
• 还有很多事情需要管理、保护、监控等
• 可能有更多的RCU和WCU浪费

只是抛出另一个想法，还没有尝试过，也没有考虑过每一个赞成和反对。

使用Lambda提取所有写操作，并将它们写入备份表。使用TTL（用户可以恢复其内容的时间）免费删除旧条目。如果您为不同价格级别的服务提供更长的备份，甚至可以根据客户修改TTL。

您需要一个好的模式来避免热键。

customer-id (partition ID) | time-of-operation#uuid (sort key) | data, source table etc
-------------------------------------------------------------------------------------------

例如，如果你的一些客户比其他人更活跃，这个例子可能会有问题。

可能的解决方案：使用已知范围的int-s作为后缀ID，例如client-id#1，client-id#2... client-id#100等。这将传播写入，您的应用程序知道范围-能够查询。

无论如何，这只是我脑海中一个快速而肮脏的例子。

我想到的一些利弊：

• 可能更贵，除非单独的桌子有较大的RCU/WCU净空

Answer 2

对我来说，这听起来是一个很好的思路。您可能还需要考虑以下几点：

• 将所有客户数据放在一个表中可能会更便宜，因为您可以更高效地分发RCU和WCU。从客户的角度来看，这可能是好的，也可能是坏的，因为一个客户可以使用任何客户的RCU/WCU（如果您想这样考虑的话）。如果将客户数据拆分为单独的表，则可以单独对其进行调配
• 细粒度安全性在DynamoDB中不是很好。只有当表的分区键是Amazon uid时，才能真正实现行（项）级安全性。如果无法做到这一点，您将依赖应用程序代码来保护客户数据。将客户数据拆分为单独的表将提高安全性（如果无法使用项目级安全性）

关于你的问题。DynamoDB备份实际上不必还原到同一个表中。因此，您可能将所有客户数据都放在一个备份的表中。如果一个客户请求恢复，您可以将数据加载到新表中，将其数据同步到活动表中，然后删除恢复表。这不一定很容易，但你可以试一试。此外，您还可以在执行同步时支付所有RCU/WCU的费用，这是您在恢复时不会产生的费用。

希望其中一些有用。