时序数据库_个人页_阿里云开发者社区

提交了问题 2019-05-31

GDB的性能怎么样

提交了问题 2019-05-31

mysql ibdata1文件被undo log日志占了几百个G。

提交了问题 2019-05-31

问个问题，DBMS的登录必须前置阿里云登陆吗？

提交了问题 2019-05-31

咨询下RDS for postgresql高可用版在主实例出现故障无法访问时，会自动切换到备用实例，这个是如何来判定故障的呢？判定故障立即切换还是会根据预定义的主备切换时间取切换呢？https://help.aliyun.com/document_detail/96747.html?spm=5176.2020520104.108.2.2b4b1450OM1hSC 治富

提交了问题 2019-05-31

phoenxi写进去的主键id=1数据，在hBase中rowkey被转换为\x80\x00\x00\x01

提交了问题 2019-05-28

咨询下RDS for postgresql高可用版在主实例出现故障无法访问时，会自动切换到备用实例，这个是如何来判定故障的呢？

提交了问题 2019-05-28

phoenxi写进去的主键id=1数据，在hBase中rowkey被转换为\x80\x00\x00\x01

提交了问题 2019-05-28

菜鸟问题

提交了问题 2019-05-28

阿里的tsdb与influxdb，两者比较，优缺点是什么？以后的发展路径是什么样的？

提交了问题 2019-05-23

用 SQL 在一个有几亿条记录的库表里插入一个字段（如：Minute），有没有更好更稳定的办法？我们这里总返回失败

提交了问题 2019-05-23

TSDB的httpapi支持压缩上传吗

提交了问题 2019-05-23

TSDB在控制台上好像没有直接导出到对象存储的工具吧

发表了文章 2019-05-21

【直播预告】阿里巴巴高级算法工程师麦慧君：阿里云时序数据库TSDB For InfluxDB®介绍

主讲人：麦君本名：麦慧君中山大学学士/香港大学博士阿里巴巴高级算法工程师专注于时序数据库研发，时序数据压缩，硬件加速和数据库查询性能优化等内容概要：主要讲解时序数据和时序数据库的特性，介绍目前DB-Engines排名第一的时序数据库InfluxDB，以及阿里云时序数据库InfluxDB®的特点和优势，详细讲解如何使用InfluxDB®管理时序数据，包括数据收集与存储、数据查询和可视化。直播时间：2019年5月23日周四 19:00直播地点：阿里数据库技术交流群直播回放观看：https://yq.aliyun.com/live/1110PPT下载地址：https://yq.aliyun.com/download/3561 详情请看下方图片：想看免费直播的提前扫码入群以下为云栖社区的官方云栖号：阿里云时序时空数据库（点击关注）扫描下方公众号二维码可获得更多活动资讯：

提交了问题 2019-05-20

maven引入phoenix一直报错！

提交了问题 2019-05-17

GDB有事务性吗

提交了问题 2019-05-15

已经创建文件夹但是数据写入失败

提交了问题 2019-05-14

请问下 hitsdb /api/put 接口一次性请求最多能写多少个datapoints？

提交了问题 2019-05-14

mysql 只有几百条数据的update 更新了10s一般是什么问题，我查询了锁表，机器的io都没发现问题

发表了文章 2019-04-24

《K8s监控神器——TSDB for Prometheus的入门与实践》

直播时间 2019年4月25日 19:00 - 19:40（30分钟分享+10分钟答疑）主讲人胡建洪(花名：莫趋)阿里云智能-数据库产品事业部技术专家内容概要 Prometheus作为云原生监控的首选工具，其单机部署的架构设计在提供稳定性和易用性的同时，也使得数据存储受限于单节点的存储大小。阿里云TSDB针对这一痛点，为用户提供了易用性高，稳定性强，性价比优的存储技术方案。本次技术分享中，我们会展示如何配置阿里云TSDB作为Prometheus远程存储的流程，并量化展示本方案达到的查询吞吐高，延迟低，性能按需弹性扩展等优势。关注Prometheus的你，请千万不要错过本次技术分享。直播地址阿里数据库技术交流群扫码入群观看直播

发表了文章 2019-04-17

数据库技术之《OpenTSDB简介以及同TSDB的差异》

直播时间 2019年4月18日 19:00 - 19:40（30分钟分享+10分钟答疑）主讲人吴兴博（花名：兴博）阿里云智能-数据库产品事业部技术专家内容概要 OpenTSDB是可扩展的分布式时序数据库，底层依赖HBase。作为基于通用存储开发的时序数据库典型代表，起步比较早，在时序市场的认可度相对较高。阿里云智能TSDB高度兼容OpenTSDB协议，采用自研的索引，数据存储模型，流式聚合等技术手段提供更强大的时序能力。本课程从主要介绍OpenTSDB以及同阿里云智能TSDB多个角度的对比差异。直播地址阿里数据库技术交流群钉钉扫码观看直播

发表了文章 2019-04-10

数据库技术之《TSDB采集和展示方案》

直播时间 2019年4月11日 19:00——19:40 主讲人伊翼（花名：老滚）阿里云智能-数据库产品事业部技术专家，从事 TSDB 核心引擎的研发工作内容概要时序时空数据库TSDB以其强大的功能和兼容性，对于当前的一些开源解决方案实现了较好的适配, 本课程会介绍TSDB的一些基本概念：指标，维度，时间线等等，以及与一些开源组件或开源项目对接的方法，包括：Grafana对接TSDB， Telegraf对接TSDB， Tcollector的对接。直播地址阿里数据库技术交流群钉钉扫码观看直播

发表了文章 2019-03-07

时序数据在滴滴实时数据开发平台中的处理和应用

