物联网系统中，需要实时处理的数据可通过队列送入流处理引擎；不需要实时处理的数据，用于离线分析或数据挖掘，需要先存储起来。物联网系统的数据存储的方式很多，要根据实际场景来选择。
微博广告基础架构团队负责人、技术专家，商业大数据平台及智能监控平台发起人，目前负责广告核心引擎基础架构、Hubble智能监控系统、商业基础数据平台（D+）等基础设施建设。关注计算广告、大数据、人工智能、高可用系统架构设计、区块链等方向。在加入微博之前，曾就职于百度负责大数据平台建设，曾担任趣点科技联合创始人兼CTO等职位。毕业于西北工业大学，曾在国内外知名期刊发表多篇学术论文，拥有9项发明专利。
2021年11月22日，南方电网数字电网研究院有限公司发布《2021年南网数研院平台安全分公司数据中心升级完善二期（电能量平台融合改造、分节点云化等）项目存储计算组件和时序数据库采购公示公告》，采购方式单一来源。 项目概况：根据网公司云化数据中心主分节点建设安排，数据中心升级完善二期（电能量平台融合改造、分节点云化等）在原有数据中心升级完善一期项目及二期（数据湖、云化及服务组件层）建设的基础上，完善了数据中心数据处理及服务能力。本项目对数据中心存储计算组件进行扩容，新增913套存储计算组件，预算3652万元
2017年时序数据库忽然火了起来。开年2月Facebook开源了beringei时序数据库；到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了，而早在2016年7月，百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB，成为支持其发展制造，交通，能源，智慧城市等产业领域的核心产品，同时也成为百度战略发展产业物联网的标志性事件。时序数据库作为物联网方向一个非常重要的服务，业界的频频发声，正说明各家企业已经迫不及待的拥抱物联网时代的到来。 本文会从时序数据
2月19日，，就 Apache IoTDB 的核心技术及典型应用场景进行了直播分享探讨，分别是 Apache IoTDB：基于开放数据文件格式的时序数据库、IoTDB 在阿里云智能制造业务中的实践、智能运维场景中的时序数据库选型与挑战、时序数据库IoTDB在360的落地实践这4个主题。
12 月 3 日、4日，2022 Apache IoTDB 物联网生态大会在线上圆满落幕。大会上发布 Apache IoTDB 的分布式 1.0 版本，并分享 Apache IoTDB 实现的数据管理技术与物联网场景实践案例，深入探讨了 Apache IoTDB 与物联网企业如何共建活跃生态，企业如何与开源社区紧密配合，实现共赢。
今天分享一篇时序数据库Survey，《Time Series Management Systems: A Survey》，2017 年 TKDE 的。作者 Søren Kejser Jensen, Torben Bach Pedersen, Senior Member, IEEE, Christian Thomsen，丹麦奥尔堡大学。他们在 2018 年有一篇时序数据库的论文： ModelarDB：Modular + Model。
一、IoTDB的研发背景 (一)IoTDB的发展历程 IoTDB是由清华大学大数据软件团队于2016年开始开发的一个物联网数据库项目，旨在满足大规模物联网和工业物联网应用的数据、存储和分析需求。2018年11月，IoTDB进入了Apache孵化器，开始了它的开源之旅。在孵化期间，IoTDB吸引了来自全球的贡献者和用户，并与其他Apache项目如Spark和Hadoop进行了无缝集成。2020年9月，IoTDB正式成为Apache顶级项目，并获2020年北京市科技进步一等奖。2021年10月，IoTDB受邀参
原创文字，IoTDB 社区可进行使用与传播基于IoTDB 平台的学习和研究_应用_芯动大师_InfoQ写作社区
https://blog.csdn.net/ransom0512/article/details/78114167
在大型微服务架构中，服务监控和实时分析需要大量的时序数据。存储这些时序数据最高效的方案就是使用时序数据库 (TSDB)。设计时序数据库的重要挑战之一便是在效率、扩展性和可靠性中找到平衡。这篇论文介绍的是 Facebook 内部孵化的内存时序数据库，Gorilla。Facebook 团队发现：
Hive和HBase是两个在大数据领域中被广泛使用的开源项目，它们各自适用于不同的场景，但也可以在某些情况下结合使用。以下是Hive和HBase在不同场景下的应用示例：
数据库的模型包含关系型、key-value 型、Document 型等很多种，那么为什么新型的时序数据库成为监控数据存储的新宠呢？ 下面就会从
回想起来，第一次对文件格式有直接的认识，还是在很久很久以前那个MP3随身听流行的年代。那时候，一个MP3随身听的容量通常是128MB；一首.mp3格式的音乐大约为4MB。我是个杰伦粉，当时杰伦发行了大约60首歌曲，而我最大的愿望是在MP3随身听里存下所有杰伦的歌曲。很明显，128MB的随时听最多也只能存30首歌曲，苦恼的博主在一番探索之后，发现手里的MP3播放器不仅能播放.mp3的音乐，还能播放.wma格式的歌曲；而且，一首wma格式的音乐大小只有2MB！有了这个办法，我终于不用每周更换一次MP3里的歌曲了...
时序数据库，全称为时间序列数据库，主要用于处理带时间标签（按照时间的顺序变化，即时间序列化）的数据。这些数据主要由电力行业、化工行业、气象行业、地理信息等各类型实时监测、检查与分析设备所采集、产生。这些工业数据的典型特点是产生频率快（每一个监测点一秒钟内可产生多条数据）、严重依赖于采集时间（每一条数据均要求对应唯一的时间）、测点多信息量大（常规的实时监测系统均有成千上万的监测点，监测点每秒钟都产生数据，每天产生几十GB的数据量）。
复杂而又变化多端的中高频量价因子的研究和开发已经成为众多量化私募最重要的工作之一。DolphinDB作为一个一站式的时序数据存储、分析和实时计算平台，可以帮助金工和IT人员将复杂的因子快速转化成能在研发或生产环境中高效运行的计算机脚本。
为什么用关系型数据库？最常见的理由是别人在用，所以我也得用，但是这个并不是理由，而是借口。
先来介绍什么是时序数据。时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线，往过去看可以做成多纬度报表，揭示其趋势性、规律性、异常性；往未来看可以做大数据分析，机器学习，实现预测和预警。
智慧健康养老服务管理系统是北京怡养科技有限公司的建设项目，是内嵌智能家居、健康管理、综合评估、服务管理、呼叫中心、决策支持等模块在内的专业养老服务管理系统。基于老年人健康数据，以老年人综合评估管理和老年人风险预测分析模型与专家系统为技术支持，整合养老服务资源，为老年人提供精细化、专业化的照护管理计划和个人健康档案管理。
在上篇文章《时序数据库体系技术 – 时序数据存储模型设计》中笔者分别介绍了多种时序数据库在存储模型设计上的一些考虑，其中OpenTSDB基于HBase对维度值进行了全局字典编码优化，Druid采用列式存储并实现了Bitmap索引以及局部字典编码优化，InfluxDB和Beringei都将时间线挑了出来，大大降低了Tag的冗余。在这几种时序数据库中，InfluxDB无疑显的更加专业。接下来笔者将会针对InfluxDB的基本概念、内核实现等进行深入的分析。本篇文章先行介绍一些相关的基本概念。 InfluxDB
本项目由涛思数据投递并参与“数据猿年度金猿策划活动——2022大数据产业创新技术突破榜单及奖项”评选。
近几年IoT、IIoT、AIoT和智慧城市快速发展，时序/时空数据库成为数据架构技术栈的标配。根据国际知名网站DB-Engines数据，时序数据库在过去24个月内排名高居榜首，且远高于其他类型的数据库，可见业内对时序数据库的需求迫切。
我们知道zabbix在监控界占有不可撼动的地位，功能强大。但是对容器监控显得力不从心。为解决监控容器的问题，引入了prometheus技术。
InfluxDB是一个开源的、高性能的时序型数据库，在时序型数据库DB-Engines Ranking上排名第一。
TDengine 是一款开源、云原生的时序数据库，专为物联网、工业互联网、金融、IT 运维监控等场景设计并优化。它能让大量设备、数据采集器每天产生的高达 TB 甚至 PB 级的数据得到高效实时的处理，对业务的运行状态进行实时的监测、预警。
万物互联时代，工业物联网产生的数据量比传统的信息化要多数千倍甚至数万倍，并且是实时采集、高频度、高密度，动态数据模型随时可变。传统数据库在对这些数据进行存储、查询、分析等处理操作时捉襟见肘，迫切需要一种专门针对时序数据来做优化的数据库系统，即时间序列数据库。
【摘要】Gartner指出赋能边缘是2020年十大战略技术趋势之一，5G加速IoT领域的发展，物联网设备数据的收集，存储和计算需求与日俱增。Apache IoTDB是物联网时序数据收集、存储、管理与分析为一体的的软件系统。Apache IoTDB作为Apache的2020新晋顶级项目，以其出色的表现得到了Apache的认可！目前Apache IoTDB与Hadoop、Spark和Flink等进行了深度集成，可以完全胜任工业物联网领域的海量数据存储、高速数据读取和复杂数据分析的需求。本次分享将为大家对Apache IoTDB的前世今生和核心的技术进行详细介绍.
点击关注公众号，Java干货及时送达 来源：www.cnblogs.com/xiaoyuxixi/p/12235979.html 新公司要上监控，面试提到了 Prometheus 是公司需要的监控解决方案，我当然是选择跟风了。 之前主要做的是 Zabbix，既然公司需要 Prometheus，那没办法，只能好好对比一番，了解下，毕竟技多不压身。 但稍稍深入一点，我就体会到了 Prometheus 的优点，总结一下这两种监控方式。 两种监控工具的历史简介 Prometheus Kubernetes 自从
OpenTSDB(Open time series data base)，开发时间序列数据库。DB这个词很有误导性，其实并不是一个db，单独一个OpenTSDB无法存储任何数据，它只是一层数据读写的服务，更准确的说它只是建立在Hbase上的一层数据读写服务。行业内各种db都很多了，为什么还会出现它？它到底有什么好？它做了什么？别着急，我们来一一分析下。 其实OpenTSDB不是一个通用的数据存储服务，看名字就知道，它主要针对于时序数据。什么是时序数据，股票的变化趋势、温度的变化趋势、系统某个指标的变化趋势……其实都是时序数据，就是每个时间点上纪录一条数据。 关于数据的存储，我们最熟悉的就是mysql了，但是想想看，每5分钟存储一个点，一天288个点，一年就10万+，这还是单个维度，往往在实际应用中维度会非常多，比如股票交易所，成千上万支股票，每天所有股票数据就可能超过百万条，如果还得支持历史数据查询，mysql是远远扛不住的，必然要考虑分布式存储，最好的选择就是Hbase了，事实上业内基本上也是这么做的。（我对其他分布式存储不了解，就不对比了）。 了解Hbase的人都知道，它可以通过加机器的水平扩展迅速增加读写能力，非常适合存储海量的数据，但是它并不是关系数据库，无法进行类似mysql那种select、join等操作。 取而代之的只有非常简单的Get和Scan两种数据查询方式。这里不讨论Hbase的相关细节，总之，你可以通过Get获取到hbase里的一行数据，通过Scan来查询其中RowKey在某个范围里的一批数据。如此简单的查询方式虽然让hbase变得简单易用， 但也限制了它的使用场景。针对时序数据，只有get和scan远远满足不了你的需求。 这个时候OpenTSDB就应运而生。 首先它做了数据存储的优化，可以大幅度提升数据查询的效率和减少存储空间的使用。其次它基于hbase做了常用时序数据查询的API，比如数据的聚合、过滤等。另外它也针对数据热度倾斜做了优化。接下来挨个说下它分别是怎么做的。
这只是市场上主流数据库的一小部分，实际上还有很多其他数据库类型和实现。选择适合项目需求的数据库类型通常取决于数据模型、性能需求、可扩展性等因素。
近日，东方国信时序数据库CirroData-TimeS（基于Apache IoTDB）完成了与大连图扑TopLink组态软件的适配。在某核电站数据展示项目中，数据经过Toplink的解析，进入CirroData-TimeS时序数据库进行存储和计算。通过搭建场景和动画驱动，对压水堆核电站发电的工作原理进行了数据可视化展示。实现了CirroData-TimeS在工业数据可视化领域的生态建设，为工业物联网提供了全新的解决方案。
时序数据，是在一段时间内通过重复测量（measurement）而获得的观测值的集合；将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴；
近日，UCloud新发布了一款时间序列数据库UTSDB (UCloud TimeSeries Database) ，此次上线的UTSDB-InfluxDB版基于InfluxDB v.1.7，完全兼容原生 InfluxDB 协议。后端存储接入 UCloud 自研的Manul统一存储，容量可动态扩充，最高可至数百TB，并通过高效压缩节省80%存储成本。支持高并发写入，QPS最高可达350万，为物联网等领域的亿级设备提供实时监控生产数据、全局掌握数据趋势等能力。
作为腾讯唯一的时序数据库，CTSDB 支撑了腾讯内部20多个核心业务（微信彩票、财付通、云监控、云数据库、云负载等）。
伴随新能源物联网的发展，生产、分配、消耗等各个方面由设备及传感器所产生的时序数据量越来越大，严重挑战传统的以关系型数据库为核心的解决方案，数据处理性能低下、数据架构臃肿、存储成本高昂等问题频发，如何应对大数据量下的数据存储、查询、分析，成为了能源企业目前迫切需要解决的难点，数字化转型升级迫在眉睫。我所在的公司江苏阿诗特作为一家具有20多年储能逆变器和户用储能研发能力的企业，在此背景下也开始探索数据架构升级的有效路径。
cassandra虽然没被划分为时序数据库，只被分到了nosql，但是其优秀的性能以及灵活扩展作为一个时序数据库使用也没有什么问题，thingsboard就使用了cassandra作为时序数据存储引擎。
influxdb是一种时序数据库，时序数据库简而言之就是针对时间为KEY的数据存储系统。其可存储海量数据，并且查询性能非常强，可以用来做基于时间的应用，比如日志存储、温度计采集等。本文通过安装部署、以及简单实用，初步体验influxdb。
随着大数据时代的发展，诞生了一大批大数据时代下的新数据库产品，如今MongoDB、Redis、HBase这些NoSQL数据库已经成为了互联网开发的新标配，SQL一统江湖的时代不复存在了。
在本文中，我们将探讨如何设计一个可扩展的指标监控和告警系统。一个好的监控和告警系统，对基础设施的可观察性，高可用性，可靠性方面发挥着关键作用。
最近几年一直在使用监控系统，主要使用Zabbix和Prometheus 两个监控工具，对于这两个监控系统有一些使用实践方面的经验，通过对比的方式来和大家分享一下。
前言 随着Devops、云计算、微服务、容器等理念的逐步落地和大力发展，机器越来越多，应用越来越多，服务越来越微，应用运行基础环境越来多样化，容器、虚拟机、物理机不一而足。面对动辄几百上千个虚拟机、容器，数十种要监控的对象，现有的监控系统还能否支撑的住？来自于容器、虚拟机、物理机、网络设备、中间件的指标数据如何采用同一套方案快速、完整的收集和分析告警？怎样的架构、技术方案才更适合如此庞大繁杂的监控需求呢？ 上篇文章《建设DevOps统一运维监控平台，先从日志监控说起》主要从日志监控的方面进行了分享，本篇文章
如果一艘快艇足够承载下你的所有货物到达彼岸，那么你不需要使用一艘轮船出行。产品设计和技术选型也是一样，我们经常会说：“我需要一个能够处理百万规模并发读写操作的，低延时，高可用的系统。” 如果按照这样的需求去设计系统，你可能得到的是一个设计复杂，代价昂贵的通用方案。但是如果仔细分析一下需求，你可能省略了需求背后的一些前提条件，比如真实的需求可能是这样的：“我需要一个能够处理百万规模的并发（只是理论峰值，平均情况小于10万并发）读写操作（读写比例1:9，只有追加写，没有修改操作）的低延时，高可用的（可以接受一定程度数据不一致性的）系统。” 那么你可能可以为这个特定的需求设计一个简单的，高效又低成本的系统。
本文获文章作者授权翻译，转载需要注明来自公众号EAWorld 作者：Daniel Berman 译者：白小白 原题：Prometheus vs. Graphite: Which Should You Choose for Time Series or Monitoring原文：https://logz.io/blog/prometheus-vs-graphite/ 全文3742字，阅读约需要15分钟 任何系统、应用程序、产品或流程的关键性能指标之一是某些参数或数据点在一段时间内的表现。比如，如何在几秒钟
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
引言 因特网互联设备的发展，提供了大量易于访问的时序数据。越来越多的公司有兴趣去挖掘这类数据，意图从中获取一些有意义的洞悉，并据此做出决策。技术的最新进展提高了时序数据的收集、存储和分析效率，激发了人们对如何处理此类数据的考量。然而，大多数现有时序数据体系结构的处理能力，可能无法跟上时序数据的爆发性增长。 作为一家根植于数据的公司，Netflix已习惯于面对这样的挑战，多年来一直在推进应对此类增长的解决方案。该系列博客文章分为两部分发表，我们将分享Netflix在改进时序数据存储架构上的做法，如何很好地应对
我们可以将设备上行数据存储到关系型数据库中，我们需要两张带有时间戳的表（最新数据表 和 历史数据表），历史数据表存储所有设备上报的数据，最新数据表需要存储设备最新一条上报数据，这条最新数据相当于设备的当前状态。然后展示的时候只展示最新一条数据的状态，报表查询可以按照设备id和时间从历史数据表查询汇总。 这样是可以的，但是我们的最新数据表需要被频繁的更新，数据量少的时候没问题。但数据量大，并发高的时候就会出现问题。 1、存储成本：数据不会被压缩，导致占用存储资源。 2、维护成本：单表数据量太大时，需要人工分库分表。 3、写入性能：单机写入吞吐量难以满足大量上行数据的写入需求，数据库存在性能瓶颈。 4、查询性能：数据量太大导致查询性能受到影响。
什么是时间序列数据（Time Series Data，TSD，以下简称时序）从定义上来说，就是一串按时间维度索引的数据。用描述性的语言来解释什么是时序数据，简单的说，就是这类数据描述了某个被测量的主体在一个时间范围内的每个时间点上的测量值。它普遍存在于IT基础设施、运维监控系统和物联网中。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
