我有一个 QLDB 最有意义的用例。我还认为发件箱模式对数据可靠性很有意义。但是,我担心发件箱条目会污染期刊。
我的理解是,虽然我可以将“发件箱”表与主数据表分开,但日记帐在整个分类帐中共享。似乎发件箱模式传统上使用关系数据库,其中不可变日志的概念不是问题。
随着数据集的增长,这会成为一个问题吗?更重要的是,是否有一种更有意义的替代模式?
我有一个 QLDB 最有意义的用例。我还认为发件箱模式对数据可靠性很有意义。但是,我担心发件箱条目会污染期刊。
我的理解是,虽然我可以将“发件箱”表与主数据表分开,但日记帐在整个分类帐中共享。似乎发件箱模式传统上使用关系数据库,其中不可变日志的概念不是问题。
随着数据集的增长,这会成为一个问题吗?更重要的是,是否有一种更有意义的替代模式?
由于日志是提交给分类帐的每笔交易的不可变历史记录,因此如果您将发件箱模式与 QLDB 一起使用,您的分类帐将包含通过发件箱表传递的消息的永久历史记录。如果您需要排队等待发送的消息的不可篡改的审计历史记录以及正在发送的消息(从表中“删除”)的记录,这将非常有用。但是,如果您不需要它,那么您将在分类帐的整个生命周期内为这些消息支付存储费用,并且不会从中获得太多价值。
典型的事件驱动方法是使用 QLDB 的流式传输功能,该功能将 Kinesis Data Stream 与您的分类帐相关联。每次提交事务时,QLDB 都会将事务发布到 Kinesis Data Stream。这使您能够从分类帐中发生的交易中驱动事件。使用这种方法,您可以将业务数据提交到分类帐,而无需担心发件箱表。该文档应包含您在消息传递中需要的信息。提交后,QLDB 会将事务中的文档推送到 Kinesis 中,您可以在其中使用 Lambda 函数处理它,然后继续发送消息。
需要注意的一点是,QLDB 提供了至少一次将数据传输到 Kinesis 的保证。这意味着您需要识别和处理(或只是容忍)潜在的重复消息。不过,无论如何,您应该始终考虑分布式系统中的幂等性。
如果您不想为 Kinesis 付费并且不需要实时方法,您可以通过预定的 QLDB 导出到 S3 以及对导出文件进行一些批处理来做一些事情,但我将从流式传输开始。如果您想了解更多有关导出方法的信息,请联系我。
也可以看看: