永远在线的时间序列数据库：跟上无法追赶的地方

2020年12月14日，第18卷，第6期极有可能您从未想过如何生成自己的数据库。而且，在可能需要做任何事情的情况下，您可能永远找不到自己。

但是，如果仅作为思想练习，请片刻考虑一下：如果作为核心业务需求，您发现需要提供从断开的操作中捕获数据的信息，这样，更新方可能会在不同的时间点进行更新。同一时间（或重叠的时间）没有冲突？而且，如果您的服务要求您整天几乎连续接收大量数据，以至于您由于担心发现自己远远落后于当前状态而无法在任何时候中断数据摄取，该怎么办？几乎没有办法赶上？考虑到所有这些，您是否可以使用任何可商购的数据库来满足这些要求？

对。那么，那将离开你呢？那你会怎么做？我们想与Theo Schlossnagle一起探讨这些问题，事实上，他确实建立了自己的时间序列数据库。作为Circonus的创始人和首席技术官，该组织在已经庞大且呈指数增长的IoT（物联网）设备上进行遥测分析，Schlossnagle有充分的理由进行这项投资。

Akamai全球绩效和运营的首席架构师Justin Sheehy向Schlossnagle询问了这项工作背后的想法以及在构建数据库的过程中做出的一些关键决策，以及在此过程中学到了什么。 AWS（Amazon Web Services）的高级应用科学家Chris McCubbin代表ACM进行了讨论。

贾斯汀·希尔（JUSTIN SHEEHY）作为曾经做出写我自己的数据库的可疑决定的人，我知道它可以证明是正确的做法，但对于大多数公司而言，我认为事实并非如此。这不仅是一个业务问题，而且还有一些有趣的工程方面的问题。那么，西奥（Theo），您为什么觉得需要编写自己的时间序列数据库？

THEO SCHLOSSNAGLE有很多原因。首先，流入我们的遥测分析平台的几乎所有数据都是随着时间流逝的数字形式。我们目睹了数据量和广度的指数级增长。实际上，根据我们的估计，在过去十年中，我们看到的增长幅度约为1x10 12。显然，计算平台还没有跟上这一步。存储成本也不会下降1x10 12倍。这就是说，我们经历的数据增长速度与存储和分析所有数据所需要的经济现实不符。

因此，我们决定创建自己的数据库的主要原因与简单经济学有关。基本上，最后，您可以解决任何问题，但省钱。似乎，通过限制问题空间，我们可以找到一种更便宜，更快速的解决方案，随着时间的推移，该解决方案将变得更加可维护。

JS您考虑过任何开源数据库吗？如果是这样，您是否找到了几乎满足您目的的任何东西，只是出于一些有趣的原因而拒绝了它们？另外，我很好奇您是否在环顾四周时发现了什么创新？ -或就此而言，您真正想避免的事情？

TS I受DynamoDB和Cassandra以及其他一些一致的哈希数据库（如Riak）的影响很大。正如我发现这些设计令人鼓舞一样，我也为他们的一致性哈希方法如何限制您可以使用受限数据集而感到沮丧。

我们想要的拓扑看起来与DynamoDB，Riak或Cassandra等一致的哈希数据库相似，但我们还希望进行一些小的调整，并且希望所有数据类型均为CRDT（无冲突的复制数据类型）。我们最终建立了CRDT专有的数据库。这从根本上改变了可能的方法，特别是围绕着如何向数据库写入过程。

还有其他一些细微差别。一方面，大多数一致的哈希系统在环网中使用vBuckets的概念，例如，您有15个主机和64个虚拟桶，数据属于该桶，最终由主机协商以确定它们中的哪个拥有哪个桶。

对于我们的系统，我们希望消除这种总体粒度。因此，我们实际上使用SHA-256作为哈希方案，并使用2 256个vBucket。结果，每个数据点的落入位置由节点和环落入的位置驱动，而不是由vBucket所有权驱动。

