Amazon QLDB 设计原则答案

【问题标题】：Amazon QLDB Design PricinplesAmazon QLDB 设计原则
【发布时间】：2020-09-25 17:40:52
【问题描述】：

我想知道在 QLDB 中设计表的最佳方式，以及是否最好执行连接或嵌套文档。例如，如果我有表transaction 和payment，其中付款必须与交易相关联。以下哪个选项最好；

嵌套文档选项（一个表格）

{
    'payment_reference': 'abc123',
    'transaction': {
        'id': 123,
        'name': 'John Doe',
        'amount': '$10'
    },
    'fees': '$2',
    'amount_paid': '$12'
}

两个表选项

付款文件

{
    'payment_reference': 'abc123',
    'transaction_id': 12,
    'fees': '$2',
    'amount_paid': '$12'
}

交易文件

{
    'id': 123,
    'amount': '$10',
    'name': 'John Doe',
   
}

【问题讨论】：

标签： amazon-qldb

【解决方案1】：

我认为@Aurgho 已经回答了您的问题。但我将根据 Aurgho 所说的内容提出我的一般想法，这可能会帮助其他有类似问题的人来这篇文章。

有多种因素会影响您的设计决策，以及 QLDB 施加的配额和限制。以下是一些可以帮助您向前思考的建议：

查询模式：此时，Amazon QLDB 只允许在顶级字段上创建索引。在嵌套文档设计（选项 #1）中，如果您的查询将在嵌套文档的任何字段上进行，那么这些查询将不使用索引并将执行扫描。这会影响您的表现。使用选项 #2，您可以在两个表上都有索引，并在连接条件中使用这些索引字段。
访问模式：您的写入量是否会明显多于读取量？如果您的读取很稀疏，并且对稍有延迟的延迟不是非常敏感，那么从数据建模的角度来看，选项 #1 可能会更好，因为所有与支付相关的信息都被捕获在一个文档中。另一方面，如果您有更多读取，并且读取对延迟敏感，则应从前一点的角度评估您的选择。
配额和限制：Amazon QLDB 对文档大小（当前为 128 KB）https://docs.aws.amazon.com/qldb/latest/developerguide/limits.html#limits.fixed 有配额。如果您计划随时添加更多字段，则每个文档的大小会随着嵌套字段而不断增加，您最终可能会遇到文档大小限制。还有其他配额可能会根据您的用例影响您的决定。

一般来说，如果您不打算查询嵌套文档中的字段和/或您的写入>>>读取和/或您的读取不是对延迟非常敏感和/或您的文档大小将保持在当前施加的限制内，您可以使用选项 #1。当您将数据推送到 QLDB（仅一次插入）以及必须在代码中处理文档时，将所有数据放在一个文档中可以让您在应用程序层轻松一些，但您必须正确选择权衡.

这些只是帮助您向前思考的一般指示。您可能还有其他用例，其中任何一个设计选项都比另一个更令人信服，并且您可以在两者之间权衡某些优点/缺点。

此外，QLDB 还提供了一些优化查询性能的建议，可以进一步帮助您做出决定https://docs.aws.amazon.com/qldb/latest/developerguide/working.optimize.html

【讨论】：

【解决方案2】：

如果在嵌套文档选项中选择交易文档嵌套在付款文档中，请记住文档大小限制为 128KB，如 QLDB limits documentation 中所述。如果可以预见付款单据在嵌套后大到足以达到此限制，则此选项可能存在风险。
如果您预见到必须对事务文档中的某些字段建立索引，您可以创建两个单独的表并改为执行连接。（如create index reference 中所述，QLDB 不允许对文档的嵌套值进行索引，并且如我们的限制文档中所述，AWS QLDB 允许每个表最多有 5 个索引）

上述建议仅基于帖子中提供的信息，我们不了解此用例中当前的访问模式，需要进一步了解才能更好地回答。您可以通过 qldb-outbound AT amazon.com 与团队联系，以进一步咨询您的用例。

谢谢

【讨论】：