本文根据演讲视频以及PPT整理而成。本文将主要围绕以下三个方面进行分享：背景简介技术方案当前现状一、背景简介滴滴实时数据开发平台源于这样的初衷，即构建业务监控的双眼，用以监控发生的时事对系统业务交易量是否产生影响。此外，数据可能存在异常和波动，直接监控数据较为低效，时序数据还用以实时报警，帮助相关运营人员排查情况。实时监控和实时报警是滴滴数据管理的两个最核心场景。 2015年以前，滴滴数据管理的架构非常简单。通过扫描Mysql的从表和api数据进行预计算，预计算的操作结果先存储于本地文件，再定时上传到CKV数据库。以计算城市订单量为例，一级目录是城市id，二级目录是日期，预计算的操作结果先按照目录结构存储于本地文件，再定时上传到CKV数据库中。这种简单架构的瓶颈是显而易见的，即指标开发和扩展的难度较大。随着指标增多，在Mysql中维系配置越来越麻烦，并且往往牵一发而动全身。扩展目录也非常麻烦，以增加产品线维度为例，在原来的一级目录和二级目录之间增加产品线维度要求本地文件目录和数据库都需要修改，存储和计算成本呈指数级别增长。问题的根本原因在于，这种架构无法保证数据的及时性和稳定性。链路的延迟以及使用脚本扫描数据使得数据量越大数据查询越慢，数据及时性较差；通过api或者数据库查询无法保证不重不漏地消费数据，数据稳定性较低。从2015年开始，滴滴针对数据及时性和稳定性两方面进行优化。滴滴数据管理的流程分为几个阶段，首先输入业务数据，对数据进行加工和存储，再经过查询输出相关指标。2015年以前，数据管理平台使用app请求实现所有连接，不仅影响系统的吞吐性能，还可能存在数据遗漏。2015年之后，滴滴引入了消息队列实现连接，利用消息队列的数据吞吐量优势和ack机制降低了链路时延，同时保证了链路的稳定性。此外，还将数据加工替换为实时计算引擎，进一步降低系统时延。查询指标涉及到数据计算，数据计算可以在业务数据加工时进行，可以在数据存储时进行，也可以在数据查询时进行。数据计算越迟进行，前期数据的复用率越高，因此滴滴选择在数据查询时进行数据计算。比如，查询实时订单呼叫量时，在数据加工处进行数据计算并存储，在新增实时订单应答量时，仍需开发新的实时任务进行计算；实时集群的资源是有限的，如果每开发一个指标都新增一个实时任务，将会带来极大的资源浪费。假如在数据加工时进行ETL清洗，在数据存储时仅存储简单的订单表，而在数据查询时才进行数据计算就可以复用之前数据计算的结果，从而节省集群资源。这对数据库的查询和存储能力提出了较高的要求。传统的事务型数据库仅针对事务，而不针对数据分析场景，因而不适用于时序数据查询，针对此，滴滴引入了OLAP引擎。由于所有业务数据都具有时序特点，滴滴选择了KAFKA+SMAZA+DRUID的OLAP引擎。下图展示了2015年到2017年初的架构图，所有线上业务数据使用Kafka进行实时数据流存储，经过实时计算加工，再写回Kafka。然而，这存在开发周期过长，开发语言复杂，现有人力成本跟不上业务需求变更的开发瓶颈。同时，还存在调用链路较长，实时数据资产管理混乱等缺点。为了应对此开发瓶颈，滴滴致力于实现实时数据管理的一体化平台，允许全公司共同参与数据的采集、加工和存储等工作。由此，滴滴构建了实时计算开发平台Woater，以实现降低开发难度、实时资产管理等优化目标。二、技术方案下图展示了2017年至今，滴滴实时计算开发平台采用的技术框架。Mysql的数据从表通过Canal采集，文本日志通过Swan采集，采集到的数据存储于Kafka Topic中。实时计算引擎层引入了Spark Streaming和Flink，对采集到的数据进行数据加工，再写入Druid中。此外，平台还引入了离线数据，使用HIVE将其与实时数据结合，提高了消息队列的数据查询能力。当数据写入Druid Datasource后，平台会生成所有数据的模板，并落地存储，开放给所有用户使用，开放的功能包括实时监控、报警服务等。此外，平台还允许用户自定义功能，比如根据实时应答率动态调节产品价格等。另外，滴滴实时数据开发平台还提供了血缘管理、权限管理两个支线功能。血缘管理将平台所有资产，包括Kafka任务和api等实时写入血缘管理模块，方便用户查看任意数据的上下游流动情况。数据开发平台的每个模块都相互解耦，因此滴滴还为每个模块都实现了权限管理功能。 Druid是针对时序数据提供低延时的数据写入以及快速交互式查询的分布式OLAP数据库。在数据写入时，由用户发起实时数据写入任务，通过overload节点将任务发布到各个MiddleManager节点上，MiddleManager节点进而发起子任务，实时拉取数据并存储到Deep Storage中，保证了历史数据的高可用。Druid支持的Deep storage类型包括Amazon S3, HDFS等任意文件系统。在数据查询时，来自客户端的请求首先到达Broker节点，由Broker节点查询全局的数据分片拓扑图，从而将查询拆分成若干子查询，涉及到实时数据的子查询由MiddleManager节点执行，涉及到历史数据的子查询由Historical节点执行，子查询结果在Broker节点汇总并返回给前端。 Druid针对时序数据的存储与查询进行了多项优化。在数据分片设计方面，Druid将所有数据分成了三个属性，包括时间戳，维度和指标。时间戳和指标都采用整数型或者浮点型进行本地存储，因此具有很高的压缩比。字符串数据在本地存储时不会直接存储为字符串格式，而是将其生成映射表。以属性维度的Page为例，映射表可能将“Justin Bieber”映射为0，将“ke$ha”映射为1，那么Page列数据在数据库中将存储为“0011”，因而也具有较高的压缩比。为了加快查询，Druid还为每个值维系一个倒排索引，比如，“Justin Bieber”在Page列的倒排索引为“1100”，“ke$ha”在Page列的倒排索引为“0011”。在查询Page等于“Justin Bieber”时，只需挑选索引中为“1”的项。在进行多列筛选时，只需将各列的索引进行异或计算，比如要查询Page等于“Justin Bieber”且Username等于“Reach”的数据项时，按照倒排索引逻辑，仅需将“0100”和“Justin Bieber”的倒排索引进行异或。下面列出了Druid的主要优化方法。一方面，Druid采用列式Segment进行存储，另一方面，它采用基于字典的编码对维度列进行压缩，从而提高压缩比。此外，Druid还引入了Rollup聚合存储机制，允许用户自定义数据聚合规则，提高数据的查询效率。优化后的Druid实现了数据实时可查询，同时提供亚秒级的查询效率，99%的数据查询可以在1秒内返回结果，这对于拥有700+数据源和日均查询量近2000千万的集群而言非常难得。此外，Druid还将数据压缩到了其原始大小的1/30，实现了极高的压缩比。然而，Druid存在数据加工能力较弱的缺点，仅依赖Druid很难实现两个表的Join操作。滴滴实时数据开发平台的解决方案是在数据加工层引入主流的SparkStreaming和Flink技术，二者代表了实时计算引擎的两种不同设计方向。Spark Streaming以Spark引擎为基础发展而来，将基于离线数据的批计算压缩为微批操作，使其变成近乎实时的计算。Spark生态具有极高的活跃度，对Spark相关技术熟悉的人员可以快速上手Spark Streaming。Flink适用于低延迟的数据处理场景，支持实时处理数据，同时支持从下至上兼容批处理。此外，Flink还能够提供“exactly once”的实时处理方案和不重不漏的数据消费。在开发方式方面，滴滴实时数据开发平台提供了多种用户操作以适应更多用户。针对具有流基础的用户，平台提供了Web IDE,支持在线开发编译，在线提交配置，减少了本地配置开发环境的困难。针对具有编程经验的用户，平台提供了StreamSQL和DruidSQL，StreamSQL允许用户使用SQL方式进行数据加工，降低用户的平台上手难度，DruidSQL可用于Druid相关的查询同时帮助用户进行在线调试。此外，滴滴还提供了可视化拖拽等功能帮助指标查询，方便初级用户。三、当前现状目前，滴滴实时数据开发平台提供的实时监控功能已覆盖滴滴的全部核心业务线，包括国内和国际化业务。提供的实时监控服务实现了秒级延时，支持每秒刷新。另外，滴滴团队还对底层Druid进行了优化，实现了99.995%的可用性。滴滴实时数据开发平台的这些能力针对平台的所有用户全部开放。在异常报警方面，根据实时的血缘链路，滴滴实时数据开发平台承诺实现的准确性达到3次误报，1次漏报。在异常报警时，平台将筛除数据正常范围的延迟、抖动和链路异常，减少误报率。在及时性方面，滴滴实时数据开发平台承诺能在1分钟内快速响应问题。同时，滴滴实时数据开发平台还提供了大中小屏可视化方案，从而为用户提供更丰富的图表和更灵活的配置方式。

发表了文章 2019-03-06

阿里巴巴双11千万级实时监控系统技术揭秘

