s3 与 dynamoDB 的 gps 数据答案

【问题标题】：s3 vs dynamoDB for gps datas3 与 dynamoDB 的 gps 数据
【发布时间】：2017-03-24 23:08:59
【问题描述】：

我有以下情况，我试图找到最佳解决方案。设备每秒将其 GPS 坐标写入 csv 文件，并在开始新的 csv 之前每 x 分钟将文件上传到 s3。

稍后我希望能够获取特定时间段的 GPS 数据，例如 2016 年 11 月 11 日上午 8 点到 2016 年 11 月 11 日下午 2 点

以下是我目前正在考虑的两种解决方案：

使用 lambda 函数自动将 csv 数据保存到 dynamoDB 记录中
仅将元数据（csv gps timestamp-start、timestamp-end、s3Filename）保存在 dynamoDB 中，然后直接从 s3 请求文件。

然而，这两种解决方案似乎都有一个主要缺点：

gps 数据每条记录使用大约 40 个字节（秒）。因此，如果我使用 10 分钟的块，这将产生一个 24 kB 的文件。 dynamoDB 按项目大小对写入容量收费（1 个写入容量单位 = 1 kB）。因此，单次写入需要 24 个单元。读取（4kB/单位）甚至更糟，因为用户可能请求大于 10 分钟的时间范围。因此，对于涵盖例如的请求6 小时 (=864kB) 需要 216 的读取容量。考虑到多个用户，这太昂贵了。
当我直接从 S3 读取时，我遇到了限制并发请求数量的浏览器。例如，6 小时的时间跨度将涵盖 36 个文件。考虑到连接限制为 6，这可能仍然可以接受。但是 24 小时（=144 个文件）的请求将花费太长时间。

知道如何解决这个问题吗？

最好的问候，克里斯

【问题讨论】：

【解决方案1】：

如果 S3 密钥以合理的格式包含日期（例如 ISO：deviceid_2016-11-27T160732），您可以完全避免使用 DynamoDB。这允许您通过列出对象键找到正确的文件：https://docs.aws.amazon.com/AmazonS3/latest/dev/ListingKeysUsingAPIs.html。

（如果无法控制命名，可以使用 Lambda 函数重命名文件。）

请求数量是个问题，但您可以尝试在其前面放置一个 CloudFront 分配并利用 HTTP/2，它允许浏览器通过同一连接请求多个文件。

【讨论】：

这些都是好主意。在键中策略性地放置 / 字符可能更适合 S3 API 的前缀+分隔符对象列表逻辑。而且，当然还有 gzip，可以在上传之前在客户端完成，或者在文件进入时在后端使用 Lambda+S3 事件（节省存储空间），或者使用 CloudFront 即时完成（零努力，但可能不会-9 级压缩）。如果Content-Encoding 正确，Sane 用户代理将在下载时自动撤消压缩。

【解决方案2】：

您是否考虑过使用AWS Firehose？您的数据将定期被铲入 Redshift，就像 Postgres。您只需抽取一个 JSON 格式或一个 |分隔记录到 AWS Firehose 端点，剩下的就是 AWS 小精灵的魔法。

【讨论】：