AWS TimeStream DB Summary

Keywords: Amazon, AWS, TimeStream, Time Stream, TimeSeries, Time Series, Database, TS, DB

What is AWS TimeStream DB

我们在本文档中简称 AWS TimeStream DB 为 “TS”.

首先 TS 是一个 “时序数据库 (Time Series DB)”. 所谓时序数据库就是数据的生成方式主要按时间递增, 并且基本上一旦生成就不怎么改变, 而查询方式也通常是基于时间, 并且最近的数据比旧数据通常更有价值. 在基于时间查询的基础上, 要有一些根据观测值过滤, 并且做一些聚合计算的功能.

其次 TS 是一个云原生数据库, 无需运维, 根据需求自动弹性伸缩. 你可以在几秒钟内就启动一个数据库并开始使用. 这也是它的重要卖点之一.

跟市面上其他的时序数据库比有什么优劣

优势

TS 是 “时序数据库” 的后起之秀, 它的主要优势还是云原生. 节约了用户大量的运维成本. 这里的运维成本除了配置集群, 硬件网络调优, 数据备份, 性能监控等. 如果自己做不仅要雇人, 还需要搭建许多子系统以及购买第三方产品. 更重要的是时间成本. 在 TS 里这些通通不需要, 你可以立刻开始使用, 而无需担心系统的性能问题和稳定性. 另外, 数据安全问题一直是热度很高, 落地很难. 而 TS 使用了 AWS 已经非常成熟的基础设置. 数据天生加密, 数据访问商能对数据能进行表级别的粒度管理.

劣势

TS 的数据模型是介于以 OpenTSBD 为代表的 metric-tag-value 模型, 和以 InfluxDB 为代表的 measurement-tag-field:value 这样的时序模型, 和以 TimeScaleDB 为代表的关系模型之间. 吸取了三个方向的优点, 做了一定的融合, 有着自己的创新. 性能并没有对极端场景做极致的优化, 而是折中的尽可能在各种场景下都有着不错的性能.

其他时序数据库比较

TODO

市场上占有率第一, 也最成熟的时序数据库是 InfluxDB. InfluxDB 是一个开源项目通过孵化器扩张成了一个创业公司. 其单机版本开源免费, 而集群版和企业版收费.

这里我们不对其数据模型做详细分析.

时序数据库技术选型

AWS TimeStream DB Pricing

Keywords: Price, Pricing, Cost

TS 是一个按需收费的数据库, 你用多少就花多少钱. 具体花费取决于四个维度:

  1. Writes:
    • 每次 Batch Write Records 写入的数据以 1KB 为单位向上取整, 每 1 million of 1KB 也就是 1GB 的数据写入收费 $0.5

  2. Queries:
    • 查询时每扫描 1GB 的数据收费 $0.01

  3. Memory Store:
    • 存在内存中的热数据每 GB 每小时 $0.036

  4. Magnetic Store:
    • 存在磁盘上的冷数据每 GB 每个月 $0.03

举例来说:

你的业务是移动运营商基站设备监控:

  • 每条数据有 10 个 Measurement, 平均一个 key value pair 有条数据有 20 个字符串, 那么一条数据就是 0.2 KB.

  • 每台设备每 10 秒进行一次测量, 也就是平均每小时进行 6 * 60 = 360 次测量, 一共 360 * 0.2 = 72 KB / Hour.

  • 你遍布全国 50 个 State, 每个省 20 个 City, 每个 City 100 个设备, 一共 50 * 20 * 100 = 100,000 台设备.

  • 这些设备每小时生成 72 KB * 100,000 = 7.2 GB 数据.

  • 你希望对一周内的数据进行实时分析, 由于工作日, 放假等误差, 你希望保证 10 天内的数据为热数据.

  • 因为每个月你需要生成一次当月统计, 考虑到各种误差, 延迟, 你希望所有数据在磁盘上保存 2 个月, 以供聚合分析.

  • 对于超过 2 个月的数据, 你希望将其导出到廉价存储例如 S3 Glacier 上, 这部分的开销跟 TS 数据库比可以忽略不计.

  • 假设你的业务监控的时间粒度是 1 分钟, 也就是有情况发生后一分钟需要监测到. 这就意味着每 1 分钟就需要 Run 一个 Query 扫描数据. 一分钟所有设备会产生 0.12 GB 数据, 也就是每次扫描都需要扫描 0.12 GB 数据.

  • 然后你需要每隔一个小时对最近一周内的滚动窗口数据进行汇总聚合统计. 这就意味着每 1 小时就要 Run 一个 Query 扫描 7 天的数据. 也就是每 1 小时要扫描 7.2 GB * 24 * 7 = 1209.6 GB 的数据.

我们来计算一下每个月的花费:

  • Writes:
    • 每个月产生了 7.2 GB * 24 * 30 = 5,184 GB 数据

    • 写入花费: 5,184 * 0.5 = $2,592

  • Memory Store:
    • 平均在内存中驻留的热数据为 7.2 GB * 24 * 10 = 1,728 GB

    • 热数据存储花费: 1,728 * 24 * 30 * 0.036 = $44,790

  • Magnetic Store:
    • 平均在磁盘中驻留的冷数据为 10,368 GB

    • 冷数据存储花费: 10,368 * 0.03 = $311

  • Query:
    • 每分钟监控:
      • 平均每个月要执行 24 * 60 * 30 = 43,200 次查询, 一共扫描了 5,184 GB 数据

      • 扫描总花费: 5,184 * 0.01 = $52

    • 每小时统计:
      • 平均每个月要执行 24 * 30 = 720 次查询, 一共扫描了 720 * 1209.6 GB = 870,912 GB 数据

      • 扫描总花费: 870,912 * 0.01 = $8,709

由以上分析可知, 主要的花费用在了热数据存储, 以及对大部分的热数据进行扫描查询上. 所以你在构建时间序列数据的应用时, 要仔细分析到底需要多少数据是热数据.