为什么我应该使用时间序列数据库?
作者:Katy Farmer / 产品, 用例, 开发者
2018年3月1日
导航至
时间序列数据 是特殊的 — 不仅在于它捕获的独特数据,还在于我们与这些数据交互的方式。也许您开始使用来自您公司恒温器传感器的时间序列数据(最终证明爸爸在晚上调低了温度)或分析历史数据以预测市场价格。您做得非常出色。
但是,随着新型数据的出现,也带来了新的责任。时间序列数据是短暂且大量的,也就是说,它来得快,去得也快,而且数量巨大。这需要与其他类型的数据不同的存储和检索考虑因素。如果您想从关系型数据库的表中检索用户,您可以通过模式中的任意数量的属性进行查询:ID、姓氏、名字、地球、风与火乐队中最喜欢的成员。如果您想确切知道您的无人机(别名:Skynosaur)何时将坐标发回家,您也可以做到这一点。但并非没有权衡。
何时使用时间序列数据库
许多公司和个人都成功地将他们的时间序列数据存储在其他类型的数据库(关系型、noSQL)中。如果您是其中之一,您很满意,并且您目前没有任何问题,我绝不会要求您更改。您做您自己。
但是,使用专为您的时间序列数据设计的数据库肯定有好处。
可扩展性
可扩展性是我们经常听到的神奇词汇之一,并且 有时 使用是正确的。时间序列和时间序列数据库 之外的规模的一般问题是:如果 Skynosaur 飞行 1,500 小时(商业飞行员执照的最低小时数),我们已经为一个设备达到了超过一百万个数据点。Skynosaur 的制造商(Skynosaurus Rex, Inc.)可能拥有数千个设备将数据发回家。按时间戳查询将涉及关系数据库中的数百万行数据。
人们经常声称 SQL 数据库的可扩展性不好,而 NoSQL 数据库的可扩展性好,但在 ACID 与 BASE 方面,我更容易理解。不公平地总结一下,符合 ACID 标准的数据库关注保证有效性——数据应该是原子性的、一致的、隔离的和持久的。BASE 模型允许我们为了速度、规模或我们想要优先考虑的任何事物而放弃一些 ACID 原则。为了决定哪个系统有效,我们需要确定我们数据库的主要目的。
如果我们不关心持久数据,我们可以编写不刷新到磁盘的命令(这意味着数据可能无法在重启后幸存)。如果我们不关心原子性,我们可以缩短数据集锁定的持续时间。时间序列数据库通过提供适合时间序列数据的原则来平衡 ACID/BASE 关系。
例如,时间序列数据作为一个整体比作为单个点更有价值,因此数据库知道它可以为了更高的写入次数而牺牲持久性。Skynosaur 每五秒钟将数据发回家,因此如果我们丢失了 1,500 小时飞行时间中的一些数据点,我们的总体趋势仍然会保持完整。
在这种情况下,可扩展性意味着时间序列数据库专门处理更高的写入次数和最终一致性,即使在分布式存储中也是如此,并且这种专长意味着那些关心数据的人可以减少担忧。
易用性
如果我们的所有数据都存在于一个安全、持久的黑匣子中,我们可以松一口气。但是,我们访问数据的方式可能与其存储方式一样重要。每个数据库都有其查询语言,旨在尽可能高效地访问内容。请记住这一点,因为正如我们之前提到的,时间序列数据是特殊的。它是一个带有时间戳的双彩虹。
再次考虑向 Skynosaurus Rex 总部发送数据的 Skynosaur 大军。有数百万个数据点需要搜索,但现在我们有了一种专为手头任务构建的查询语言 — 不是查看数据与其他模式片段的关系,而是查看时间上下文中的数据,以便进行聚合、设置窗口或查看趋势。这与其他数据库是否能够做到这一点无关,而是与我们如何选择花费我们的资源有关。
权衡
数据库架构是关于权衡和优先级的。您需要速度还是准确性还是容量还是预定义的模式?证据在于基准测试。衡量一切。不要选择工具或产品 — 选择解决您问题的方案。专用工具是为特殊问题而制造的,因此时间序列数据库针对时间序列问题进行了优化。