时间序列数据库的简要介绍-InfluxDB，TimescaleDB和QuestDB
基于特定的业务需求和用例，从关系数据库中衍生出了大量新数据库。从内存中的键值存储到图形数据库，从地理空间数据库到时间序列数据库。在使用关系型数据库的一般解决方案不是很有效的情况下，所有这些不同类型的数据库都有特定的用途。
尽管有许多不同类型的数据库，但在这里我们将研究时间序列数据库-处理时间序列数据所需的数据库。
由时间间隔内某物的连续测量组成的数据是时间序列数据。
随着金融交易的现代化以及物联网的出现，对时序数据库的需求显而易见。股票和加密货币的价格每秒钟变化一次。为了测量这些变化的数据并对该数据进行分析，我们需要一种有效的存储和检索数据的方法。
随着物联网设备在我们生活中的空前渗透，物联网设备生成的数据每天都在增加。无论是汽车诊断，房屋的温度读数，迷路的狗的GPS位置，物联网设备无处不在。
物联网设备只能做一件事情，一件事情。通过设备上的传感器捕获信息，并将其发送到服务器进行存储。由于现有的通信协议对于这种轻量级的高频数据，流数据来说太复杂了，因此开发了MQTT来解决物联网的消息传递。
时间序列数据可以有两种类型-常规(通常基于测量)和不规则(通常基于事件)。
但是时间序列数据不仅限于物联网，它也渗透到整个互联网。捕获搜索引擎查询，主题标签，社交媒体帖子的病毒性等趋势也可以生成时间序列数据。它并没有就此结束。在由软件驱动的世界中，记录和审核安全性和合规性至关重要。所有这些数据也可以归类为时间序列数据。
专门设计时间序列数据库来处理由于捕获，存储和分析来自一个或多个上述来源的时间序列数据而引起的问题。因此，为简单起见，让我们将时序数据定义为：
- 高容量(来自测量的连续数据)
- 自然时间顺序(时间是必不可少的维度)
- 作为整个数据集(比单个记录)更有价值
有了这些信息，时间序列数据库应该能够存储大量数据，并具有大规模记录扫描，数据分析和数据生命周期管理的能力。如前所述，传统的事务数据库虽然可以用于存储，检索和处理时间序列数据，但是并不能充分利用可用资源。
特定的问题需要特定的解决方案。
现在，随着公司意识到这一事实，他们开始使用专门的数据库来解决特定的问题。这回到了我开始这篇文章所谈论的内容。在所有其他数据库中，时间序列数据库在过去两年中的采用率更高(截至2020年12月的数据)。
时间序列数据库使用率增加约2.5倍的主要原因是云和数据技术的融合，以及能够从较早的地方捕获数据的地方捕获数据的能力，即，汽车的引擎，冰箱，数十亿个设备的位置数据等等。除了新的来源外，公司还意识到某些较旧的来源毕竟并不真正适合事务数据库。所有这些都促进了时间序列数据库的广泛采用。
时间序列数据库
考虑到时间序列数据库的存在，让我们研究一下如果要尝试时间序列数据库可以采取哪些不同的选择。可以在DB-engines网站上找到完整的时间序列数据库列表。我将谈论其中的三个。
时序数据库
作为时间序列的PostgreSQL销售，它很快就引起了您的注意。默认情况下，PostgreSQL对任何东西都是一种赞美。借助超表和大块等新的体系结构，TimescaleDB在插入方面的性能提高了15倍以上，在查询性能上也有了显着提高。在这里阅读更多有关它的信息。
尽管没有像其他大多数时间序列数据库一样，主要的云提供商在云中没有针对TimescaleDB的完全集成的解决方案，但是TimescaleDB可以在所有这些数据库上无缝运行。例如，如果您的基础架构位于AWS中，并且您不想在Timescale Cloud中运行您的TimescaleDB实例，则可以使用EC2实例来安装官方的TimescaleDB AMI，也可以使用带有官方头盔图的AWS Elastic Kubernetes Services。
InfluxDB
与在PostgreSQL(关系数据库)中获得灵感的TimescaleDB不同，该数据库是从头开始编写的NoSQL时间序列数据库。尽管TimescaleDB具有站在被广泛接受和钦佩的关系数据库的肩膀上的优势，但InfluxDB却走了一条不同的道路。InfluxDB是时间序列数据库中的佼佼者，但根据TimescaleDB的研究，它在许多方面都无法击败TimescaleDB。
如果您想读一读有趣的文章，并想将这两个数据库都安装在系统上以自己了解一下，请转到Oleksander Bausk今天在他的博客上发布的这个有趣的比较。
话虽如此，InfluxDB具有很多功能。除了查询语言InfluxQL和Flux外，InfluxDB还开发了一种干净，轻量，基于文本的协议，该协议用于将点写入数据库。值得赞扬的是，其他时间序列数据库(例如QuestDB)已经采用了这种方法。
与TimescaleDB一样，InfluxDB也提供了开箱即用的云解决方案，但是您仍然可以决定在其中一个云平台上运行InfluxDB。例如，如果您在AWS上运行它，则将对CloudWatch指标，Grafana，RDS，Kinesis等具有本地支持。总而言之，一个非常好的数据库。由于它是一个相当新的事物，因此很难说它将与基于关系数据库的时序数据库竞争。
QuestDB
QuestDB是时间序列数据库列表中的最新成员，它是最新一批YCombinator之一。QuestDB的一些主要区别是列式存储，低内存占用，关系模型在时间序列上的使用以及可伸缩的无模式提取。与大多数时间序列数据库相似，QuestDB还使用官方AMI和Kubernetes Helm Charts在AWS上提供云部署选项。
QuestDB还采用了InfluxDB Line Protocol进行接收，而不必担心随着数据结构的变化而更改架构。作为列式数据库，QuestDB无缝处理新列的创建，因此支持无模式提取。
尽管在初期，QuestDB几乎提供了对ANSI SQL的完全支持以及对SQL方言的一些补充，但它创建了许多完全独特的功能，使其成为可行的替代品，可能比市场上的其他一些主要数据库更好。
结论
尽管还有其他几个数据库，但我现在只讨论了这三个数据库。从可公开获得的数据中可以明显看出，向时序数据数据库过渡到时序数据库。越来越多的公司将开始使用时间序列数据库作为其数据库堆栈的一部分，不一定取代关系数据库，而是增加了其数据功能。这就是为什么今年将不仅对时间序列数据库而且对市场上出现的所有其他专用数据库特别令人兴奋的原因。
原文链接：https://towardsdatascience.com/the-case-for-using-timeseries-databases-c060a8afe727
