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

Question

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

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

注意：我最关心的是成本

标签： databasemongodbarchitectureamazon-dynamodb

Answer 1

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

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