Amazon QLDB有任何扩展/性能限制吗?

时间:2019-10-06 05:49:43

标签: amazon-qldb

Amazon QLDB主页上显示

  

QLDB也是无服务器的,因此它会自动扩展以支持您的应用程序的需求。

但是,即使像DynamoDB这样的产品(具有几乎不受限制的自动缩放)也有一些缩放限制。 (例如,DynamoDB每个分区键最多具有3k RCU。)

我正在尝试找出QLDB的扩展/性能限制。每个键,表,分类帐或帐户是否有最大TPS或最大吞吐量?每个表,分类帐或帐户是否有最大存储容量?

截至2019年10月,在QLDB Quotas and Limits页上没有提及任何扩展限制。

QLDB FAQ page说,

  

与普通区块链框架中的分类帐相比,Amazon QLDB可以执行的交易量是分类账的2到3倍。

这只是一个开始,但并不是很有用,因为“ 2-3X”的范围相对较大,而且他们还没有指定他们认为通用的区块链框架。

是否有人在此方面找到任何信息(在文档中,AWS博客文章中,在深潜会话中等),是否有这样的限制?

1 个答案:

答案 0 :(得分:7)

您注意到,任何系统都有限制。要真正解决问题,您需要对用例进行基准测试,以查看获得的数字。我不想误导你!

也就是说,我可以帮助您了解一些QLDB基础知识,这些基础知识将帮助您建立一个心智模型,以了解系统应如何应对不同的工作负载。

第一个要理解的概念是文档修订模型。在QLDB中,插入文档,然后对其进行更新(修订)然后删除。每个文档都有一个QLDB分配的UUID,每个修订版都有一个QLDB分配的(严格单调递增且密集的)版本号。可以通过在QLDB会话中发布交易(发送PartiQL语句)来修改文档。

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

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

第四个概念是期刊。 QLDB是“日志优先”数据库:所有事务都首先写入分布式日志,然后用于更新索引存储。 QLDB体系结构为您抽象了物理日志实现,但确实暴露了“链”的概念,该概念是“日志”的一个分区。每条链具有固定的容量(每秒新修订)。 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级演讲,今年将再做一次。我将在我们的Journal-first架构上进行“粉笔讨论”,并将介绍其中的一些概念。该会话将被记录并上传到YouTube,但“粉笔对话”要求您亲自参加。但这两种方式只是我们必须参与并更好地解释QLDB体系结构,优势和局限性的众多机会之一。请随时提出问题,我们将尽力回答这些问题并提高可用文档的质量。就“ 2-3倍索赔额”而言,此数字是通过针对区块链框架和QLDB构建真实的用例(例如银行业示例)并将这些学习结果提取为一个数字来确定的。我们认为,如果人们不需要分布式分类帐,那么QLDB的集中性可以带来很多好处,而性能就是其中之一。如果您有特定的用例,其中QLDB的速度不比区块链框架上的用例快,那么我们很想听听这些。