From inevitable overprovisioning to the “on-demand” tax: why DynamoDB is bloody hard to cost-control 最近 有了帮助潜在的ScyllaDB客户了解运行DynamoDB的真正成本的具体目标,现在,如果你退一步,看看我的目标,这没有太大的意义,对吗?如果有人已经使用DynamoDB,他们不会知道在规模上运行该技术的成本是多少? 建立一个DynamoDB成本计算器 天真地说,这也是我一开始的想法,但后来,我开始反驳DynamoDB成本计算的内部运作方式,当时我意识到,为什么团队最终会支付数十万美元(如果不是数百万美元),以便在规模上运行DynamoDB有很多原因。 我发现的最重要的是:DynamoDB易于采用,但难以控制成本。 我的同事Guilherme和我 ,但如果你没有时间观看,继续阅读,以发现关键的发现。 通过这些线路进行Webinar 第一個常見的誤解是DynamoDB對您收取的費用,您可能已經聽說過閱讀能力單位和寫作能力單位等用語,並且在閱讀和寫作數量方面得到“你為你所使用的付款”的說法。 DynamoDB 写作非常昂贵。 如果你看看 ,你会看到一个阅读请求单元(RRU)的成本是每百万单位的0.125美元,而一个写请求单元(WRU)的成本是每百万单位的0.625美元。所以,写作比读取高5倍。我不知道确切的技术原因,但毫无疑问,写作路径是更重的(耐用性,一致性,索引等),也许有些头部空间。 按需容量定价 谈到什么......还有另一种模式: 正如名字所暗示的那样,这意味着你可以指定你要使用多少(即使你不使用它),并希望付出更少的费用。 尽管如此,让我们检查比率。 每 RCU 的读取能力单位(RCU)费用为 $0,00013,而写作能力单位(WCU)费用为 $0,00065,所以写作成本比读取成本高出不奇怪的5倍。 因此,即使在预定模式下,你仍然在写作上支付5倍的罚款。 预定能力 你不是提供请求,你是提供价格... 这里是捕获:提供的容量单位是每秒测量的,而不是每百万个请求,就像在按需的情况下一样。这让我一开始就感到沮丧。 每秒 N 操作,无论您是否使用该容量。 处理的能力 因此,如果您的流量爆炸了,或者您过于预算,以避免请求转移(稍微更多),您基本上正在支付空闲容量。 保留能力... 因此,这里是交易:如果你保留容量,你是在提前大打赌,希望稍后节省一点。 如果您对基线使用情况有信心,则 AWS 会为您提供预留 DynamoDB 容量的选项,就像 EC2 或 RDS 一样。 一个Gotcha:没有部分前期选项;它是全额支付或离开。 让我们来看看一个简单的用例来比较价格模型... 假设您的工作负载平均值为1小时内1万读/秒和1万写/秒。 按需价格: 写作: $22.50 / 小时 ... 10,000 * 3600 * 0.625 / 1M 阅读: $4.50 / 小时 ... 10,000 * 3600 * 0.125 / 1M (比写作便宜5倍,如往常) 预定价格(未预定): 字体: $6.50/hr ... 10,000 * $0.00065 阅读: $1.30 / 小时 ... 10,000 * $0.00013 提供1年保留: 写作: ~ $ 2.99/hr 阅读: ~$0.59/小时 “嘿,保留数学在哪里?”我听到你。 你用100 WCU($0128/hr)和RCU($0.0025/hr)的保留价格,一个月的730小时,一年中的12个月,再用100个单位,以你所需的速率来倍增,然后翻开它,哭一点,并粘贴到“数学女士”的子里。 我的观点是: Provisioned 比 On-Demand 便宜 3.4 倍 预订价格:比按需价格便宜7,5x 按需是为喜欢过度支付或讨厌预测的人。 btw , 为: AWS 建议按需 随着时间的推移而演变的交通模式 Spiky 或 batchy 工作负载 低利用率(降至零或低于峰值的30%) 这基本上是每一个现实生活的工作负载 - 至少对于ScyllaDB的客户来说,所以是的,希望为这种灵活性付费,除非你的流量看起来像一本教科书,你有一个水晶球。 它不是物件的大小,但它是... 这是一个你可能不会击中,直到你使用真实的应用数据......在这个时候,你会立即后悔忽略它。 在DynamoDB中,你不只是按操作付款,而是按传输数据的片段付款,并且片段大小在读写之间有所不同: Writes 每 1KB (Write Request Units 或 WRUs) 发票 读取每4KB(读取请求单位或RRU) 所以,如果你写一个 1.1KB 项目,那就是 2 WRUs. 写一个 3KB 项目? 仍然 3 WRUs,每一个 1KB (或其中的一部分) 都被计算。 读取方法是相同的,只有在4KB的边界。读取1KB的项目?1RRU。读取4.1KB的项目?这就是2RRU。 是不是有趣?我相信这些边界有很强的技术原因。你可以在这里看到陷阱。将此与写作成本的5倍相对于阅读的成本结合起来,事情可能会很快变得丑陋,特别是如果你的项目大小超越了这些门槛,而你没有意识到。如果你在你的计划中有固定的项目大小,但绝对不会与我们在ScyllaDB看到的使用案例类型相符。 过度供应,因为你必须... 另一个疼痛点,以及AWS自己的计算机的错误遗漏,是使用预算容量时需要过度预算。听起来很矛盾,但你被迫过度预算 - 不是因为你想要,而是因为DynamoDB会惩罚你如果你不这样做。 如果您滑过预定的容量,您将击中 我喜欢这种类型的例外信息的清晰度. 我不喜欢它实际上做什么,尽管:请求。 它保留了未使用的阅读和写作能力,但除此之外,您的应用程序只会失败。 过度过度过度过度 300s 窗口爆炸容量 因此,最好的方法来应对这种情况是过度供应,多少?这保证了“取决于”的答案,但它确实取决于您的工作负载类型,我们将此功能添加到我们的计算机中,以便您能够以一个百分比动态过度供应,仅仅是为了考虑到工作负载的额外成本。显然,这些成本可以快速增加,因为在实践中,即使您在仓库中工作,您也会为峰值支付费用。 在我们移动之前... 如果这里有一个重复的主题,那就是这样:DynamoDB的定价并非本质上错误,你会为你所使用的付出代价,但对于任何看起来不像完美、可预测的恶性波的工作负荷来说,这是非常不可原谅的。 不管它是: 5x写成本倍增器 7.5x 按需成本倍增器 Opaque每秒预定利率 惩罚性圆形和物件尺寸的人工边界 或者只是需要过度供应以避免在峰值负荷期间面部种植 你总是需要第二次猜测你的架构,只是为了保持成本爆炸的优势。 讽刺的是,DynamoDB被标记为“无服务器”和“完全管理”,但你最终会管理容量数学,推断错误,极端的定价水平和无限的输出体操。 这就是为什么我们构建了一个模拟实际工作负载的计算机,而不仅仅是平均值,因为确定成本的第一步是了解它们来自哪里。 在 ,我通过一些从DynamoDB切换到ScyllaDB的客户的现实世界示例,以显示流量模式,项目大小,缓存和多区域 topologies的真实影响。 在 . 我的下一个博客文章 跳跃前进并模拟自己的工作负载 在我们的新成本计算器上模拟您自己的 DynamoDB 工作负载 提姆·科普曼斯 在过去的几十年里,蒂姆一直在从事各种工程,热衷于可靠性和安全性。2013年,他创立了Flood IO,这是一个分布式性能测试平台,经过收购后,他喜欢扩展产品、业务和团队,然后转向其他性能相关的项目。