演讲嘉宾简介：柴武，阿里巴巴高级开发工程师，有多年APM SaaS产品研发经验，曾经使用过多款业界主流时序数据库产品，包括Druid、ClickHouse、InfluxDB等。对时序数据库领域有多年经验，目前负责阿里巴巴TSDB核心引擎开发。本次直播视频精彩回顾，戳这里！https://yq.aliyun.com/live/863以下内容根据演讲嘉宾视频分享整理而成。本次的分享主要围绕以下三个方面：一、时序业务全景二、TSDB 介绍三、核心技术四、总结展望一、时序业务全景TSDB自2016年开始服役，到现在已经三年了，参与了三次阿里巴巴双11大促。2016年是 TSDB 元年，2017年开始在阿里巴巴内部做大规模推广。下图展示了2017年和2018年大促状态下TSDB吞吐表现。写入的峰值从2017年的2000w TPS到2018年有了翻倍的增长，增长到了4000w TPS。查询峰值从8000 QPS转到了2w QPS。这些都是阿里巴巴核心业务的吞吐量情况，日均有800TB的时序数据，累计超过了数百亿的时间线，覆盖了集团130+的业务。时序业务覆盖场景时序业务覆盖的场景从基础设施到上层应用，覆盖各个主要系统层面。基础设施层主要负责物理机器和操作系统的监控。基础运维层包括Sunfire，云监控和GOC。Sunfire是阿里巴巴统一监控和日志采集报警系统；云监控是阿里云上统一的监控系统；GOC是全球应急调度指挥系统，包含报警数据，故障定级数据等。资源调度层包含海量的容器，包括现在在服役的集团调度系统以及业界流行的Kubernetes。集群管理层面最突出的是DBPaaS业务,DBPaaS承担阿里巴巴所有数据库实例的监控和调度，每秒的吞吐量在千万量级。上层应用包括IoT场景应用如盒马门店和菜鸟IoT；以及APM场景应用如黄金眼和电商指标监控，还有安全部的核心链路监控等。覆盖的场景从DC到上层的SaaS。面临的挑战目前，时序数据库所面临的挑战有很多，包括业务方提出的需求和挑战。如淘宝魔兔这个无线端APM应用，他和终端用户的具体交互行为相关，会遇到高频率，低延迟查询的挑战。另外，大多数OLAP系统和分布式系统都会涉及的长时间，多维度海量数据聚合分析。还有时序数据库特有的发散时间线，比如如何聚合大量时间线？以及双11大促状态下的极高流量冲击，对整个时序数据库容量的挑战是非常大的。二、TSDB介绍TSDB架构阿里巴巴内部TSDB和在阿里云上售卖的TSDB是同一套架构，只是在能力上有所不同。下图从左到右分别是采集端，云端（Server）TSDB，以及更靠近用户的各种协议（可视化，Grafana展示和时序洞察，时序洞察可以将时序数据导入进来直接查看分析）。采集端实现了一套边缘计算的方案。边缘计算主要应用在IoT场景下、资源受限或不稳定的环境下；另外边缘计算与云端TSDB打通，云端TSDB可以直接下发规则，在边缘做数据清洗和计算，最终实现边云一体化。时序引擎整个架构包含的内容比较多，最核心的是底层TSDB核心的时序引擎，上层包括计算引擎，TSQL引擎和智能分析引擎。底层TSDB核心的时序引擎包含几个模块，时序索引，流式数据的聚合，存储引擎和稳定性管理。时序索引指的是关于时间线的查询和过滤。流式数据的聚合指的是如何在内存里做高效的海量数据的聚合分析。存储引擎提供了时序数据海量数据存储的解决方案。稳定性管理阿里巴巴最看重，即如何保证TSDB能够长时间在集团和云上安全稳定的运行。其中计算引擎是阿里自研的时序流计算引擎，提供了预聚合，降精度（降采样）持续查询的能力，其中持续查询在告警或复杂事件分析场景下用的比较多。TSQL引擎也是阿里自研的，带有分布式执行器和优化器。TSQL引擎能够扩充时序分析的能力，降低用户使用的门槛。智能引擎可以提供一些已训练好或生成好的模型算法库，提供行业定制的解决方案。 TSDB能力对比动态schema支持。NoSQL数据库基本都支持tags写入，但TimescaleDB基于传统的关系数据库 Postgres，所以不支持动态schema。多值模型。多值模型在时序场景下能极大地提升写入速度。在监控一个风力发电点的时候，它可能既有风向又有风速，一次性写入两个指标要比单值模型下一次写入一个指标要好很多。另外多值模型对上层的SQL模型更友好，比如做select查询时可以基于多个值做分析等。时序索引。相对来说，OpenTSDB基于HBase行过滤，没有时序索引。但TSDB，InfluxDB等都构建了时序索引，这样做是为了优化查询的效率。预聚合和降精度。Facebook Gorrila出来以后，时序压缩开始越来越引起大家关注，针对时序数据的特点做一些压缩，比如时间戳是连续的，数据是稳定的，采用 delta-of-delta 或者 xor 等方式进行时序压缩，最终压缩的效率要比通用压缩提高很多倍。SQL能力。SQL 接口能够降低用户使用 TSDB 的门槛，可以让熟悉 SQL 的用户直接上手操作时序模型；并且能通过 SQL 扩充时序分析能力等。集群能力。InfluxDB在开源领域有一些高可用、集群的解决方案，但稳定的高可用方案需要收费的商业版本支持。TimescaleDB目前还在开发过程中。OpenTSDB基于Hadoop生态，所以其可扩展性没有问题。 TSDB给2018年双11补充了哪些弹药。首先在保证稳定性的前提下，提供一套能够满足各个业务方的解决方案。满足高频率低延迟查询、高性能聚合、海量数据低成本存储、海量时间线管理的方案。另外，在功能模块上优化了时序索引，做了一个基于KV存储的索引，可以实现无限时间线的读写。以及参考 Facebook Gorilla做的分布式缓存存储，满足高频率低延迟查询。最后是计算引擎。在技术方面，首先做的也是时序索引优化，流式聚合引擎，预聚合和降精度，工作负载管理，以及自研的时序压缩。三、核心技术海量时序数据存储如何解决低成本存储问题？下图是双11阿里内部业务的具体使用场景。DBPaaS专注于阿里巴巴集团内部所有数据库实例监控和分析。其涉及的指标包括底层所有机器，容器，操作系统以及上层各种数据库实例指标。所有指标存在一套数据库里面，可以做统一的查询和分析，而且DBPaaS保存了历年双11数据库表现性能的数据，每一年双11当天的详细数据都在一套数据库里。DBPaaS业务带来的挑战实际上是非常大的，首先因为DBPaaS监控的是所有数据库实例，这些实时监控指标要纳入双11光明顶大屏，也就是阿里巴巴核心作战指挥室大屏，如何保证准确、及时、稳定的大屏展示就给 TSDB 带来了极大挑战；另外，日常写入均值是1000w TPS，到了双11峰值达到1400w+ TPS，如此大量的数据怎么存储。最后每天新增数据达数百TB，数据的保存本身就是一个挑战。时序数据压缩。下图左边是一个表格，每一行代表一个时间序列，与OpenTSDB中表结构一样。由于时序模型比较单一，KV基本上都是类似设计。0到3600代表过去一小时的数据，数据是秒级采集的，也就是说一行数据一共有3600列，每列都有一个值。对于OpenTSDB来说整个存储没有压缩。如果是毫秒级，一列需要360w秒，当然时间窗口是可以调的，但总的来说是受限制的。阿里在存储层参考Facebook Gorilla的思想，引入了时序压缩算法。通过列合并的方式将所有时间戳和value分别聚合成两个大的数据块，之后对数据块应用时序压缩算法，接着底层KV存储会使用通用的块压缩进行压缩。整体压缩率可以达到15:1，这里压缩率是根据线上真实的业务数据计算出来的。具体的压缩算法如下，时间戳使用了delta-delta,浮点型用了XOR编码，整型用了简单的variable length encoding，字符串使用通用压缩。需要说明一点。因为阿里内部有明确需求，所以不会使用有损压缩，但是这些算法实际上是支持的。下图是真实业务场景下的数据压缩效果。压缩前数据有6T，使用通用的块压缩，压缩完的结果是715G，不到1/10。时序压缩和块压缩一起应用的场景下可以到413G，整个压缩效率可以达到15:1左右。时序压缩加块压缩相比块压缩仍有40%的提升，这对于存储成本的降低是有很大意义的。另一个好处就是时序压缩在块压缩之前，做完时序压缩数据体积已经很小了，块压缩效率也不会受到影响。在大查询场景下，rt降低一半，当做长时间范围scan时，数据已经被高度压缩，IO效率很高，rt可以降低一半。预聚合和降精度数据降采样，多层级时间缩放。比如给客户做一个报表，这个报表有多个时间层级，给客户看过去一年，一个月或一周不同粒度的详细数据，这是一个下钻的过程。如果直接使用TSDB从详细数据做聚合的话用户体验很差，响应时间可能特别长。海量数据的聚合，统计分析。对过去半年的数据做sum 、min、max操作，甚至做P99，P55分位的统计。这种情况下计算量特别大，如果直接从详细数据里聚合也是不可行的。时间线的Join。统计交易量的成功数量，失败数量和总量，并且计算其成功比率等。因为整个数据的采集是成体系的从采集端到展示端，直接修改采集端的采集来源可能不太灵活，因此需要引擎支持多个时间线做 join 计算。实时异常检测，实时计算。给整个运维大屏提供准确，及时的数据，或者将异常的点发送给客户做报警等。下图是计算引擎和存储引擎一起提供的解决方案。首先阿里有一套自研的时序流计算引擎。考虑到TSDB团队既要输出阿里云公有云客户，也要输出阿里巴巴集团内部客户，还要输出专有云客户。在不同场景下部署资源是受限的。我们基于 Apache Beam，设计了一套自研的时序流计算引擎的语义的框架。底层可以支持Flink，Spark，JVM内存，在大规模或小规模场景下都能做计算。在此基础上，时序流计算引擎提供了持续查询能力，可以提供持续查询的视图，做报警或者复杂事件分析时可以直接查询、分析数据流中的时序数据。时序流计算引擎和TSDB是打通的，用户的数据写进来之后，一部分数据转发给流计算引擎。用户可以和TSDB交互制定策略来决定哪些数据需要降采样，哪些数据需要预聚合。另外可以制定一些报警的规则，下发给TSDB，然后TSDB将规则下发给时序流计算的持续查询,最终实现报警。TSDB写入的是详细数据，时序流计算写入的是概要数据，就是降采样或预聚合以后的数据。TSDB端做查询时用户可以查询预聚合数据。上层支持包括各种聚合算子，如 min，max，sum，count，p99，P95 和中位数分位统计等，多个时间线之间的Join，乱序数据和重复数据的写入等。 2.高频、低延迟查询淘宝魔兔支撑着阿里内部500+移动端应用无线数据的分析和监控，是一个Mobile APM 场景的应用。Mobile APM的特点是读写吞吐与用户的交互相关，属于事件型时序数据。比如双11大促的某一刻突然有一个活动上来，用户集中访问应用中的某个功能时，会产生成倍的突发流量。双 11 监控到的淘宝魔兔的查询峰值达到了4000 QPS，下图能够看到写入流量由均值 60万 TPS 飙升到峰值600万 TPS 左右，约有10倍的流量冲击。另外，业务方根据 TSDB 而制定的一些实时的策略和决策会直接影响移动端应用的用户体验，所以业务方要求TSDB rt在20ms以内。在这样的场景下，传统TSDB，比如 OpenTSDB在查HBASE时IO路径是非常长的，整个查询中会发生很多抖动和毛刺。读写rt P99分布在20ms内对OLAP系统来说是很难达到的。为了支持高频、低延迟查询，我们参考Facebook Gorilla 设计了基于Java的分布式缓存方案，集群基于Zookeeper实现分片和容量调整，可以实现动态的扩容和缩容。整个双11下来支撑了1000w+TPS写入和 10 倍流量冲击。其中最关键的是TSMem节点的设计。TSMem首先要解决两个问题，一是如何实现如此高的吞吐。二是怎么保证查询99% 的 rt 都维持在20ms以内，保持极低的延迟。TSMem 基于Disruptor 框架，将用户并发读写的请求在 RingBuffer里做暂存。采用多个生产者，一个消费者模式。一个消费者在消费到用户请求后，会将请求分发到对应的 worker线程。Worker线程池里面每一个线程对应一个时序缓存分片，所以实际上是基于Disruptor 做了内存 sharding。一个 worker 线程对应一个shard，这样的好处不用考虑锁或其它资源的竞争。另外值得注意的是把写请求和读请求都分配到同一个请求的链路上来，由同一个worker线程同时处理，可以实现无锁的读写。另外利用RingBuffer的batching特性，一个简单的写入或小批量的写入通过RingBuffer之后可以积攒成一个大的batch，然后在worker线程里做一次批量操作，可以极大提升吞吐量。另外一个的问题怎么保证高效的内存管理和极低毛刺的rt。首先要降低JVM GC 的影响，把所有的时序数据存在时序数据块中，在内存里做基于引用计数的chunk池化管理。这样做的好处是没有过多临时对象的创建，所以整个 GC 很平稳。减少了大量数据块的创建和开销。也会抹平掉在极端条件下突然申请一个新的很大的时序块所造成的延迟的抖动。 3.高效聚合分析Sunfire是阿里统一的日志和基础监控报警平台。整个平台覆盖了集团内部5w+的应用。监控指标覆盖从基础设施到上层应用，包括IaaS，PaaS，SaaS以及无线应用。这个场景带来的挑战是由于覆盖的应用特别多，业务复杂，数据体量大，因此每秒扫描的时序数据量特别大。比如，在大促时某个业务要做提前的扩容，上一批新的机器就相当于一批新的时间序列的创建。最高的情况下可以达到每秒几十万时间线的创建。下图展示的是在某一天有一批新的机器上线后的整个消费过程。累计的时间线在大促当天统计达到60亿，而且还在不停增长。如何解决每秒扫500w时间点？如果在OpenTSDB内存里做聚合计算直接响应用户查询，需要把所有点堆在内存中，这会给系统造成极大的不稳定因素。另外一个是时间线创建的速度。比如说 OpenTSDB 是基于UID表的，那字典表的原子操作也会有一个性能瓶颈，大概是20w TPS，这个瓶颈也会阻止业务的发展。时序索引高维聚合分析涉及到TSDB引擎两个内部的模块。流式聚合引擎和时序索引。时序索引包括两部分内容，一部分是构建出来的索引，另一部分索引的评估器。时序索引整个查询流程如下图，首先会解析查询，然后通过评估器给查询做优化，最终会把查询具体执行的步骤交给时序索引进行查询，最终返回时间线。然后流式聚合引擎会根据查询出的时间线从底层时序数据存储中把查询时间范围内的时序数据全部提取上来，最终通过降采样、预聚合计算后返回给用户。下图展示的是时间线的生命周期图。在不同阶段有的时间线会消亡，有的时间线会创建出来。用户在查询t2~t3时间范围的时序数据的时候，不会希望查到t0~t2时间范围内已经消亡的时间线。因为多一条时间线，在流式聚合引擎去底层存储捞数据点的时候就会多一次IO 操作。之前的存储在InfluxDB 1.3之前是全内存的时间线索引。全内存的时间线索引不会对时间范围做筛选，在用户查询t2~t3的数据的时候，会返回所有的时间线，InfluxDB 1.3之后有基于文件的索引之后，可以直接返回这两条时间线，性能提升很多。与InfluxDB创建落盘的时序索引的出发点一样，我们 TSDB 基于KV做了一套落盘的索引，其本质上就是倒排索引。时序索引的一个特性是给倒排索引增加了时间戳。在倒排基础上增加了时间戳后，索引查询时支持首先根据tag和value过滤出目标时间线，接着根据时间维度再做一次筛选，最终过滤效果会好很多。另外把整个倒排索引持久化到KV存储总，这样索引节点可以实现无状态运行，支持水平扩展，并支持时间线的TTL。下图是时序索引的评估器，评估器要做的事情就是在用户查询时序索引时实现更高的查询效率。评估器的数据来源包括 HyperLogLog 计数器，比如倒排里面某个tag或者整个倒排究竟有多少时间线;另外还来自 BloomFilter，记录某个时间线究竟是否存在；另外评估器的数据来自内存里面的时序索引缓存。评估器在查询的时候首先会选择整个倒排里面较小的集合进行运算，并支持对运算查询条件的优先级排序。如用户提供了等于查询或模糊匹配时，我们会首先执行确定性更强的等于查询，当然同时也要比较集合的大小。比如用户查询提供了两个条件，分别是机房维度和IP维度，评估器首先判断要优先查询IP维度，因为IP维度对应的 tag 包含的时间线更多，过滤时效率会更高。因此，BloomFilter和HLL虽然是粗略的统计，但在两个查询条件涉及的集合存在数量级差别时，依然能有效提高查询效率。另外比如如果BloomFilter 反馈时间线不存在，那整个查询就可以立即终止。! 流式聚合引擎前面介绍的预聚合和降采样是在数据写入TSDB之前进行的，流式聚合引擎是TSDB进程内部的用户查询时的聚合和计算的引擎。流式聚合引擎基于pipeline 方案设计，整个 pipeline 包含有不同的步骤，它提供10+核心聚合算子，20+ 填充策略，10+插值算法。可以把用户的复杂查询转化成一些简单的算子组合，转换的结果可以保证整个查询结果准确性。前面提到的时序索引查到时间线后会交给流式聚合引擎，从时序数据存储里面将具体的时间序列捞出来，根据用户的查询条件做降采样，或者缺点填充，聚合操作等。整个pipeline里其实不止图上列出的几类算子，还包括 topN、limit、插值等算子，采用松耦合方式设计，扩展性很好。另外整个pipeline从数据库捞数据时，是以小批量的方式捞出来，然后再交给流式引擎里面其它算子。本质上是一个火山模型。捞出来的小批量数据在内存里面是以列式存储，每一个算子计算性能很高。另外内存里的流式聚合引擎可以与写入 TSDB 之前做的预聚合和降精度生成的结果做无缝衔接。假设降采样提前计算出五分钟粒度的数据并写入 TSDB，此时如果用户的查询刚好是五分钟粒度降采样查询，那么流式计算引擎就不需要从时序数据库里面捞详细数据进行计算，而是直接捞五分钟粒度的数据做进一步迭代计算即可。所以说整个TSDB和计算引擎是打通的。稳定性保障工作负载管理因为TSDB既要提供集团内部和专有云客户，同时也要在公有云上服务外部客户，所以稳定性是非常重要的。TSDB 从三个层面做了稳定性和安全层面的保障。第一是资源隔离。第二是做时间线和时序数据细粒度的流控。最后是全面的指标监控。资源隔离。主要是读写线程的分离，保证查询的链路突然有故障时不会影响写入，写入链路有故障的时候也不会影响查询。另外是慢查询和大查询的资源隔离。根据用户提供的查询条件，计算一个指纹，通过指纹和历史查询记录，可以判断是不是一个大查询或者慢查询。如果是慢查询，TSDB会直接将该查询放入一个单独的隔离队列里面，该队列是资源受限的。假如是一个正常查询，TSDB 就会将当期查询放到资源更加充足的队列里面，从一定程度上可以加速整个查询。全面监控指标。包括TSDB整体吞吐量，响应时间，IO层面的关键指标，还包括各个核心模块如时序索引模块或者流式聚合模块的核心指标。可以很清晰，快速地了解到TSDB内部究竟发生了什么，快速定位客户的问题。时间线和时序数据细粒度的流控。端到端流控目的是在突发流量场景下或用户负载突然增加时，保护引擎不会受到影响甚至 crash。首先，TSDB 会在读写入口做IO线程的资源控制。其次会在 TSDB 内部两个大的核心模块的入口和IO出口处对流量做一个控制。另外，流控的维度非常多，比如可以针对时间线模型进行流量控制。时间线过多的时候，说明该业务在设计时序模型时可能是有问题的，需要做预聚合之类，降低查询覆盖的时间线。其他维度，诸如查询覆盖的时序数据点数量，IO层面如吞吐量等，以及整个查询耗时统计等。四、总结和展望上面提到的几个场景都是 TSDB 在 2018年已经解决或者正在解决的问题。接下来介绍下，TSDB要往那些方向发展，要做些什么功能、特性，满足哪些需求。第一个是冷热数据的异构存储，其目的就是降低用户的成本。因为现在数据价值越来越受到重视，最好能把用户的详细数据给长久保存下来，因此需要提供一个详细数据、长时间的存储解决方案，比如跟阿里云OSS打通等。第二个是Serverless的读写能力。Serverless读写能力实现之后，可以让TSDB有全域的分析计算能力。全域分析计算能力指的是首先高频低延迟的短时间的查询，另外是OLAB系统长时间高维度的聚合分析，然后是历史详细数据或历史某一段时间数据的分析。历史数据怎么分析，或者冷数据怎么分析都是Serverless来解决的。Serverless还可以降低计算，查询，写入等的成本，降低客户成本。第三是拥抱时序生态。比如说学习和借鉴Prometheus 系统设计或者其他商用 TSDB 和监控解决方案，以及拥抱开源社区，提供高可用、稳定的适配和替代方案，把 TSDB 的优势，如流式计算、时序索引、计算引擎或SQL引擎等等提供出来，给客户一个更好的解决方案。然后是时序智能分析，希望能够做更多的稳定、可靠的模型，深入到行业内部给客户解决一些具体问题。

