SimpleDB 或 DynamoDB 的生存时间答案

【问题标题】：Time to live for SimpleDB or DynamoDBSimpleDB 或 DynamoDB 的生存时间
【发布时间】：2016-08-24 20:14:43
【问题描述】：

我们的要求非常简单，我们要为传感器存储 GPS 位置，并且不应该超过几天。数据的总粒度最大约为一分钟左右。

由于传感器的总数可能超过十亿，除非我自己编写分区逻辑，否则 SimpleDB 不是一个选项。 SimpleDB 为每个属性建立索引，这使得偶尔运行一次定期清理脚本成为可能，这些脚本会删除超过 2 天的条目。

DynamoDB 看起来要好得多，因为它对数据量没有限制，我可以在 sensorID+timestamp 上使用 partitioned+range 主键。但是，删除旧数据需要扫描查询，除非我在时间戳字段上也有全局二级索引。使用这个二级全局索引，查询可能会更快。

只有我相信会有更好的出路吗？使用 DynamoDB/SimpleDB 更好，因为整个部署都在 AWS 环境中，我们不想在运维上投入太多。我知道 Mongo DB 等其他 NOSQL DB 支持这些。

【问题讨论】：

我真的不知道如何将 GPS 位置（它们具有相同格式）更好地存储在 NOSQL 数据库中。这确实是可以在表中最好地存储、索引、检索和分析的数据的定义。
因为我将拥有数十亿个条目。我希望系统自动共享/分区，而不必担心。听起来几乎任何人在没有灵活模式的情况下使用 NOSQL 都是在犯错，但事实并非如此。
“数十亿个相同格式的条目”正是您应该使用关系数据库而不是无模式 NOSQL 的原因。当你有数十亿个相同的数据点，但你将它们存储为键值对时，是的，你犯了一个错误，因为不了解数据库的作用，以及为什么分区键值存储比对可排序/可索引表进行分区。
撇开关系数据库可能需要 8B 用于 ID，8B 用于时间戳，4B 长，4B 纬度 = 32Byte 用于整个条目这一事实，而您的键/值存储将需要它，加上十亿次存储相同键（或对相同键的引用）所需的存储量，加上具有一些树状结构来保存属于单个实体的键/值对的结构开销。如果您在键/值数据库中执行此操作，您的问题是令人难以置信的 RAM 和复杂性，如果在关系数据库中执行，则非常简单和高效。
因此，您甚至可能不需要在“正常”大小的平台上的关系数据库中进行分区来执行此操作。整个“旧条目必须死”的事情变得非常容易，因为表通常会朝一个方向增长，并且没有间接性。自动数据库维护例程会在使用过程中清理和压缩数据库，这些都不是您自己需要关心的事情。现在，再次解释一下，除了人们在 Twitter 上更频繁地提及它之外，为什么键/值还有其他优势？

标签： amazon-dynamodb amazon-simpledb ttl

【解决方案1】：

在 DynamoDB 中添加了一项新功能。请查看TTL

这将在特定项目的 TTL 过期后删除该项目。

【讨论】：

【解决方案2】：

您可以在基于日期的表格中以x 天为增量保存条目。

GPS_LOCATIONS_09052016
GPS_LOCATIONS_09072016
...

然后您可以每隔x 天删除旧表。

每个传感器有多少个 GPS 位置？例如，如果您有 5 亿个独特的传感器，那么根据传感器 id 进行分区就不是很有效。

如果基于日期的表不适合您，那么您可以在 timestampHash 哈希键和 timestamp 范围键上创建 GSI，其中 timestampHash 是介于 1 到 y 之间的数字， y 取决于您的数据大小。然后，您可以针对每个timestampHash 以及timestamp 小于现在的位置或您设置的清除参数的任何位置对该 GSI 进行范围查询。 timestampHash 将帮助您对数据进行分区以提高吞吐量。

【讨论】：