这样一来，我们便可以闯入所谓的＆＃34;双面环。在典型的一致哈希环中，您有一组主机，并且每个主机在环周围都有多种表示形式。相反，我们要做的是将环分成两半，其中环的第一个180度（环的第一个pi）包含一半的节点，另一个pi包含其余的节点。

然后，为了将数据分配给节点，我们使用了所谓的“跳过步行”。基本上，这使pi弧度在环上来回翻转，从而确保您从环的一侧到另一侧交替，这对于将环的一半放在一个AZ上是非常有利的。 ]，另一半覆盖到另一个区域或一个区域或另一个区域，或一个云或另一个区域。

使用CRDT的一个有趣方面（而不是达成共识就可以取得进展）是，它可以让您将一半的戒指放在石油钻井平台上，另一半放在Azure云中，然后每当VSAT时一切都正确同步[非常小的光圈端子]链接正在正常工作。这样一来，即使断开连接，您也可以拥有所有相同的特性和功能并保证。

JS I还对CRDT进行了一些工作，发现它们很有趣，因为您拥有可以由多方更新的数据类型（可能在多台计算机上同时或重叠时间更新）而没有冲突。由于更新是自动解决的，因此您无需传统数据库意义上的隔离即可确保一次只有一方能够对给定的数据结构执行事务。实际上，这可以任意发生，而且仍然可以解决。

另外，有多种方法可以解决此问题，无论是通过可交换性还是收敛性操作-请记住，在过去的10多年中，针对这些问题进行了大量研究。因此，您可以拥有一些共识的好处，而无需任何一方在任何时候都对同一数据采取行动。这就是为什么我认为这是令人兴奋的研究和实施领域。

CHRIS McCUBBIN这如何适用于最适合时间序列数据库的数据类型和操作？迄今为止，这是否甚至一直是CRDT研究的重点？

TS到目前为止，CRDT的许多研究都集中在非连续操作上，当然，当您考虑时间序列数据库时，这并不是想到的第一件事。但是，CRDT方法的真正优势在于，如果您可以将整个操作集限制为CRDT，则可以放弃共识算法，例如Paxos，Multi-Paxos，Fast Paxos，Raft，Extended Virtual Synchrony以及其他类似方法。这并不贬低任何这些算法。只要能够实现无仲裁的进步能力，他们就会带来很多不必要的负担。

有几个原因使CRDT极具吸引力地吸引了时间序列数据库。一个是大多数时间序列数据库，尤其是那些按我们的工作量工作的数据库，都是从机器而不是人员那里获取数据的。连接这些机器的网络通常很宽，我将其描述为“始终在线且可运行”。这意味着，如果您在数据库的接收端遇到某种形式的服务中断，那么每次宕机都会使恢复状态变得更加困难。

因此，如果发生断电，导致我的数据库失去仲裁一个小时，就不会像一旦恢复服务后马上就可以接机。首先，我将需要处理最后一小时的数据，因为随着时间的推移，无论系统的可用性如何，数据库接收端的负担都会继续累积。这就是说，为建立始终在线的数据接收建立时序数据库的强大动力非常强大，因为否则，如果服务中断或灾难性故障，您将在恢复故障时发现服务，您的状态将远远落后于现在，根本无法跟上。

JS听起来，出于深思熟虑的原因，您将一个非常棘手的问题换成了另一个问题，这意味着您摆脱了与共识算法有关的问题。但是，我了解到，许多所谓的CRDT实现实际上并没有达到该标准。我很想知道如何到达可以让您确信自己的数据结构实现真正符合CRDT要求的地方。

TS当然，很多CRDT确实很复杂，尤其是在它们表示某种复杂的相互关联状态的情况下。一个典型的例子是用于文档编辑，字符串插入和类似操作的CRDT。但是，绝大多数机器生成的数据都是一次写入，永不删除，永不更新，仅追加的变化。这就是当设备测量某个特定时间点的外观时，由幂等事务产生的数据类型。这是机器生成的数据中的幂等性元素，实际上使其易于使用简单的CRDT。

