SimpleDB或DynamoDB的生存时间
问题描述：
我们的要求非常简单，我们希望为传感器存储GPS位置，该位置应该不会超过几天。数据的总粒度将在一分钟左右最大。SimpleDB或DynamoDB的生存时间
由于传感器总数可能超过10亿，除非我自己编写分区逻辑，否则SimpleDB不是一个选项。 SimpleDB通过索引每个属性，这使得可以在一段时间内运行一次定期清理脚本，删除大于2天的条目。
DynamoDB看起来好多了，因为它对数据量没有限制，我可以在sensorID +时间戳上使用分区+范围主键。但是，删除旧数据将需要扫描查询，除非我在时间戳字段上还有全局二级索引。使用这个二级全局索引，查询可能会更快。
难道只有我相信有更好的出路吗？使用DynamoDB/SimpleDB更好，因为整个部署都在AWS环境中，而且我们不想投入很多操作。我知道像Mongo DB这样的其他NOSQL数据库支持这些数据库。
答
您可以以日期为基础的表格保存条目，日期为x（s）增量。
GPS_LOCATIONS_09052016
GPS_LOCATIONS_09072016
...
然后，您可以每x天删除旧表格。
每个传感器有多少个GPS位置？如果你有例如5亿个独特的传感器，那么在传感器ID上分区并不是非常有效。
如果基于日期表不为你工作了，那么你就可以在timestampHash哈希键和timestamp范围密钥，其中timestampHash是1之间的数字y，y取决于您的数据大小创建一个GSI。然后，您可以对每个timestampHash和timestamp比现在更少或无论您设置清除参数，对GSI执行一次范围查询。 timestampHash将帮助您对数据进行分区以提高吞吐量。
我真的没有看到GPS位置如何**都具有相同的格式**将更好地存储在NOSQL数据库中。这实际上是数据的最佳定义，可以在表格中最好地存储，索引，检索和分析。 –
因为我会有数十亿的条目。我希望系统能够自动共享/分区，而不用担心。 它几乎听起来像任何人没有灵活的模式使用NOSQL是做错了，事实并非如此。 – Ouroboros
“数十亿同样形成的条目”**正是为什么你应该使用关系数据库，而不是无模式NOSQL。当你拥有数十亿个相同的数据点，但是你将它们存储为键值对时，是的，你不明白数据库的作用，以及为什么划分键值存储比分配硬要困难得多分区可排序/可索引表。 –