揭开AWS的Timestream数据库的面纱

AWS因不断推出新的云计算服务而闻名业界，不过AWS云计算服务太多了，客户往往难以了解所有的服务，AWS的数据库也不例外。

AWS至少提供15个数据库，最新的一个是Amazon Timestream，9月开始面向一般用户发布。Timestream主打 “物联网”应用，主要用于时间序列数据记录的存储和检索，时间序列指一组与时间戳相关的数据点。

Timestream与其他时间序列数据库一样用于那些产生连续数据流的应用，例如来自物联网传感器的测量数据，这些数据的格式可以快速插入和检索大量的时间序列事件，进而可支持复杂的分析——每天事实上可以有数万亿的事件，而且其速度比标准关系数据库快1000倍之多。

简单一点的时间序列数据可以是跟踪你每天走的步数，该数据还可以与一段时间内的体重联系起来，一些企业则需要做诸如跟踪和理解快速变化的数据（如股票价格、视频流或操作机器的温度）的业务，时间序列数据就是必须的。而且，物联网设备数目在不断激增，这种数据库也变得越来越重要，Timestream竞争对手，例如如开源的Prometheus、InfluxData Inc.的InfluxDB和Timescale Inc.的TimescaleDB的迅速崛起也说明了这一点。

亚马逊首席技术官Werner Vogels在上周在一篇博文中谈到Timestream背后的事情。他在接受记者采访时表示，Timestream在一定程度上表明了两点，其一，亚马逊的理念是为各种任务建立特定的云工具，而不是试图把这些都放在一个平台上，其二，它表明亚马逊公司基本架构的选择。下面是访谈对话内容（内容经过适当编辑修改）：

记者：你那篇关于Timestream的博文好像有个更大的目标，而不是仅仅是为了展示它如何工作。

Werner Vogels：我试图提供一点关于Timestream数据库背后的技术背景，以及一些我们正在建立的其他系统资料。在Timestream这一块我们做了一些独特的架构决定，这些决定可能也适用于一般架构。例如，我们用了基于单元的架构，可以减少影响半径。

另外，不要孤立地优化系统。你只是测量信息传递，或只测量存储，或只测量查询，这样的想法并不能给你一个整体系统做到真正能优化你想做的事情。

记者：Timestream和背后的想法是如何融入到AWS的整体云计算方法呢？

Werner Vogels：这是我们寻求建立专用数据库的一部分。对于很多工程师来说，关系型数据库是他们用来做各种事情的锤子。他们知道如何很好地使用这个工具。但在关系型数据库里做时间序列是个非常令人头痛的问题。而且很难做到实时性。毕竟，我们看到大多数时间序列应用的实时性的作用都颇为重要。

那我们一直在进行这种探索，Jeff Bezos多年前说过的一些话真正推动了我的架构原则。我们在构建工具，而不是构建平台。旧式平台的定义就是，软件公司发布下一个版本，给了你所有的东西，告诉你应该如何开发软件。

过了一段时间我们了解到，如果你构建的小工具真的是为了一个特定的目标而设计的，你可以对其进行优化，使得其性能更好或更可靠或实际上更便宜，或确保你能提高开发人员的生产力。

记者：时间序列数据库的目的是什么呢？

Werner Vogels：时间序列就是一个随时间变化的数据点序列。如果看一看我们周围的世界，大量的例子可以纳入时间序列。在许多应用里时间是个主导因素。例如点击流分析。你可能想要一个仪表盘，能实时告诉你正在发生的事情。在这一类的应用里，时间起的作用很重要。有个专门的数据库实际上能够让你实时访问当前的、即时的内存数据。

记者：Timestream是如何工作的呢？

Werner Vogels：Timestream下面有两个不同的存储引擎。其中一个在内存里，基本上就是最新的记录。时间序列数据库里的大多数记录都是当前时间记录。这一类用例涵括了许多当前的用例。然后历史数据则在磁性存储或SSD里。你可以设置一个策略，根据这个策略确定什么东西需要从内存中迁到历史引擎里。

内存存储的目标是那些非常快的查询。基本上你可以在几毫秒内分析几十GB的数据。历史存储更多考虑的是TB级、PB级以及那些需时数秒的查询类型。对客户来说，好处是他们不必考虑这个问题。他们不必考虑什么在内存里，什么在磁盘上。这对他们来说是透明的。

大多数查询都可以及时从当前数据上完成，你想在几毫秒内得到结果。如果是个预测引擎，用来查看你的冰箱里的液态天然气故障，你不想明天再做，你想要现在就做。另外仪表盘、报警、点击流分析等等，这一类至关重要的事情也是这样。

记者：Timestream与其他时间序列数据库有什么不同呢？

Werner Vogels： 我们亚马逊这里有个原则，我们对客户的平均延迟不感兴趣，因为平均延迟意味着我们客户的50%将经历更糟糕的体验，而且你不知道有多糟糕。包含了90%、99%的客户的体验才是我们真正关心的。你想要实时评测这个。在Timestream上建一个查询很容易，可以查过去5分钟或过去45分钟或过去1小时或过去45秒的数据，查询那些含90%或99%客户的体验数据。