在我们的案例中，解决冲突是主要目标，因为对于时间序列数据，只能有一个与来自一个特定传感器的特定时间戳相对应的度量。为了确保这一点，我们使用了非常简单的架构来确保任何测量的最大绝对值都会获胜。如果出于某种原因，某个设备应在同一时间点为我们提供两个样本，则我们的系统将收敛于最大绝对值。我们还有带外使用的分代计数器。这仅仅是为了提供简单的冲突解决方案。

话虽这么说，在一年的时间里，当我们可能会有一万亿个样本进入时，我们通常会以零个实例结束而需要解决冲突，这仅仅是因为那不是那种数据机生成。

可以预见，Schlossnagle和他的团队在设计和开发时间序列数据库时并非从零开始。相反，他们希望了解可以使用哪些框架以及可以从哪些库中借用。

首先，他们确定了最关键的是什么，以及他们愿意做出哪些权衡。例如，他们知道他们需要将向前和向后兼容性作为基本要求，因为他们承受不起任何破坏数据摄取的事情。

他们还了解，将数据写入原始设备的实际问题将是最难解决的事情之一。因此，他们对数据库进行了设计，以使它实际上只在少数几个地方写入磁盘本身。取而代之的是，利用了许多现有的嵌入式数据库技术，并设计了系统内的优化路径，以利用这些数据库技术中的每一个，同时还可以解决它们各自的弱点。

JS很显然，您将CRDT视为解决您最重要的设计约束之一的一种方法：需要提供始终在线的数据提取。系统上是否还有其他约束影响您的设计？

TS我们已经第一手了解到，只要您有一个跨多个群集运行的系统，就不希望某些节点比所有其他节点都更为关键，因为这可能导致操作问题。这里的一个典型问题是类似于Hadoop基础结构中的NameNodes，或者基本上是任何类型的特殊元数据节点，这些节点需要比所有其他节点更多的可用性。我们绝对希望避免这种情况，以消除单点故障。这非常有助于我们的设计。

另外，虽然我们由于要获取一些真正的大批量遥测数据而专注于规模经济，但我说，我们没有尽早想到的一个挑战是我们后来如何设法在所有数据中找到东西。就是说，如果在一年的时间里有100万亿个样本进入系统，您将如何在所有这些东西中找到东西？您甚至将如何导航所有这些数据？

例如，在IoT领域中，如果您要从100亿个传感器中获取测量数据，那么您将如何基于跨分布式系统的元数据搜索来隔离从某些传感器获得的数据？我认为这通常不会给计算机带来特别艰巨的挑战，但是由于它不是我们为预先设计的，因此在实施过程中肯定会带来很多痛苦。

JS您很少听到人们谈论他们需要如何根据他们所学到的与最初的假设不符或暴露了某些未提供的东西（如您正在谈论的东西）来改变自己的方法。在这里。如果我对您的理解正确，那么最初您不包括探索性查询某些您认为次要的数据，只是后来才意识到它确实很重要。

TS那是一个公平的表征。更具体地说，让我们说，对于任何基于遥测的时间序列系统，您将需要在一系列传感器上附加一系列测量值。假设您正在衡量服务器上的CPU使用率。在这种情况下，您将拥有一个链接到一定数量的测量值的CPU的唯一标识符（无论是每秒，每分钟或十分之一秒），这些标识符表示该CPU的实际使用方式。

我们发现您在一个系统中可以包含多达1亿甚至十亿个这样的字符串，这意味着很难找到一个特定的字符串并进行探索。作为一个独立的计算机科学问题，解决起来并不是那么困难。

