我想很好地了解使用 DynamoDB Titan 后端的价格（以美元计）。为此，我需要能够了解 DynamoDB Titan 后端何时进行读写。现在我很无知。
理想情况下，我想运行一个添加一些顶点、边的测试用例，然后进行相当简单的遍历，然后查看完成了多少次读取和写入。关于如何实现这一目标的任何想法？可能通过指标？
如果事实证明我自己无法提取此信息，我将非常感谢您先简要说明一下 DynamoDB Titan 后端何时执行读取和写入。
【问题讨论】：
标签： amazon-dynamodb titan
对于所有 Titan 后端，为了了解和估计写入次数，我们依赖于估计给定 KCVStore 的列数。您还可以在使用 DynamoDB Storage Backend for Titan 时使用指标来衡量写入的列数。
要启用指标，请启用here 列出的配置选项。
具体来说，启用第 7-11 行。
请注意 max-queue-length 配置属性。如果executor-queue-size metric 达到特定tx.commit() 调用的最大队列长度，那么您就知道队列/ storage.buffer-size 不够大。一旦 executor-queue-size 指标达到峰值而没有达到 max-queue-length，您就知道您已经捕获了在 tx.commit() 调用中写入的所有列，因此这将为您提供在 tx.commit() 中更改的列数.您可以查看 edgestore 和 graphindex 的 UpdateItem 指标，以了解列在两个表之间的分布情况。
所有 Titan 存储后端都实现了 KCVStore，键和列的含义根据存储的类型而有所不同。假设您没有打开用户定义的事务日志，有两个存储会获得大量写入。它们是 edgestore 和 graphindex。
无论您是否配置复合索引，总是会写入 edgestore KCVStore。每条边和该边的所有边属性由两列表示（除非您将该边标签的模式设置为单向）。边列的键是直接列中边的出顶点，反面中边的入顶点。同样，边的列是直接列中边的入顶点，反面是边的出顶点。每个顶点至少由 VertexExists 隐藏属性的一列、顶点标签（可选）的一列和每个顶点属性的一列表示。顶点的键是顶点id，列对应顶点属性、隐藏顶点属性和标签。
只有在 Titan 管理系统中配置复合索引时才会写入 graphindex KCVStore。您可以索引顶点和边属性。对于每对索引值和具有该索引值的边/顶点，graphindex KCVStore 中将有一列。键是索引 id 和值的组合，列是顶点/边 id。
现在您知道如何计算列数，您可以利用这些知识来估计在使用 Titan 的 DynamoDB 存储后端时写入 edgestore 和 graphindex 的大小和数量。如果您对 KCVStore 使用多项目数据模型，您将获得每个键列对的项目。如果您为 KCVStore 使用单项数据模型，您将在一个键处获得所有列的一项（启用图形分区时不一定如此，但这是一个我现在不会讨论的细节）。只要每个顶点属性小于 1kb，并且一条边的所有边属性之和小于 1kb，当使用多项数据模型进行边缘存储时，每列将花费 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你删除）。
【讨论】：