发表了文章 2019-03-06

二维火监控平台的构建和探索

本文根据演讲视频以及PPT整理而成。本文将主要围绕以下三个方面进行分享：构建背景 APM的构建过程未来展望一、构建背景二维火公司的整体架构体系分为三个阶段，即从单机到面向服务化，最后到面向微服务的架构。因此，监控平台所需要监控的也是上文所提及的这三个阶段，即从单机到分布式的指标日志，最后到APM。在单机时平台往往是靠用户对故障进行反馈的，在接到反馈后相关技术人员手动登陆服务器，人工输入指令，对问题进行定位，不但会导致故障的时延非常长，而且对开发人员的技术要求也很高。但随着公司的业务发展，公司的整体架构进行升级后，对故障的容忍度进一步的降低，此时，便需要一些集中化的方法去管理相关指标和日志。二维火公司分布式指标的实现方法如下，首先会在每台机器上安装falcon-agent，来对所需要的指标，如网络指标等进行采集，然后将这些指标传输到transfer，transfer把这些指标发送到自带时序数据库的同时，会转发一份到InfluxDB，最后通过InfluxDB在Grafana里进行视图配置，以及一些相关操作如同比、环比操作。对于日志，则使用ELK架构，通过把相关的日志信息如应用日志，nginx日志，Mysql日志等保存在指定的文件中，根据系统环境的不同，在VM下通过rsyslog，在Docker下通过log-pilot把日志传输到Kafka，然后通过logstash对不同的日志进行解析处理，并发送到不同的ES集群，最后通过kibana进行视图的相应配置。在二维火，ES的作用不仅仅是全文搜索，还有数据分析，比如得到nginx的访问趋势，还有一些核心应用的指标趋势等。但随着公司的发展，这一套架构已经不能够完全满足公司的业务需求了。事实上，大家经常会遇到这样的问题，底层服务挂掉后，往往需要很长的时间来进行问题的定位。随着微服务化的发展，一些架构也需要随之升级，但在升级时会遇到很多问题需要解决，例如如何确认优化之后的架构是不是合理的，调用是不是合理的，如何提供一个有效的衡量指标，如何梳理复杂的依赖，来快速的进行问题定位，又比如作为提供方，哪些服务调用了我们的应用，调用的情况是什么样的，以此方便进行熔断，限流等操作，这些都是在架构升级时需要考虑的问题。二、APM的构建过程二维火公司是从2017年开始研发APM平台的，当时业界有一些开源的产品，比如Zipkin，Pinpoint，Skywalking等。虽然使用这些开源软件可以很快的进行平台的搭建，但是经过调研后发现这些开源软件的功能比较单一，并不能完全满足相应的业务需求，同时扩展性较低，所以二维火公司选择了对APM平台进行自研搭建。进行自研平台的搭建虽然需要投入专员进行开发维护，但对于APM平台是可以完全掌控的，能够很好的和现有的技术体系进行集成，并且可以很好的支持自定义扩展。其实上述所说的自研并不是从零开始，也有很多现成的方案进行参考，包括谷歌，阿里等都有相应的案例分享。对于APM来说，主要分为以下几个步骤，第一个是数据的埋点，第二个是数据的采集，第三个是数据的处理，第四个是数据的存储，第五个是数据的展现，关于数据展现需要根据不同公司实际的业务需求进行处理，同时数据埋点目前有许多案例可以进行参考，便不过多叙述。接下来将主要围绕数据的采集，处理和存储进行更加细致的介绍。（1）数据采集首先介绍的是数据采集，我们会在各个中间件的拦截层将链路的信息进行采集，如果一个组件没有拦截层的话，则会通过静态代理的方式对埋点进行注入。当采集到链路信息后，会进行采样和下层的RingBuffer未满的判断，如果都满足，此时会在业务线程里使用Protostuff进行序列化操作并发送到RingBuffer，最后通过异步线程批量的将数据发送到Kafka中。在数据采集过程中，需要注意的是采集数据要尽可能的减少应用的性能损耗，降低主机的资源消耗，因此使用ProtoStuff进行序列化操作，ProtoStuff相比于其他方法，序列化后的数据量更小，同时在业务线程里进行序列化后，可以进一步降低之后异步线程的CPU占用时间。但是这种方案也会存在一些问题，比如，采样或者RingBuffer满时，数据会丢失，同时指标计算不够准确，并且缺少应用指标，如连接池、线程池等，因此需要对数据的采集过程进行相应的改进。改进后的数据采集过程增加了jvm，redis、Mysql连接池，dubbo线程池等指标信息的收集并发送到Kafka，同时在客户端进行预计算，把每个接口的统计信息，比如请求数，平均响应时间等先行进行计算，因此在采样或者RingBuffer满时，指标数据也能保证不会丢失。对于数据采集来说，最为关键的是要尽可能的对重要数据进行完整的采集，同时降低对应用的损耗，在APM中最重要的两种数据分别是链路数据和指标数据，因此下文主要介绍这两块数据的处理和存储。（2）数据处理在数据获取后，便要进行数据的分析和处理。目前业界常用的方法是流计算，而在二维火平台中则是使用flink进行处理的，一方面，flink的核心代码很多是Java，能比较快速的掌握，另一方面，flink有以下几个优点，一是优秀的窗口机制，能够允许一定时间的乱序，二是api非常简洁，三是具有完善的监控，可以很快的对性能瓶颈进行定位，四是提交方式简便，flink提供web界面进行任务提交，同时flink还具有容错性强，社区活跃性好，及时性高等优点。首先是对于链路数据的处理流程，从Kafka获取到数据后，如果数据量不大，则直接通过flink把数据写入存储中，但数据量很大的话，如部分行业的高峰期，便会进行采样控制，通过对traceId进行哈希取模后再写入存储中，但高优先级或异常数据一定会写入存储中。其次是统计数据的计算，首先启动一个job，消费原始的链路数据，因为数据量会非常大，如果直接将数据发送到下一个任务进行窗口计算，这时任务间的网络传输量会非常大，因为flink中用于network的内存是有限的，大数据量的传输就会演变成为瓶颈。事实上，对于原始的链路数据来说，每一批数据大部分都是对同一个接口的调用，所以在数据转发到窗口之前，首先要进行预计算，通过把属于同一个接口的统计信息提前计算出来，以此来减少任务之间的网络数据传输，之后进行细粒度化的的keyby操作，来减少热点问题。在这之后以一分钟的窗口计算低维的统计数据，如某个应用其中一台机器下dubbo提供者的接口，计算出接口的请求总数、失败数、平均响应时间、tps、在各个响应时间区间的数量等，将低维的统计数据写入TSDB的同时，同时发送一份数据到Kafka，这样便可以通过新的job进行更大窗口的计算或者高维的聚合。在二维火，目前flink每天处理几十TB的数据，主要用于数据转发，依赖分析，实时指标计算，预聚合，SQL统计，组件异常警告等方面，可以平稳无中断运行数月。（3）数据存储对于数据存储，主要分为链路数据的存储和指标数据的存储，对于链路数据存储，我们存储在hbase，需要通过hbase还原整个调用链路，通用的做法是将同一次调用的所有数据存储到hbase的同一行，然后使用traceId作为rowKey，通过traceId还原整个调用过程。但在spanId是随机数的情况下，通过traceId查询出来的数据，调用顺序是无法保证的，所以增加了一个parentId，parentId是上层链路的spanId。通过使用traceId+parentId作为rowKey的方法，便可以一层层还原整个链路的调用过程，但是这种方法只能通过RowKey进行链路的查询，因此需要对存储方式进行改进，即将查询条件放入elasticsearch中，并关联rowKey。所以在通过flink进行写入数据时，首先把链路数据写入Hbase中，并把一些查询条件写入ES中，此时在前端进行查询时，既可以通过RowKey查询，也可以通过条件进行查询。接下来是指标数据的存储，考虑到随着数据量的增大，单机无法满足全部的业务需求，因此选择分布式时序数据库Aliyun TSDB。Aliyun TSDB具有很多优点，以二维火公司为例，监控团队规模不大，没有太多人力来做时序数据库的运维，而Aliyun TSDB可以做到零运维，同时Aliyun TSDB有着极佳的写入性能，可以支持秒级的数据写入。Aliyun TSDB还具有永久储存，时间线无限制，多值写入等其他优点，可以满足二维火平台绝大部分的业务需求。目前二维火监控平台有近400个应用的链路统计信息以及部分的主机信息，在写入Aliyun TSDB时没有产生过反压问题，对于低维查询可以做到毫秒级返回，但和其他时序数据库一样，仍然会有一些小问题产生，比如在高维查询或者时间线过多的时候响应不够理想，不支持topN等，这时便需要结合使用一些其他方法，例如对数据进行预聚合，使用redis进行处理等。 4）整体架构目前，二维火监控平台整体的前期架构是在应用层采集到链路数据和指标数据，将数据发送到Kafka，通过flink对数据进行分析，分析后对数据进行存储，最后在前端通过UI视图对数据进行展现。经过一段时间的功能迭代后，目前的总体架构中，一方面增加了移动端的相关数据信息，会把移动端的监控数据进行采集后一并发送到Kafka，同时也增加了拨测功能，另一方面将日志处理模块迁移到flink中。三、未来展望二维火监控平台对于未来的功能升级主要集中在以下几个方面，首先是进一步完善移动端监控以及拨测信息，其次是实时告警，目前告警的时延超过一分钟，希望未来能够在一分钟内进行告警，同时会进行AiOps的开发，如自动化的故障检测和实时的告警收敛，最后将会探索平台与Service Mesh的结合。

