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

时间:2017-01-26 11:01:47

标签: amazon-dynamodb amazon-sqs amazon-sns amazon-kinesis amazon-dynamodb-streams

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

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

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

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

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

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

我开始考虑其他解决方案,如:

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

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

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

2 个答案:

答案 0 :(得分:2)

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

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

只是我的2¢。

答案 1 :(得分:0)

如今,带有订阅的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搜索功能之类的信息。