amazon-dynamodb - 使用适用于Titan的DynamoDB存储后端的DynamoDB定价

Question

我想很好地了解使用DynamoDB Titan后端的价格（以美元计）。为此，我需要能够理解DynamoDB Titan后端何时进行读写。现在我很笨。

理想情况下，我想运行一个测试用例，它添加了一些顶点，边，然后进行了相当简单的遍历，然后查看完成了多少次读写操作。关于如何实现此目标的任何想法？可能通过指标？

如果事实证明我自己不能提取此信息，我将非常感谢有关DynamoDB Titan后端何时执行读取和写入的第一个简要说明。

Answer 1

对于所有Titan后端，要了解和估计写入次数，我们依靠估计给定KCVStore的列数。您还可以测量使用用于Titan的DynamoDB Storage Backend时使用度量标准写入的列数。

要启用指标，请启用here中列出的配置选项。
具体来说，启用7-11行。
请注意max-queue-length配置属性。如果executor-queue-size metric在特定的tx.commit()调用中达到max-queue-length，则您知道队列/ storage.buffer-size不够大。一旦执行者队列大小度量标准达到峰值而未达到最大队列长度，您就会知道您已经捕获了所有在tx.commit()调用中写入的列，因此将为您提供在tx.commit()中更改的列数。您可以查看边缘存储和graphindex的UpdateItem指标，以了解两个表之间的列分布。

所有Titan后端存储都实现KCVStore，根据存储类型，键和列具有不同的含义。假设您尚未打开用户定义的事务日志，则有两个存储可进行大量写操作。它们是edgestore和graphindex。

无论是否配置复合索引，都会始终写入边缘存储KCVStore。每条边和该边的所有边属性均由两列表示（除非您将该边标签的模式设置为单向）。边列的关键是直接列中边的外顶点，而后列中边的内顶点。同样，边的列是直接列中边的内顶点，而边的列是反面中的边的顶点。每个顶点至少由VertexExists隐藏属性的一列，一个顶点标签（可选）的一列和每个顶点属性的一列表示。顶点的键是顶点ID，列对应于顶点属性，隐藏的顶点属性和标签。

只有在Titan管理系统中配置复合索引时，才会写入graphindex KCVStore。您可以索引顶点和边属性。对于每一对索引值和具有该索引值的边/顶点，graphindex KCVStore中将存在一列。键将是索引ID和值的组合，而列将是顶点/边缘ID。

现在，您知道如何计算列，可以在使用适用于Titan的DynamoDB存储后端时，使用此知识来估计对edgestore和graphindex的写入大小和数量。如果将多项目数据模型用于KCVStore，则每个键列对都将获得一个项目。如果对KCVStore使用单项数据模型，则将在键处为所有列获得一项（启用图形分区时不一定是正确的，但这是我现在不再讨论的细节）。只要每个顶点属性小于1kb，并且边缘的所有边缘属性的总和小于1 kb，则在使用多项数据模型进行边缘存储时，每列的写入成本为1 WCU。同样，如果使用多项目数据模型，graphindex中的每一列将花费1 WCU编写。

假设您进行了估算，并且始终使用多项目数据模型。让我们假设您估计每秒将向edgestore写入750列，向graphindex每秒写入750列，并且您希望将这一负载驱动一天。您可以将两个表的读取容量设置为1，因此您知道每个表都将从一个物理DynamoDB分区开始。在us-east-1中，每10个单位的写入容量每小时的写入成本为$ 0.0065，因此，对于每个表而言，每天24 * 75 * $ 0.0065的写入成本为$ 11.70。这意味着Edgestore和graphindex的写入容量每天将花费$ 23.40。可以将每个表的读取次数设置为每秒1次读取，从而使每天两张表的读取成本为2 * 24 * $ 0.0065 = $ 0.312。如果您的AWS帐户是新帐户，则读取将属于免费套餐，因此，实际上，您只需为写入付费。

DynamoDB pricing的另一方面是存储。如果您每秒写入750列，即每天在一张表中写入6480万个项目，则意味着每月有19亿个（约20亿个）项目。则该表中一个月的平均项目数为10亿。如果每个项目的平均大小为412字节，并且有100字节的开销，那么这意味着一个月要存储10亿个512字节的项目，每个月大约477 GB。 477/25向上舍入为20，因此按此负载进行存储的第一个月的费用为每月20 * 0.25美元。如果您继续以这种速率添加项目而不删除它们，则每月的存储成本将每月增加约5美元。

如果图形中没有超级节点或具有相对大量属性的顶点，则对边缘存储的写入将在整个分区键空间中均匀分布。这意味着您的表在达到10GB时将划分为2个分区，然后在达到10GB时，每个分区将共划分为4个分区，依此类推。 2到477 GB /（10 GB /分区）的最近幂是2 ^ 6 = 64，因此这意味着您的边缘存储在第一个月的过程中将分裂6次。在第一个月末，您可能会有大约64个分区。最终，您的表将具有如此多的分区，以至于每个分区将只有很少的IOPS。这种现象称为IOPS饥饿。您应该有适当的策略来解决IOPS饥饿的问题。两种常用策略是1.批量清理/存档旧数据和2.滚动（时间序列）图。在选项1中，您旋转EC2实例以遍历图形并将旧数据写入较冷的存储区（S3，Glacier等），然后将其从DynamoDB中删除。在选项2中，您直接写入与时间段（周-2015W1，月-2015M1等）相对应的图形。随着时间的流逝，您向下调配了旧表上的写入，并且当需要将它们迁移到较冷的存储时，您将读取该时间段的整个图并删除相应的DynamoDB表。这种方法的优势在于，它可以使您以更高的粒度管理写入配置成本，并且可以避免删除单个项目的成本（因为您免费删除了一个表，而不是每个项目至少产生1个WCU您删除）。