10

The main Amazon QLDB page says

QLDB is also serverless, so it automatically scales to support the demands of your application.

However, even products like DynamoDB—with practically unbounded automatic scaling—have some scaling limits. (For example, DynamoDB has a max of 3k RCU per partition key.)

I’m trying to find out the scaling/performance limits of QLDB. Is there any max TPS or max throughput per key, table, ledger, or account? Is there a maximum storage size per table or ledger or account?

As of October 2019, there’s no mention of any scaling limits on the QLDB Quotas and Limits page.

The QLDB FAQ page says,

Amazon QLDB can execute 2 – 3X as many transactions than ledgers in common blockchain frameworks.

That’s a start, but it’s not very helpful because “2-3X” is a relatively wide range, and they haven’t specified which blockchain frameworks they consider common.

Has anyone found any info on this (in the documentation, in AWS blog posts, from a deep dive session, etc) whether or not there are any such limits?

4

1 回答 1

17

正如您所注意到的，任何系统都有限制。对您的问题的唯一真正答案是对您的用例进行基准测试以查看您得到的数字。我不想误导你！

也就是说，我可以帮助您了解一些 QLDB 基础知识，这些基础知识将帮助您建立一个心智模型，了解系统在不同工作负载下的行为方式。

首先要理解的概念是文档修订模型。在 QLDB 中，文档被插入，然后更新（修订），然后被删除。每个文档都有一个 QLDB 分配的 UUID，每个修订版都有一个 QLDB 分配的（严格单调递增和密集）版本号。可以通过在 QLDB 会话上发出事务（发送 PartiQL 语句）来修改文档。

接下来，交易。事务通常读取一些状态，然后继续或放弃。例如，如果您正在构建一个银行应用程序，其用例是从 Mary 向 Joe 转账，交易可能是“读取 Mary 的余额”、“读取 Joe 的余额”、“设置 Mary 的余额”和“设置乔的平衡”。在这两者之间，您的应用程序可以强制执行约束。例如，如果它确定 Mary 的余额小于转账金额，它将放弃交易。如果此事务成功，则会创建两个新的修订（一个用于 Mary 的新银行帐户，一个用于 Joe）。

下一个概念是乐观并发控制 (OCC)，在https://docs.aws.amazon.com/qldb/latest/developerguide/concurrency.html进行了解释. 当您尝试提交事务时，如果另一个事务干扰了您尝试提交的事务，QLDB 将拒绝它。例如，如果再次从 Mary 的账户提款（在您读取余额之后），您的提交将由于 OCC 冲突而失败，允许您重试交易（并重新检查 Mary 是否仍有足够的钱）。因此，您的交易性质会影响您的表现。如果您正在读取账户余额，然后根据读取生成新余额，那么您的吞吐量将低于创建新账户或将账户更改为随机金额（两者都不需要任何读取）的吞吐量。

第四个概念是期刊的概念。QLDB 是“日志优先”数据库：所有事务首先写入分布式日志，然后用于更新索引存储。QLDB 架构为您抽象了物理日志实现，但确实公开了“strand”的概念，它是 Journal 的一个分区。每个链都有固定数量的容量（每秒新修订）。QLDB 目前（2019 年末）将每个分类帐限制为单链。

把这些放在一起，希望我能帮助你解决你的问题：

  1. 最大 TPS。理论上限是单链的最大 TPS。没有一个固定的数字，因为各种因素可能会影响它，但它是成千上万的TPS。
  2. 每个文档的最大 TPS。这永远不会超过最大 TPS，但受 OCC 的约束比其他任何东西都多。如果您只是插入新文档（不读取），那么 OCC 冲突将为零。如果您正在阅读，您将受到我们从期刊更新索引存储所花费的时间的约束。100 TPS 是一个很好的起点。
  3. 每桌最大。除了由其他限制（即每个文档限制或链限制）施加的限制之外，没有每个表的限制。
  4. 每个帐户的最大值。我们对“QLDB 会话”API 没有账户范围的限制。每个账本都是一个岛。
  5. 每个表、分类帐或帐户的最大大小。这里没有限制。

关于会话的说明：我们对 QLDB 的会话默认限制为 1500 个。每个会话只能有 1 个活动事务，并且由于 PartiQL 查询时间、网络往返或您的应用程序正在处理结果的工作，每个事务都需要一些时间。这将对你的表现施加一个上限。我们确实允许客户增加此限制，如https://docs.aws.amazon.com/qldb/latest/developerguide/limits.html中所述。

关于您问题的其他部分（文档、示例和学习材料），我可以提供一些信息。QLDB 于上个月发布，因此 re:Invent 2019 是我们与客户互动并获得有关开发人员需要更多帮助的直接反馈的第一个机会。我们在 re:Invent 2018 上进行了 300 级的演讲，今年还会再做一次。我将就我们的日志优先架构进行“粉笔谈话”，并将介绍其中的一些概念。会议将被记录并上传到 YouTube，但粉笔讲座需要您亲自到场。但无论哪种方式，这只是我们必须参与并更好地解释 QLDB 架构、优势和限制的众多机会之一。随时继续提问，我们' 我们将尽最大努力回答这些问题并提高可用文档的质量。就“2-3x 声明”而言，这个数字是通过针对区块链框架和 QLDB 构建现实世界的用例（例如银行示例），并将这些学习成果提炼成一个数字来确定的。我们相信，如果不需要分布式账本，QLDB 的中心化特性可以带来很多好处，而性能就是其中之一。如果您有 QLDB 不比区块链框架上的相同用例快的特定用例，我们很乐意听到这些。我们相信，如果不需要分布式账本，QLDB 的中心化特性可以带来很多好处，而性能就是其中之一。如果您有 QLDB 不比区块链框架上的相同用例快的特定用例，我们很乐意听到这些。我们相信，如果不需要分布式账本，QLDB 的中心化特性可以带来很多好处，而性能就是其中之一。如果您有 QLDB 不比区块链框架上的相同用例快的特定用例，我们很乐意听到这些。

于 2019-10-30T16:49:56.673 回答