发表了文章 2019-03-06

时序数据库技术和架构演进

本文根据演讲视频以及PPT整理而成。本文将主要围绕以下四个方面进行分享：时序数据与时序数据库时序数据库的演变时序数据库对比总结一、时序数据与时序数据库什么是时序数据库？按照维基百科解释，时间序列数据库（TSDB）是一个为了用于处理时间序列数据而优化的软件系统，其按时间数值或时间范围进行索引。时序数据库增长趋势时序数据库从2014年开始就被DB-Engine列入了单独的数据库类别进行统计。下图所示的是在过去的24个月内所有数据库类别在DB-Engine上的增长趋势，可以看出时序数据库的增长趋势排在第一位。时序数据举例列举一个时序数据的例子，比如在张北有一些风力发电机组，这些风力发电机都具有能够代表自身唯一性的标签(Tag)，比如生产厂商、风场、型号以及自身ID等，而每个风机都会产生一些指标(Metrics)，比如当前的运转功率、当前风速等。随着时间，这些风机会产生新的数据，这些数据就是时序数据。时序数据库的应用场景如下图所示的是一些时序数据库的应用场景，第一个就是证券交易场景，大家所熟知的K线图就是一个比较标准的时间序列。又比如像广告数据展示，网站PV/UV，这些对运营人员很重要的时序数据。智能手环、智能手表等可穿戴设备可以采集个人健康数据，比如睡眠信息、运动信息等，并按照时间顺序将其发送到云端，经过一系列计算，最终为用户提供一些建议和提示。除上述比较常见的时序数据之外，还有气温变化情况、工业传感器数据、服务器监控数据、网络设备监控数据等。最后，还有车联网数据场景，如今新能源汽车越来越多，大部分汽车都支持通过APP直接管理，它们会时时刻刻地产生车辆的GPS、续航、安全事件等数据，云端可以利用这些数据进行分析处理，用户也可以用来查看车辆情况。时序数据库的特性时序特性：对于时序数据的时序特性而言，每条数据都会有一个时间戳，而按照要求的不同，时间戳在精度上有不同。通常而言，大多数时序数据以秒为单位，而在一些工业上会有以毫秒或者纳秒为单位的情况。数据的采样频率主要分为两种，一种是以可感知的周期频率来采集的，另外一种则是以不可感知的网站PV/UV进行离散型采样，这是因为虽然用户访问可以被提前预测，但是精确度不会很高。数据特性：对于时序数据的数据特性而言，数据都是顺序可追加的，也是多维可关联的，它们具有不同的指标。近期的时序数据往往是大家所关注的，访问频率会比较高，而时间较远的数据所带来的价值则会随着时间的推移而逐渐降低，因此时序数据也存在冷热归档的特性。此外，时序数据也会包含一些具体的数值、状态和事件。 CRUD特性：而对于时序数据库而言，也会有一些CRUD的特性。时序数据库的读写有点类似LSM数据库的特点，写操作的频率远远大于读，并且存在一定的时间窗口。此外，时序数据库通常极少更新数据，存在一定的覆盖写，并且支持批量删除操作。而随着业务对于技术的要求越来越高，因此时序数据库也需要支持高可用、高可靠以及可伸缩等特性。通常情况下，时序数据库不具备事务能力。 **二、时序数据库的演变**如下图所示的是随着时间而诞生的一些比较具有代表性的时序数据库。最早诞生的时序数据库就是RRDTool，RRD是Round-Robin Database的意思，它属于基于平板文件的简单存储。后来，伴随着大数据和Hadoop生态的发展，OpenTSDB，KairosDB这些基于Hadoop之上通用存储而专门构建的时间序列数据库开始出现，它可以按时间间隔高效地存储和处理数据。而由于OpenTSDB基于HBase这样一个通用的NoSQL存储，虽然可以解决时序相关的一些场景问题，但无法满足对于成本和性能要求更高的场景。而随着Docker、Kubernetes、微服务等技术的发展，以及对于IoT的发展预期越来越强烈。在数据随着时间而增长的过程中，时间序列数据成为增长最快的数据类型之一。高性能、低成本的垂直型时序数据库开始诞生，以InfluxDB为代表的具有时序特征的数据存储引擎逐步引领市场。而在后来的2015年，FaceBook开源了Gorilla，在时序领域应用比较广泛。在2017年，微软发布了Azure Series Insights。2018年，Amazon发布了Timestream预览版。由此可以看出，时序数据库的需求与应用愈发广泛。 **可以简单概括时序数据库发展演变历程：** 第一代时序数据库：基于平板文件的简单存储。代表：RRDTools，Graphite。RRD（Round Robin Database）。第二代时序数据库：依赖与Hadoop生态的通用分布式存储系统。代表：OpenTSDB，KairosDB 第三代时序数据库：对高性能，低成本有强需求，需要针对时序领域特别专门设计。代表：InfluxDB 特例：TimescaleDB。基于PostgreSQL关系数据库构建。时序数据库发展现状如下图所示的是时序数据库在不同领域中比较具有代表性的产品，主要分为了开源、公有云、学术以及商业&工业四大领域。三、时序数据库的对比OpenTSDBOpenTSDB以HBase作为底层存储，对应的会有一些TSD，也就是OpenTSDB的主要进程。TSD互相是对等结构，不存在Master-Slave主从关系，在向OpenTSDB写数据之前需要做好负载均衡。下图所示的是OpenTSDB存储数据的逻辑关系，以MySQL的指标数据为例。最前面是指标Metric，接着是Timestamp，需要注意的是这里的Timestamp和HBase以及HFile上的Timestamp是没有任何关系的。HFlie里面的Timestamp是用来MVCC或TTL等来使用的，而时序领域所使用的Timestamp主要指的是数据产生的时间或落盘的时间。在Timestamp之后是指标的Value以及Tag，也就是DataSource。以上是逻辑上的关系，实际情况中会因存储的不同有所变化。对于每条数据而言，都会有指标名称和对应的DataSource，如果直接把这些数据存储到HBase中则会造成极大的存储浪费，这是因为字符串存储占用的空间比数值类型多很多。因此，OpenTSDB对应的解决办法是将每一个指标都编码成如下图所示的数值类型，进而减少存储占用，而将对应的Mapping映射存储一张全局映射表中。这样做的优势是相对节省存储，而缺点则是由于全局映射关系，使得对于硬件的要求有所提升。下图所示的是HFile结构。HFile以Block作为最小存储单位，主要的存储类型有Index Block以及Data Block等。对于数据部分而言，每个Data Block可以拆分成一个个Key-Value对象，再进一步细化则会有偏移量KeyLength和ValueLength以及字符串对象KeyBytes和ValueBytes。而对于KeyBytes再进一步细分，可以分为RowLength、RowBytes、ColumnFamilyLength、ColumnFamily、TimeStamp以及KeyType等对象。很多偏移量字段对于HBase而言有用而对于时序领域而言这些偏移量字段没有任何意义，但是因为HFlie的设计原因，所以不得不造成存储甚至性能上的浪费。 OpenTSDB做了一些优化。首先，OpenTSDB的一行数据的Timestamp会以小时为粒度，然后将小时中的每一秒设置到列上，用逻辑上的一行来存储一小时的数据，用偏移量替代原始数值类型，以此来减少存储的占用。其次，对数据源(Tag)和指标(Metric)使用全局编码。但是经过全局编码后依然存在数据冗余。再次，还是由于通用存储的原因，HFile主要解决的还是Key-Value等场景，并没有针对时序场景特定压缩，因此也会造成存储和性能浪费。最后，OpenTSDB是时序数据库中少数几个没有实现多维查询的数据库。 DruidDruid是一个不折不扣的列式数据库，所以每一列都会独立存储。Druid和HBase的处理方式一样，都是采用编码字典对标签值进行编码，将String类型的标签值编码成int值。但和HBase不一样的是，Druid编码是局部编码，Druid和HBase都采用LSM结构，数据先写入内存再flush到数据文件，Druid编码是文件级别的，局部编码可以有效减小对内存的巨大压力。 Druid的特性Druid的这种列式存储模式还有如下好处：有数据类型概念，数据压缩率高。每列独立存储，可以针对每列进行压缩，而且可以为每列设置对应的压缩策略，比如时间列、int、fload、double、string都可以分别进行压缩，压缩效果更好。支持多维查找。Druid为Datasource的每个列分别设置了Bitmap索引，利用Bitmap索引实现多维查找。 Druid存储模型也有一些问题：数据依然存在冗余。和OpenTSDB一样，Tags存在大量的冗余。这是因为NoSQL的列存储也需要一些指标来记录列的信息。指定数据源的范围查找并没有OpenTSDB高效。这是因为Druid会将数据拆成多列，每列在查询时走Bitmap索引，再最后使用与操作找到满足条件的行号，这个过程需要一定的开销。而OpenTSDB中直接可以根据数据源拼成rowkey，在索引block按B+树方式进行查找，效率更高。 InfluxDB如下图所示的是InfluxDB逻辑架构图。InfluxDB其内部会有一些Rentention Policy，负责配置数据Duration，ShardGroup Duration和副本数量。对于Shard Group而言，可以简单地按字面意思理解，Influx Cluster会在Shard Group内创建一系列的Shard。Shard Group是一个逻辑概念。对于Shard，开源版本Shard数量默认为1，商业版会按照数据节点数以及所需的数据副本数量创建。N个数据节点X个副本，则创建N/X个Shard。Shard就是数据分区，具体形式就是TSM Engine，其主要负责数据编码，数据读写。TSM是LSM的变形，因此相似于LSM的数据库，也具有Cache，WAL，Compaction，Flush等等这些组件与操作，只不过TSM在LSM的基础之上进行了一些优化。如下图所示的是InfluxDB的时序数据在内存中的组织形式，时序数据写入InfluxDB内存后会按照SeriesKey进行组织。可以认为SeriesKey就是一个数据源，而Field就是采集的指标。比如SeriesKey是一部iPhone，Field包含经纬度，高度，行走步数等。具体的数值会借助偏移量的方式进行存储。如下图所示的是TSM文件的最粗粒度的结构。在InfluxDB中，数据以Block为最小单位存储在文件中，如图所示文件结构主要包含Data Block、Index Block以及最后的Footer。将上图进一步细化的结果如下图所示。在TSM中，索引做到了文件级别，索引的实现类似于B+树，而且数据块和索引结构存储在同一个文件中。InfluxDB中有数据类型的概念，同一个Block中只会存储同一种Key的数据。 SM文件的详解解释如下： Type：表示该SeriesKey对应的时间序列的数据类型，数值数据类型通常为int、long、float以及double等。不同的数据类型对应不同的编码方式。 Length：len(Timestamps)，用于读取Timestamps区域数据，解析Block。时序数据的时间值以及指标值在一个Block内部是按照列式存储的：所有的时间值存储在一起，所有的指标值存储在一起。使用列式存储可以极大提高系统的压缩效率。 Timestamps：时间值存储在一起形成的数据集，通常来说，时间序列中时间值的间隔都是比较固定的，比如每隔一秒钟采集一次的时间值间隔都是1s，这种具有固定间隔值的时间序列压缩非常高效，TSM采用了Facebook开源的Geringei系统中对时序时间的压缩算法：delta-delta编码。 Values：指标值存储在一起形成的数据集，同一种Key对应的指标值数据类型都是相同的，由Type字段表征，相同类型的数据值可以很好的压缩，而且时序数据的特点决定了这些相邻时间序列的数据值基本都相差不大，因此也可以非常高效的压缩。需要注意的是，不同数据类型对应不同的编码算法。对于InfluxDB而言，在1.3版本之前，所有的索引都做到了内存里。内存索引的好处就是查询速度优于其他持久化存储介质，但是缺点是索引的容量会受到限制。如果具有海量的标签，那么索引量非常大，可能内存中无法存放；其次，如果发生宕机，那么在Startup阶段，就需要重新扫描所有的TSM文件，并在内存中重新排列这些索引。正是因为上述问题，使得索引对于资源的消耗过高，所以在1.3版本之后，InfluxDB实现了基于磁盘的索引。虽然这样的磁盘索引能够解决大部分场景，但是因为存储占用的关系，所以也只实现了Tag到SeriesKey的映射，没有实现Tag到SeriesKey + FieldKey + Timestamp的映射。 Prometheus与其他时序数据库不同，Prometheus不仅包含存储，更是一个生态系统，提供了几乎整个运维领域的全部组件，提供了服务发现、数据采集服务、存储相关服务、报警相关组件等，并且提供了Web UI界面。Prometheus的优点是其提供了一整套监控解决方案，不需要运维人员去逐个拼装开源组件。此外，Prometheus还提供了一套标准，研发人员可以根据协议来替换组件，提供了更好的灵活性。 Prometheus提供了如下的关键功能 多维数据模型：Metric，Labels 灵活的查询语言：PromQL，在同一个查询语句，可以对多个 Metrics 进行乘法、加法、连接、取分数位等操作。 可独立部署，拆箱即用，不依赖分布式存储 通过Http pull的采集方式 通过push gateway来做push方式的兼容 通过静态配置或服务发现获取监控项 支持图表和dashboard等多种方式 TimeScaleDBTimeScaleDB是一个比较特殊的例子，它是基于关系型数据库实现的时序数据库。关系数据库通常默认的引擎所采用的都是B+树，而对于B+树而言，随着数据量不断写入，其内部节点的排序会造成很大压力。从用户的视角，TimescaleDB对外暴露的是一个叫做hypertables的表，其是一个抽象概念。随着数据的不断写入，其将会形成多个物理上的子表，使得每个子表上的数据不至于过高，解决了单表数据量的问题。 TimeScaleDB的特性 基于标准的PG，未对PG存储层做任何修改 时序数据表的透明自动分区特性 提供了若干面向时序数据应用场景的特殊SQL接口(使用时空UDF实现) 针对时序数据的写入和查询对PostgreSQL的Planner进行扩展和优化 面向时序数据表的定制化并行查询除了上述特性之外，TimeScaleDB还具有时序数据表的透明自动分区功能。该功能所要实现的目标如下： 随着数据写入的不断增加，将时序数据表的数据分区存放，保证每一个分区的索引维持在一个较小规模，从而维持写入的性能。 基于时序数据的查询场景，自动分区时以时序数据的时间戳为分区键，从而确保查询时可以快速定位到所需的数据分区，保证查询性能。 分区过程对用户透明，从而达到Auto-Scalability的效果。借助透明化自动分区的特性，根据官方的测试结果，在同样的数据量级下，TimescaleDB的写入性能与PG的传统单表写入场景相比，即使随着数量级的不断增大，性能也能维持在一个比较稳定的状态。 TimeScaleDB的特性对于TimeScaleDB的优势而言，首先，其100%继承自PostgreSQL的生态，且由于完整支持SQL，对于未接触过时序数据库的用户有很高吸引力；其次，因为TimeScaleDB基于PG，所以也具有灵活的JSON格式支持，无需在JSON解析上浪费计算资源；并且TimeScaleDB还可以实现快速的复杂查询，也继承了PostgreSQL的高品质与稳定性优势，还具有强ACID支持。对于TimescaleDB的缺陷而言，因为其是PostgreSQL的一个延伸，因此不能像从内核和存储层面针对时序数据库的场景进行极致优化。虽然官网上宣传能够支持集群模式，但是仍旧处于开发中，目前从产品的架构来看仍然是一个单机库，不能发挥分布式技术的优势。而且数据虽然自动分区，但是由于时间戳决定分区，比较容易形成I/O热点。而在功能层面，面向时序数据库场景的特性有限，更像是一个传统OLTP+部分时序特性。在NoSQL具有优势的简单快速查询场景，非结构化数据，存储成本和离线分析场景方面，TimescaleDB不具有优势。阿里云时序时空数据库TSDB阿里云时序时空数据库TSDB的发展演变经历了三个阶段，最开始1.0阶段主要基于OpenTSDB，底层实现了双引擎——HBase和HiStore。而随着阿里业务场景对于时序数据库不断提出新的挑战，在2.0阶段中，阿里云就将OpenTSDB引擎换成了自研的TSDB引擎，实现了OpenTSDB所没有支持的倒排索引、基于时序场景的特殊编码、分布式流计算聚合数据等功能和特性。而随着业务场景以及整个公司生态的完善，阿里云时序时空数据库TSDB实现了边缘计算和云的一体化，实现了TSQL，兼容了Prometheus生态，并且除了能够支持时序数据引擎之外，还能够支持时空数据引擎。阿里云时序时空数据库TSDB的特性 支持两种存储模型。时间线的ID + TS和继承自OpenTSDB的Metric + TS + Tag。 双层Sharding结构。先基于时间分区索引，并在存储层做Salting，避免时间分区热点。 基于Coprocessor实现列合并压缩算法，在通用ZSTD+DIFF编码的基础上进一步将存储空间减小至压缩前的1/3。 支持分布式流聚合计算。 工作负载优化：读写线程池分离，大小查询资源隔离，超时大查询Skip，限流及状态管理。四、总结对于时序数据库而言，主要存在三种流派。第一种是以Timescale为代表的标准SQL，其能够极大地降低入门门槛，也能解决时序问题，但是体量上不占优势；第二种是以OpenTSDB为代表的基于通用NoSQL的时序存储引擎；最后一种则是为了应对时序场景的业务挑战而单独设计的以InfluxDB为代表NoSQL数据库。这三种时序数据库的主要区别如下所示： SQL vs NoSQL 固定Schema vs 动态Schema 通用存储 vs 时序专用存储 单机 vs 分布式 结构化数据 vs 非结构化数据 低学习成本 vs 相对高的学习成本

