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

Question

我想很好地了解使用DynamoDB Titan后端的价格(以$计).为此,我需要能够理解DynamoDB Titan后端何时进行读写操作.现在我很无能为力.

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

如果事实证明我无法自己提取这些信息,我将非常感谢有关DynamoDB Titan后端何时执行读写操作的第一个简要说明.

Answer 1

对于所有Titan后端,要理解和估计写入次数,我们依赖于估计给定KCVStore的列数.您还可以使用DynamoDB Storage Backend for Titan测量使用指标编写的列数.

要启用指标,请启用此处列出的配置选项.具体而言,启用第7-11行.请注意max-queue-length配置属性.如果executor-queue-size指标达到特定tx.commit()调用的max-queue-length ,那么您就知道queue/storage.buffer-size不够大.一旦执行程序 - 队列大小度量标准达到峰值而没有达到max-queue-length,您就知道已经捕获了正在tx.commit()调用的所有列,因此这将为您提供在a中更改的列数tx.commit().您可以查看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定价的另一个方面是存储.如果您每秒写入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你删除).