我希望能够很好地理解使用DynamoDB Titan后端的价格（以$为单位）。为此，我需要能够理解DynamoDB Titan后端何时进行读写操作。现在我很无能为力。
理想情况下，我想运行一个测试用例，它会添加一些顶点，边缘，然后进行相当简单的遍历，然后查看完成了多少次读写操作。有关如何实现这一目标的任何想法？可能通过指标？
如果事实证明我无法自己提取这些信息，我非常感谢有关DynamoDB Titan后端何时执行读写操作的第一个简要说明。
答案 0 :(得分：8)
对于所有Titan后端，要理解和估计写入次数，我们依赖于估计给定KCVStore的列数。您还可以使用DynamoDB Storage Backend for Titan测量使用指标编写的列数。
要启用指标，请启用列出的配置选项here。
具体而言，启用第7-11行。
请注意max-queue-length配置属性。如果executor-queue-size metric命中特定tx.commit()调用的max-queue-length，那么您就知道queue / storage.buffer-size不够大。一旦执行程序 - 队列大小度量标准达到峰值而没有达到max-queue-length，您就知道已经捕获了tx.commit()调用中写入的所有列，因此这将为您提供在tx.commit()中更改的列数{1}}。您可以查看edgestore和graphindex的UpdateItem指标，以了解两个表之间列的扩展。
所有Titan存储后端都实现KCVStore，键和列具有不同的含义，具体取决于商店的类型。假设您尚未打开用户定义的事务日志，则有两个存储可以获得大量写入。它们是edgestore和graphindex。
无论是否配置复合索引，都始终写入edgestore KCVStore。边的每个边和所有边属性由两列表示（除非您将该边标签的模式设置为单向）。边列的关键是直接列中边的外顶点，反之是边的顶点。同样，边的列是直接列中边的顶点，反之是边的外顶点。每个顶点由VertexExists隐藏属性的至少一列表示，顶点标签的一列（可选）和每个顶点属性的一列。顶点的关键是顶点id，列对应顶点属性，隐藏顶点属性和标签。
只有在Titan管理系统中配置复合索引时，才会写入graphindex KCVStore。您可以索引顶点和边缘属性。对于具有该索引值的每对索引值和边/顶点，graphindex KCVStore中将有一列。键将是索引标识和值的组合，列将是顶点/边标识。
现在您已了解如何计算列，您可以使用此知识来估计在使用DynamoDB Storage Backend for Titan时对edgestore和graphindex的写入大小和数量。如果您对KCVStore使用多项数据模型，则每个键 - 列对将获得一个项目。如果您使用KCVStore的单项数据模型，您将获得一个键的所有列的一个项目（当启用图形分区时，这不一定是真的，但这是我现在不讨论的细节）。只要每个顶点属性小于1kb，并且边的所有边属性的总和小于1 kb，当使用edgestore的多项数据模型时，每列将花费1 WCU来写入。同样，如果您使用多项数据模型，则graphindex中的每列将花费1 WCU来写入。
让我们假设您做了估算，并且您始终使用多项数据模型。让我们假设您估计每秒会向edgestore写入750列，每秒写入750列到graphindex，并且您希望将此负载驱动一天。您可以将两个表的读取容量设置为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美元。
如果图中没有超级节点，或者具有相对大量属性的顶点，则对edgestore的写入将在整个分区键空间中均匀分布。这意味着当你的表达到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你删除了。）