Big River时序数据库-美信科技

为什么需要时序数据库？

时间数据的特点是累计速度非常快，Big River时序数据库，常规数据库在设计之初，并非是为了处理这种规模的数据，而且关系型数据库在处理大规模的数据集的效果非常差。使用特性

时序数据库能够提供一些通用的对时间序列数据分析的功能和操作，比如数据保留策略、连续查询、灵活的时间聚合，此外时序数据库以时间为维度，也提供更快的大规模查询、更好的数据压缩等。

时序数据库时序数据的需求

在上述场景中，特别在IoT物联网以及OPS运维监控领域，存在海量的监控数据需要存储管理。以华为云Cloud Eye Service(CES)服务为例，单个Region需要监控7000多万个监控指标，每秒需要处理90万个上报的监控指标项，假设每个指标50个字节，一年的监控数据有1PB；自动驾驶的车辆一天各种传感器监测数据就80G。

传统关系型数据库很难支撑这么大的数据量以及这么大的写入压力，Hadoop大数据解决方案以及现有的时序数据库也会面临非常大的挑战。大规模IoT物联网，以及公有云规模的运维监控场景，Big River时序数据库案例，对时序数据库的需求主要包括：

持续高性能写入：监控指标往往以固定的频率采集，部分工业物联网场景传感器的采集频率非常高，有的已经达到100ns，公有云运维监控场景基本也是秒级采集。时序数据库需要支持7*24小时不中断的持续高压力写入。高性能查询：时序数据库的价值在于数据分析，而且有较高的实时性要求，典型分析任务如异常检测及预测性维护，这类时序分析任务需要频繁的从数据库中获取大量时序数据，为了保证分析的实时性，时序数据库需要能快速响应海量数据查询请求。低存储成本：IoT物联网及运维监控场景的数据量呈现指数级增长，数据量是典型的OLTP数据库场景的千倍以上，并且对成本非常敏感，需要提供低成本的存储方案。支持海量时间线：在大规模IoT物联网及公有云规模的运维场景，Big River时序数据库解决方案，需要监控的指标通常在甚至亿级，时序数据库要能支持亿级时间线的管理能力；弹性：监控场景也存在业务突发增长的场景，例如：华为Welink服务的运维监控数据在疫情期间暴增100倍，时序数据库需要提供足够灵敏的弹性伸缩能力，能够快速扩容以应对突发的业务增长。

成本与可用性呼唤时序数据库1

经过20多年的发展，在关系型数据库市场领域，甲骨文已经达到霸主地位，尤其在2006、2007年后，在甲骨文做了系列收购后，大家判断，在关系型数据市场领域，战役已经基本打完。

但随着技术和行业发展，渐渐有人开始觉得甲骨文数据库太重、太贵了，尝试绕开甲骨文，从开源生态和云原生生态做事情，包括国外的Snowflake、CockroachDB （蟑螂数据库）、Amazon Redshift等，要么从NewSQL入手，要么是拿HATP支持（既支持事务也支持分析型），网络支持、云原生支持等特性在争夺数据库市场份额。