使事情变得复杂的是，这些字符串周围的元数据会随着时间不断变化。容器技术就是一个很好的例子。假设您将CPU使用率数据附加到在Kubernetes下运行的容器上，然后决定在一年中每天进行40次启动。这意味着，在您以前拥有1亿个流的地方，现在您的数量是[365天x 40次发布]的14,600倍，因此，您面临着真正的基数挑战。

JS鉴于您的系统始终处于运行状态，总是令人迷惑，并且显然需要为您的客户保护您存储的所有数据，我很好奇您如何处理版本升级。当您打算更改系统中一些根深蒂固的设计元素时，就不希望您可以完全重新启动。我本人已经处理过几次此类问题，所以我知道它会在多大程度上影响您的工程选择。

TS，我想您通常会在整个数据库计算中找到很多相似之处。在我们的案例中，因为我们知道完美的前向兼容性所带来的挑战，所以我们尝试确保各个版本之间的每次升级都尽可能地无缝，这样我们就不必重新构建整个系统。但是，更重要的问题是，我们真的无法承受任何摄取服务的中断，这意味着我们需要将向前和向后兼容性视为绝对的基本要求。当然，对于存储大量数据并且拥有广泛用户群的任何数据库，您都可以说相同的话。

Postgres是一个很好的例子，它确实在这个挑战中挣扎，因为每当您更改30 TB数据库的磁盘表格式时，除非执行以下操作，否则您都可以依靠某种长时间的中断复制和一些类似的事情带来了一些严重的魔力。尽管如此，我认为Postgres在过去几年中已经变得更好了，因为人们已经意识到，只要人们做出破坏兼容性的更改，大型数据库就会变得如此庞大，这些中断将持续多长时间。

JS而且，不仅需要担心向前和向后兼容性的存储。这些相同的关注点适用于您在系统中运行的所有节点，因为您不能让所有节点在同一时刻更改版本。另外，以我的经验来看，从工程的角度来看，兼容性问题要困难得多，因为从那时起，您或多或少一直都在使用它，而不仅仅是在需要升级存储时。

TS这绝对不仅仅是磁盘上的格式和功能。还需要考虑协议兼容性，特别是在复制和查询等方面。有一些框架，例如Google Protobuf [Protocol Buffers]和gRPC，其中包括一些为此提供的改进。我们使用FlatBuffers，具有讽刺意味的是，它也恰好来自Google。所有这些框架都有助于实现面向未来的兼容性。因此，您可以序列化数据并添加新字段，但是已经存在很长时间的人仍然可以在不了解所有这些新字段的情况下读取数据。而且，正是如此，即使缺少这些字段，新人们也能够读取旧数据。这无疑有助于减轻许多实施方面的问题。但是设计方面的问题仍然存在，因此我认为您需要采用这种方法。实际上，我很想了解行业中正在出现的解决如何应对这种前向兼容性挑战的最佳实践。

我的另一个保留意见是，这些框架尽管提供了所有优势，但往往是特定于语言的。如果有一种可以使您在Erlang中发挥良好作用的工具，那么对于在Go中工作的任何人来说，它都不会有太大帮助，就像为Rust编写的工具不一定一样将为必须在C环境中工作的人们做很多事情。当您考虑到不仅仅只有少数几种常用的生产系统语言存在时，就很容易看出这是如何使事情变得棘手的。

JS我完全同意，但是让我们回到特别推动时间序列数据库开发的方面。 我对了解您设法利用的任何现有事物特别感兴趣。 我们已经讨论了FlatBuffers，但是我想您可以利用其他一些软件甚至硬件。 TS首先让我说，FlatBuffers提供了一个很好的例子，因为它可以重用现成的解决方案以进行序列化和反序列化，这对于任何工程师来说都是最繁琐的任务之一。 不过，更重要的是，通过围绕所有内容提供一个不错的工具包，FlatBuffers还为网络提供了重要的向后兼容性和字节序保证，这是无价的。 这也适用于Protobuf和Cap'n Proto。 不过，我会说，我们对这些框架中的每一个都没有同样的迷恋 ......