Timestream毕竟还是个无服务器数据库，所以我们会照顾到性能和可靠性，我们会自动在多个可用区进行复制，会在背后进行扩展和缩减，安全方面也是。默认情况下做了加密，但你也可以用你自己的密钥。客户不必考虑这个问题。Timestream是个独特的数据库，各种时间场合都可以用，但不是关系型数据库。

记者：为什么时间序列数据库及其功能变得越来越重要而且现在至少更有可能实现了？

Werner Vogels： 客户正在建相当复杂的架构，特别是在物联网和DevOps管理领域。物联网是个大的用例，时间在这一块一直很重要。想象一下如果你有一个卡车车队，你想跟踪车队的载货情况、速度和油耗。如果想实时看到哪辆卡车比其他卡车消耗更多的汽油，那么Timestream在这里就变得很有用了。利用Timestream建立这样的系统可以非常简单。

记者：还有哪些例子涉及到公司使用时间序列数据库？

Werner Vogels： 如果看一下我们的客户，很大一部分是那些需要管理设备或客户参与的客户。Timestream大客户之一是Disney Plus。Disney Plus每天记录一批批数十亿的数据点，包括视频质量、缓冲、客户体验。我们有许多工业客户，如卡车运输或天然气生产或建筑业的公司，这些公司都使用时间序列数据库。

所有这些的主导属性是时间，特别是如果你想找到事情之间的相关性。Timestream自带一个标准的相关功能。例如，昨天的点击流比较你现在看到的点击流，是否有很大的变化？或者你可能会想知道你的客户今天怎么个来法，而你还把你的真实指标与之放在一起，看看和你的预测有多大差距？

Clean Air组织追踪世界各地的空气质量。你可能对昨天的空气质量感兴趣，但这是我所说的报告。它不只是一个数据点。例如，在时间序列数据库中有一个功能名为窗口，基本上是一个滑动窗口。比方说，你可以计算过去5分钟或5秒钟的平均空气质量……。我们在正常的SQL里加了相当多的函数，使得我们具有做这种时间序列的能力，可以真正地在时间上滑动，或在一定的时间段内找到相关性。

记者：Timestream如何与其他亚马逊数据库一起使用呢？

Werner Vogels： 时间序列数据库有三个部分。一个部分是将数据送到写入优化的内存存储里，然后在一段时间内迁移到到磁性存储里，然后就是查询引擎。但是需要将其放进去。Kinesis和Managed Kafka Service是将数据移入Timestream的两种方法。另外还有Apache Flink，是Timestream和其他数据库之间的一种连接器。

记者：那有些用户，比如说Oracle用户，有些用户不想使用这么多不同种类的数据库，他们怎么办呢？

Werner Vogels： 我认为完成一件事需要使用合适的工具。我们的许多专业人员都有一系列工具，这些工具正好能满足他们的这个目的。外科医生不只是有一把刀。他们有一系列的手术刀。他们不会搞混，他们知道使用完全适合的那把刀。如果他们带了一把锯子，你不会很开心吧。

我们作为软件工程师也是处于这样的处境。AWS现在有八或十种专用数据库，是一套数据库。客户可以在这么一套工具里准确地挑选合适的工具。这可以为他们节省资金，最重要的是，可以为他们节省开发人员的时间。如果我需要在一个关系型数据库的基础上建立一个时间序列操作，那么会花费我大量的精力和时间。即便这样，你甚至也不会拥有正确的可观察性工具，不能查看正在发生的事情。

记者：亚马逊是怎么想到会需要这么多不同的数据库？

Werner Vogels： 我们建的第一个新数据库是个键值存储数据库。为什么呢？那时是2004年12月12日，整个亚马逊都在关系型数据库上运行。有一次我们的大型机架集群发生故障，是一年里最繁忙的一天，整个网站都瘫痪了。这令我们想到，也许关系型数据库并不是适合所有事情的工具。

所以我们对所有的东西进行了深入的研究，结果发现亚马逊存储的70%是键值类。就只是一些给个购物车给我，给我这个，给我那个……就一个属性，给我这个属性的结果。所以我们想，等一下，我们可以为自己建立一个键值存储服务，实际上可以支持所有这些，并且服务还可以扩大规模，比用关系型数据库所能做到的可以更可靠。此外，要在三个不同的可用性区域或数据中心里维持关系型数据库运行真是一场噩梦。

我们曾经切断一个数据中心看看会发生什么。结果发现，所有的故障都是涉及关系型数据库的故障。再要把这个数据中心重新接入到实时运行就成了一场噩梦。

记者：亚马逊为此做了什么呢？

Werner Vogels： 我们建了DynamoDB。DynamoDB的一切服务都被管理，是第一个这样的服务。内部客户不需要考虑这个问题。我们用DynamoDB推出的第一个服务是购物车。

再举个例子，QLDB是我们的量子数据库分类帐服务。所有比特币操作的核心部分基本上是个不可变账本，是个分布式账本。但是我们的很多客户希望账本处于一个地方。如果你想在关系型数据库中做到这一点，无疑是场噩梦。

而如果你用上了这些特制数据库，开发就会变得非常简单。给了你所需要的正确工具，就可以提高开发速度，就是这么回事。