发表了文章 2019-03-05

饿了么时序数据库LinDB架构演进

以下内容根据演讲视频以及PPT整理而成。饿了么的监控体系于2015年之前通过StatsD与Graphite技术建立，在2016年公司开发了第一个版本基于RocksDB的本地存储系统LinDB1.0，系统实现了全链路监控的自用型功能，基本满足了公司的需求。在2017年，公司通过扩展RocksDB将LinDB系统升级到了2.0版本。在2018年，公司参考RocksDB的思想基于排倒索引与自研存储开发的LinDB3.0版本，很好的提升了系统的性能，满足了业务上多活的需求。下图展示了公司数据库的发展历程。基于LinDB系统优良的性能与公司增长的需求，饿了么公司的对LinDB数据库的不断改进的目标如下所示：数据库监控体系结构足够轻量，减少维护所需人力物力；体系支持Measurement、Tags与Fields技术；可以解决指标写入的热点问题，采用Series技术进行Sharding过程，体系支持水平扩展；支持近实时读写功能，高效快捷的查询出数据；监控体系下的数据库支持多活；自动的Rollup；支持类SQL的查询方式；安全性上高度可靠，可以支持多个副本；二．系统整体架构如下图所示是公司数据库的整体架构。公司的数据库从结构上分为四层，不同于传统数据库在存储层进行多活，公司将多活设计在了计算层中，以此提升系统的效率。在数据写入层中，不同客户端的写入数据会存入对应的不同机房的集群中。在用户查询层中，用户将通过HTTP的访问对相应LinProxy模块中的数据进行查询。在系统的计算层LinProxy中，公司为不同的LinProxy定义了不同的逻辑集群，逻辑集群将通过相应的方式向对应的物理集群进行数据的查询。在进行重量级查询时，数据会不断地从下层送到上层，导致在计算层中数据处理遇到瓶颈。系统的计算层采用了并行处理请求的方式，通过拓扑结构将数据一层层的送给用户。系统同样支持更高级的计算，例如对股票曲线的预算或时间线的预判等。三．写入过程如下图所示，数据在系统中的写入分为WAL的复制与本地写入两步。WAL复制的过程中，系统参考了Kafka设计方式，即用户只要写入WAL成功就被认为数据写入成功，通过这种方式提高了整个系统的吞吐量。本地写入过程中，用户将WAL的数据解析写入自己的存储结构中，并可以通过本地存储查到已写入的数据。例如下图所示情景，在一份含有三个副本的数据中，用户将写入成功的副本一数据分别同步到副本二与副本三中，系统采用了透取技术，用“推”的方式将数据从Leader节点推送给Follower节点。系统的复制协议采用多通道复制协议，主要基于WAL在多节点之间的复制，WAL在每个节点上的写入由独立的写操作完成，所以当客户端写入对应Leader节点的WAL成功就认为本次写操作是成功的，Leader所在的节点负责把相应的WAL复制到对应的Follower中，同理写WAL成功被认为复制成功。下图所示多通道复制的原理图，多通道复制技术仿照Kafka机制设计而来，这种设计理念将WAL视为巨大的数组以此实现将客户端上的数据一点点的写入。对于Leader节点有三个指针，分别代表写入指针，复制指针与复制完成后Follower的位置指针。通过多通道复制设计，系统提高了吞吐量，但同时降低了数据一致性的程度。系统本地写入存储数据的结构如下图所示，系统的一个数据库在单节点上会存在多个Shard，每个Shard负责各自的数据写入，并含有各自的WAL，所有Shard共享同一个索引数据。所储存的数据会根据数据库的Interval按时间片进行存储。系统的设计具有以下的优势：方便处理TTL，遇到过期的数据使用者可以直接删除相应的目录；每个Shard下面会存在Segment，Segment根据Interval来存储相应时间片的数据；每个Segment下面按Interval方式存储了很多Data Family，以此减少数据文件之间的合并操作，平衡写入放大的问题；下图所示为数据本地写入的过程。系统会为每一个Shard启一个写线程，该线程负责这个Shard的所有写操作。在写入的过程中，系统首先会把Measurement、Tags、Fields对应的数据写入数据库的索引文件，并生成相应的ID数据。系统会根据索引得到的ID，结合写入时间和数据库Interval计算得到需要写入到对应Segment下的对应Family中。整个写过程先写内存，再由Flusher线程把内存中的数据推到相应的文件中。四．如何查询下图所示为系统的查询过程。用户提交的请求首先到达Proxy层，在该层中进行SQL解析，并将解析的数据送到Aggregator Stream中进行聚合操作。系统通过LinProxy层中的LinConnect模块将处理好的请求发送到机房集群中，在机房集群中进行数据的反馈。ZooKeeper在系统中负责简单的Metadata存储。整个系统的操作采取了异步化的方式，这样可以利用系统线程在IO等待时做一些计算操作。系统在节点层面上的数据查询过程如下图所示。该过程类似于Map操作，公司在节点层面上使用了Actor来替代传统的Task，大大增加了索引查询的效率。五．存储结构在存储过程中，对数据的索引分为ID与倒排索引两部分，系统首先将输入的字符串转换成Int类型，并根据Time Series的规则为数据生成对应的唯一ID。系统根据Tags标签进行倒排索引，将索引指向一个ID列表。TSID列表以BitMap的方式存储，以方便查询的时候通过BitMap操作来过滤出用户想要的数据。系统中的每一类数据都存储在独立的RocksDB Family中。系统的具体索引步骤如下图。将数据中的字符串转换实例的过程如下图。系统首先将CPU数据、Host数据及地区数据全部转换为整型数字，再根据相应的数据规则对转换后的数字进行倒排解析，将解析后的数据存储入库。系统的存储模式参考了LSM方式，下图列出了系统根据LSM方式设计的存储模式。在系统存储的内存层面，系统设计了两个版本的Memory Table，一个负责写入数据，一个负责将数据写入文件中。在Memory Table中，每个Table都会拥有对应的Store及Block块。存储结构如下图所示。系统的文件存储中使用同一个Measurement的数据以Block的方式存储在一起，查询时通过Measurement ID定位到该的数据所存储的Block中。在文件存储结构的尾部，系统指向了Metric索引，在索引块中包含了很多Offset模块，通过这种方式方便用户得知系统的版本号并加快索引速度。系统的文件存储结构如下图所示。六．系统自身监控系统拥有很好的自身监控能力。在系统自身监控的模块，使用者可以清晰看到系统各个方面的运行情况，通过每项数据的变动，使用者可以清楚掌握系统目前的状况，监控数据示意图如下图所示。

