dynamoDb 是否适合维护将来可以扩展的通知数据？答案

【问题标题】：Is dynamoDb a good fit to maintain notification data that can scale in future?dynamoDb 是否适合维护将来可以扩展的通知数据？
【发布时间】：2020-10-18 20:37:13
【问题描述】：

在我们的应用程序中，我们目前使用 dynamoDb 来存储通知详细信息。因此，调度程序每天运行两次，查询“notificationType”（pk -> notifiactionType，sk -> userId）。在每个项目中都有一个属性（时间戳），基于该属性如果时间戳大于当前时间将发送触发器（更多的业务逻辑，对于时间戳后一天的某些记录需要发送邮件）。现在一旦用户执行发送通知的活动，然后将删除该条目

我的疑问是，如果通知类型的数据变大，那么检索所有数据是多余的，因为对于某些记录，通知不会被发送。因此使用了更多的读取容量，这可能会在以后的时间点增加成本。在这种情况下，明智的做法是使用现有的 dynamoDb 或移动到任何其他数据库，如 mongoDb、cassandra 或任何其他数据库。

注意：我最关心的是成本

【问题讨论】：

您是否需要调度程序每天运行两次，或者如果通知在时间戳过去后立即发送，它是否也适用于您的用例？
我的假设是否正确，您还使用该 DynamoDB 表来永久存储所有通知（无论它们是否具有过去或未来的时间戳）？
@Dunedan，对于您的问题 1。这取决于 notificationType。对于某些通知类型，我们会在时间戳通过后立即发送邮件。对于其他的notificationType，假设我们需要给2nd day 提醒，4th day 提醒一旦它通过了时间戳。（即超过时间戳 2 天） 2）目前，不需要永久存储数据，因此一旦用户执行发送通知的操作，我们就会删除通知谢谢！
您是否考虑过使用 TTL 使旧的过期，这样您就不必扩大规模？
@hephalump，数据会一直保留到用户执行所需的操作，并为此发送通知。所以一旦时间戳过去，第一封邮件就会被触发。即使超过时间戳 2 天，用户也没有完成所需的操作，必须在第 2 天触发邮件。所以数据删除只有在用户的任务完成后才进行

标签： database mongodb architecture amazon-dynamodb

【解决方案1】：

另一种选择是使用工作流引擎，它可以为每个用户而不是批处理作业建模通知过程。这样您就可以避免扫描大量数据，因为引擎将依赖持久计时器在适当的时间执行操作。

我在 Uber 领导的开源项目 temporal.io 被多家公司用于类似场景的通知，并测试了 2 亿个开放的并行工作流。

【讨论】：