DynamoDB是否为此用例提供了正确的选项？

Question

我有一个DynamoDB表，其中包含许多应用程序将读取的键值对。启动时，每个应用程序将读取整个表并将其缓存在内存中。

我试图解决的问题是，如果修改了DynamoDB表中的一个或多个项目，应用程序将更新其缓存。

DynamoDB流最初似乎是解决问题的正确方法。我已按照AWS的建议使用Kinesis客户端库（KCL）实现了使用者。然而，在实施它时，我遇到了一些让我相信自己走错路的问题。具体做法是：

• 当我使用KCL创建新的使用者时，它会创建一个新的DynamoDB表来执行租约和检查点的管理，这样当应用程序重新启动时，KCL知道哪些记录已被消耗，哪些记录已被消耗。这不是我对这个问题的需要。应用程序脱机时创建的任何流记录都无关紧要，因为在应用程序启动时会读取整个表。

• 同一应用程序的多个实例同时运行。需要通知每个表更新。要在KCL中实现它，我需要为每个应用程序分配一个唯一的应用程序名称。否则，他们将共享租赁表，只会通知其中一个应用程序。每个应用程序实例的一个表似乎不对。此外，我还需要一些东西来删除未使用的表。

我也使用低级API实现了它。当有一个碎片时，这样可以正常工作。我的实现并没有像KCL那样处理重新分片，但是它太脆弱了。对于我试图解决的简单问题，必须实施重新分片处理似乎是错误的。

我开始考虑其他解决方案，如：

• 实现在对表的更新时触发的lambda函数。该功能向SNS主题发送通知。消费者就该主题创建SQS订阅并通过该订阅获得通知。这个解决方案有太多可移动的部分供我喜欢。

• 使应用程序定期重新读取整个表，并确定是否已进行更改。这个解决方案感觉有点原始，但似乎是最简单的。

到目前为止，我所考虑的所有解决方案都有相当大的缺点。我错过了什么？

Answer 1

这取决于你的KCL如何推动依赖应用程序，但是 我相信SQS路径是正确的选择。

• 您可以在不受限制的情况下添加大概数量的消费者。
• 当你添加另一个依赖应用程序时，它不需要更改你的KCL来推送它，新应用程序将只是观察SQS队列。
• 您可以在发生问题时监控队列。
• 要设置更多移动部件，但是一旦你有Streams -> SNS -> SQS管道，它基本上是防弹的。

只是我的2¢。

Answer 2

如今，带有订阅的AWS AppSync GraphQL API可能是支持这种类型的应用程序的最简单方法，并且移动部件的数量最少。

只要您的一个应用程序启动，它就会使用Amplify框架或AppSync SDK连接到您的AppSync GraphQL API并订阅其感兴趣的更新。然后只要应用程序更新表中的信息通过您的GraphQL API，您所有其他应用程序都会收到有关更改以及相关更改数据的通知。

AppSync可以与DynamoDB很好地集成在一起，允许您使用GraphQL生成具有适当索引的DynamoDB表，或者根据需要从现有DynamoDB表生成GraphQL。 Amplify甚至可以通过使用GraphQL transformers来帮助您自动生成更高级别的AppSync GraphQL API，以及相关的DynamoDB表，索引，实体关系以及诸如Elasticsearch搜索功能之类的信息。