发表了文章 2019-03-04

【最全PPT下载+直播回顾】阿里云栖开发者沙龙：时序数据库技术专场

活动介绍阿里云栖开发者沙龙是“云栖社区”主办的线下技术沙龙品牌，希望通过技术干货分享来打通线上线下专家和开发者的连接。沙龙每期将定位不同的技术方向，逐步覆盖云计算，大数据，前端，PHP，android，AI，运维，测试等技术领域，并会穿插一些特别专场（开源专场，女性开发者专场，开发者成长专场等）。我们希望它是一个开发者的聚集地，每一期都是一个开发者的大Party！本期沙龙以“开辟大数据新赛道，教你玩转海量时序数据”为主题。作为国内时序数据库理念的先行者和推广者，此次阿里巴巴还邀请了来自滴滴、饿了么、二维火多位业内数据库技术专家分享交流技术经验，畅谈时序数据库背后的那些事儿。超过200名数据库开发者和爱好者现场参与了本次活动，聆听互联网大咖解构时序数据库应用最佳实践，现场人气爆棚。下面小编就为大家整理了满满的干货，供各位回顾和学习使用。直播回顾 https://yq.aliyun.com/live/863 演讲主题及嘉宾： Topic 1：时序数据库技术和架构演进本主题主要聚焦时间序列数据库的前世今生，带领大家解读时间序列数据库的由来、发展、现状、未来，以及和其他数据库的对比和优势；此外还会重点比较目前时间序列数据的热门产品和项目，对时间序列数据进行全方位的解读。分享实录文字版>>> Topic 2：时序数据在滴滴实时数据开发平台中的处理和应用数据存在天然的时序属性，对时序数据的实时快速的查询和分析可以有效的扩展数据的价值。滴滴实时数据开发平台以Spark Streaming/Flink为实时计算引擎，Druid为OLAP查询引擎，提供了一套完整的时序数据加工处理+可视化+业务监控的处理方案；为内部用户提供了低延时高可靠的的数据开发和查询服务，保障了滴滴核心业务的稳定运行分享实录文字版>>> Topic 3：二维火监控平台的构建和探索公司发展前期，一套ELK日志系统可能就已经满足了日常的监控需求，但是随着业务的发展，服务从几十个发展到几百个，每个请求涉及的链路也越来越复杂，当出现异常时，单靠日志系统已经很难迅速定位问题。本次分享将讲述二维火如何快速实现一套自研的APM平台，如何在技术选型中进行一些取舍。分享实录文字版>>> Topic 4：阿里巴巴双十一千万级实时监控系统技术揭秘目前阿里巴巴 TSDB 数据库支撑着集团每秒千万级时序数据点写入，来源涵盖数据中心、容器指标，核心业务在内的海量应用监控，采集指标累计超过 100 亿，在 18 年双 11 当天写入峰值达到 4千万/秒数据点。本次分享将介绍过去一年 TSDB 为应对这些挑战所做的核心技术改造，包括时序索引优化、流式聚合和存储引擎升级换代等等。分享实录文字版>>> Topic 5：饿了么时序数据库LinDB架构演进深入解读饿了么如何从0构建一个时序数据库为什么会有LinDB； LinDB在整个监控体系担当怎么角色；整个系统内部揭秘，如何做好一个时序数据库；未来展望；分享实录文字版>>> 全场PPT下载如需获取PPT，请您加入“阿里数据库”钉钉群，与最优秀的数据库技术专家实时交流，下载地址详见群公告～入群方式一：钉钉搜索群号：23124548 入群方式二：钉钉扫码即可加入专享优惠所知不止于感知，TSDB为物联网而生！阿里云时序时空数据库TSDB 1元购！立即体验请戳：https://promotion.aliyun.com/ntms/act/tsdbtry.html?spm=5176.149792.775960.1.dd9e34e2zgsuEM&wh_ttid=pc 招贤纳士阿里云数据库产品事业部——时序时空数据库TSDB团队是一群有情有义，愿景驱动的技术商业探索队。目前，我们提供时序时空数据库TSDB产品的云服务，一款高性能，低成本，稳定可靠的在线数据库服务；提供千万级并发读写、高效时空索引支持时空大数据并行计算，双十一写入TPS达到6000万/秒，十倍以上压缩比，PB级时序时空数据毫秒级聚合，百亿时间线的集群规模，基于机器学习的智能预测等能力；广泛应用于APM、设备监控系统、企业能源管理系统（EMS）、生产安全监控系统、电力检测系统、城市大脑、物联网、车联网、社交媒体、地理环境、物流行业、饿了么，高德，商业选址等场景。在这里，你能体验到双11海量数据的技术挑战，你也能有机会体验到性能极致优化后带来的喜悦；在这里，你能成为一个领域的专家，打造全球领先的时序时空生态系统；在这里，你能把技术转化成商业影响力，让产品服务于万千用户。现诚招“时序时空数据库专家”，欢迎大家投递简历。内推邮箱：jianlin.yjl@alibaba-inc.com 简历格式：姓名+时序时空数据库专家合作伙伴主办：阿里云智能——数据库产品事业部；云栖社区联合主办：DataFun社区；清华经管创业者加速器协办：活动行；掘金；开源中国；51CTO；IT大咖说；SegmentFault；示说网

