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

正如你所注意到的,任何制度都有其局限性。你问题的唯一真实答案是需要对你的用例进行基准测试,看看你得到了什么数字。我不想误导你!

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

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

把这些放在一起,希望我能帮你回答你的问题:

1. 最大TPS。理论上限是单个 搁浅。没有一个固定的数字,因为各种因素都有可能 影响它,但它是成千上万的TPS。
2. 插入新文档(无读取)您将没有OCC冲突。 如果你在读书,你会受到我们所花时间的约束 起点。
3. 每个表的最大值。除了其他限制(即每个文件的限制或钢绞线)施加的限制外,没有每个表的限制
4. 每个帐户的最大值。我们对“QLDB Session”API没有账户范围的限制。每一本账本都是一座孤岛。
5. 每个表、分类帐或帐户的最大大小。这里没有限制。

注意:QLA会话数限制为1500。每个会话只能有一个活动事务,每个事务都要花费一定的时间,这可能是由于PartiQL查询时间、网络往返或应用程序对结果所做的工作造成的。这将对你的表现施加一个上限。我们允许客户增加此限制,如 https://docs.aws.amazon.com/qldb/latest/developerguide/limits.html

关于你问题的另一部分(文件、例子和学习材料),我可以提供一些信息。上个月,QLDB发布了更多直接帮助客户的机会:我们需要在2019年获得更多反馈。我们在re:Invent2018大会上做了一次300级的演讲,并将在今年再做一次。我将在我们的《第一架构》(first architecture)杂志上发表一篇“粉笔演讲”,并将介绍其中的一些概念。会议将被录制并上传到YouTube,但粉笔演讲要求你亲自到场。但不管怎样,这只是我们必须参与并更好地解释QLDB体系结构、优点和局限性的众多机会之一。请随时提出问题,我们将尽最大努力回答这些问题,并提高可用文档的质量。就“2-3倍索赔”而言,这一数字是通过针对区块链框架和QLDB构建真实世界用例(如银行业示例)并将这些经验提炼为单个数字来确定的。我们相信,如果不需要分布式账本,QLDB的集中式特性可以提供许多好处,性能就是其中之一。如果你有QLDB不比区块链框架上的同一个用例快的特定用例,我们很乐意听听。