时序数据库_个人页

个人介绍

擅长的技术

GDB的性能怎么样

mysql ibdata1文件被undo log日志占了几百个G。

问个问题，DBMS的登录必须前置阿里云登陆吗？

phoenxi写进去的主键id=1数据，在hBase中rowkey被转换为\x80\x00\x00\x01

咨询下RDS for postgresql高可用版在主实例出现故障无法访问时，会自动切换到备用实例，这个是如何来判定故障的呢？

phoenxi写进去的主键id=1数据，在hBase中rowkey被转换为\x80\x00\x00\x01

菜鸟问题

阿里的tsdb与influxdb，两者比较，优缺点是什么？以后的发展路径是什么样的？

用 SQL 在一个有 几亿条记录的库表里插入一个字段（如：Minute），有没有更好更稳定的办法？我们这里总返回失败

TSDB的httpapi支持压缩上传吗

TSDB在控制台上好像没有直接导出到对象存储的工具吧

【直播预告】阿里巴巴高级算法工程师麦慧君：阿里云时序数据库TSDB For InfluxDB®介绍

maven引入phoenix一直报错！

GDB有事务性吗

已经创建文件夹但是数据写入失败

请问下 hitsdb /api/put 接口一次性请求最多能写多少个datapoints？

mysql 只有几百条数据的update 更新了10s一般是什么问题，我查询了锁表，机器的io都没发现问题

《K8s监控神器——TSDB for Prometheus的入门与实践》

数据库技术之《OpenTSDB简介以及同TSDB的差异》

数据库技术之《TSDB采集和展示方案》

时序数据在滴滴实时数据开发平台中的处理和应用

阿里巴巴双11千万级实时监控系统技术揭秘

二维火监控平台的构建和探索

时序数据库技术和架构演进

饿了么时序数据库LinDB架构演进

【最全PPT下载+直播回顾】阿里云栖开发者沙龙：时序数据库技术专场

【直播预告】阿里巴巴高级算法工程师麦慧君：阿里云时序数据库TSDB For InfluxDB®介绍

《K8s监控神器——TSDB for Prometheus的入门与实践》

数据库技术之《OpenTSDB简介以及同TSDB的差异》

数据库技术之《TSDB采集和展示方案》

时序数据在滴滴实时数据开发平台中的处理和应用

阿里巴巴双11千万级实时监控系统技术揭秘

二维火监控平台的构建和探索

时序数据库技术和架构演进

饿了么时序数据库LinDB架构演进

【最全PPT下载+直播回顾】阿里云栖开发者沙龙：时序数据库技术专场

GDB的性能怎么样

GDB的性能怎么样

mysql ibdata1文件被undo log日志占了几百个G。

问个问题，DBMS的登录必须前置阿里云登陆吗？

phoenxi写进去的主键id=1数据，在hBase中rowkey被转换为\x80\x00\x00\x01

咨询下RDS for postgresql高可用版在主实例出现故障无法访问时，会自动切换到备用实例，这个是如何来判定故障的呢？

咨询下RDS for postgresql高可用版在主实例出现故障无法访问时，会自动切换到备用实例，这个是如何来判定故障的呢？

phoenxi写进去的主键id=1数据，在hBase中rowkey被转换为\x80\x00\x00\x01

菜鸟问题

菜鸟问题

阿里的tsdb与influxdb，两者比较，优缺点是什么？以后的发展路径是什么样的？

阿里的tsdb与influxdb，两者比较，优缺点是什么？以后的发展路径是什么样的？

用 SQL 在一个有 几亿条记录的库表里插入一个字段（如：Minute），有没有更好更稳定的办法？我们这里总返回失败

用 SQL 在一个有 几亿条记录的库表里插入一个字段（如：Minute），有没有更好更稳定的办法？我们这里总返回失败

TSDB的httpapi支持压缩上传吗

TSDB的httpapi支持压缩上传吗

TSDB在控制台上好像没有直接导出到对象存储的工具吧

maven引入phoenix一直报错！

用 SQL 在一个有几亿条记录的库表里插入一个字段（如：Minute），有没有更好更稳定的办法？我们这里总返回失败

用 SQL 在一个有几亿条记录的库表里插入一个字段（如：Minute），有没有更好更稳定的办法？我们这里总返回失败

用 SQL 在一个有几亿条记录的库表里插入一个字段（如：Minute），有没有更好更稳定的办法？我们这里总返回失败