表格存储最佳实践:一种用于存储时间序列数据的表结构设计

简介: 在时间序列存储的场景,例如监控数据或者日志数据,通常比较难解决的是写入的问题,传统的数据库难以承载如此大数据量、高并发的写入压力。 表格存储能够提供非常优秀的写入能力,在阿里内部得到到了正好的实践和证明。但是若要发挥其强度的写入能力,需要有一个良好的表结构设计。 本篇文章给出了一个存储时间序
+关注继续查看

在表格存储的数据模型这篇文章中提到:


在表格存储内部,一个表在创建的时候需要定义主键,主键会由多列组成,我们会选择主键的第一列作为分片键。当表的大小逐渐增大后,表会分裂,由原来的一个分区自动分裂成多个分区。触发分裂的因素会有很多,其中一个很关键的因素就是数据量。分裂后,每个分区会负责某个独立的分片键范围,每个分区管理的分片键范围都是无重合的,且范围是连续的。在后端会根据写入数据行的分片键的范围,来定位到是哪个分片。


表会以分区为单位,被均匀的分配到各个后端服务器上,提供分布式的服务。



        在表格存储的最佳实践中提出,一个设计良好的主键,需要避免访问压力集中在一个小范围的连续的分片键上,也就是说避免热点分片。设计良好的表结构,整张表的访问压力能够均匀的分散在各个分片上,这样才能充分利用后端服务器的能力。


        那在使用表格存储来存储时间序列数据时,我们应该如何设计表的结构,避免热点分片的问题?


        假设我们需要设计一张表,用于存储监控信息,监控信息包括:时间戳(timestamp)、监控指标名称(metric)、主机名(host)和监控指标值(value)。而我们的查询场景为,指定监控指标名称和时间范围,查询该监控指标的所有值。通常我们会这样设计我们的表结构:



表设计一:


c820f472b78acf84341a1312b75bcb1681d4afba

该设计以metric列为分片键,能够满足查询的场景,但是有很严重的分片热点问题。假设一个metric下每秒采集一个点,而我们有上百台设备,则该分片每秒需要能够提供上百的写入能力,这点也没有问题。但是由于使用了metric作为分片键,metric的值为常量,随着数据量的上涨,其无法再进行分裂,会导致该分片下的数据量不断膨胀,可能超过一台物理机所能承受的上限,存在分片数据量的热点。


为了解决这个问题,我们对分片键做一个调整:


表设计二:

b6cd2deec148f387ad46e143f56a88f12390f255


我们将第一列主键和第二列主键合并为一列主键作为分片键,在数据的分布模式上并没有什么变更,但是引入了时间这个维度后,我们避免了分片数据量的热点。但是当host规模变大,从上百膨胀到上万,则该张表需要每秒提供上万并发的写入能力。我们需要将该表的写入压力均匀的分散到各个分片上,但是由于其数据的特点,每次写入的数据都是最新时间的数据,其写入压力永远集中在最新时间戳所在的分片上。


为了将写入压力均匀的分散到分片上,我们再对表做一个重新设计:


表设计三:

4ff28d7fe2d852e218267c36a3e993fd99b643d0


我们引入一个新的列 - bucket,在每行数据写入前,为每行数据分配一个桶(可随机分配),以桶的编号为分片键(HBase中有类似的解决方案,称为salted key)。桶的个数任意,可扩张,在写入之前将数据预分桶之后,也就解决了写入压力热点的问题,因为写入压力永远是均匀分配在各个桶上的。可根据具体的写入压力,决定桶的个数。


数据分桶后,如果需要读取完整的数据,需要在每个桶内都分别执行一遍查询后将数据进行汇总,可以使用我们SDK提供的异步接口,来并行的查询每个桶,提高查询的效率。


总结

在时间序列存储的场景,例如监控数据或者日志数据,通常比较难解决的是写入的问题,传统的数据库难以承载如此大数据量、高并发的写入压力。


表格存储能够提供非常优秀的写入能力,在阿里内部得到到了正好的实践和证明。但是若要发挥其强度的写入能力,需要有一个良好的表结构设计。


本篇文章给出了一个存储时间序列数据库的最佳实践,供参考。但表结构设计并不是千篇一律的,需要根据不同的业务场景设计做灵活的调整,欢迎一起探讨。

相关实践学习
阿里云表格存储使用教程
表格存储(Table Store)是构建在阿里云飞天分布式系统之上的分布式NoSQL数据存储服务,根据99.99%的高可用以及11个9的数据可靠性的标准设计。表格存储通过数据分片和负载均衡技术,实现数据规模与访问并发上的无缝扩展,提供海量结构化数据的存储和实时访问。 产品详情:https://www.aliyun.com/product/ots
目录
相关文章
|
10月前
|
存储 消息中间件 NoSQL
物联网数据通过规则引擎流转到OTS|学习笔记
快速学习物联网数据通过规则引擎流转到OTS
178 0
物联网数据通过规则引擎流转到OTS|学习笔记
|
11月前
|
存储 负载均衡 开发者
表格存储数据多版本介绍| 学习笔记
快速学习表格存储数据多版本介绍。
166 0
表格存储数据多版本介绍| 学习笔记
|
存储 NoSQL 关系型数据库
基于TableStore的海量气象格点数据解决方案实战 王怀远
基于TableStore的海量气象格点数据解决方案实战 王怀远
210 0
基于TableStore的海量气象格点数据解决方案实战 王怀远
|
存储 SQL 运维
基于Tablestore 实现大规模订单系统海量订单/日志数据分类存储的实践
前言:从最早的互联网高速发展、到移动互联网的爆发式增长,再到今天的产业互联网、物联网的快速崛起,各种各样新应用、新系统产生了众多订单类型的需求,比如电商购物订单、银行流水、运营商话费账单、外卖订单、设备信息等,产生的数据种类和数据量越来越多;其中订单系统就是一个非常广泛、通用的系统。而随着数据规模的快速增长、大数据技术的发展、运营水平的不断提高,包括数据消费的能力要求越来越高,这对支撑订单系统的数据库设计、存储系统也提出了更多的要求。在新的需求下,传统的经典架构面临着诸多挑战,需要进一步思考架构优化,以更好支撑业务发展;
594 0
基于Tablestore 实现大规模订单系统海量订单/日志数据分类存储的实践
|
存储 SQL 分布式计算
使用 Data Lake Formation(DLF) 进行 Tablestore 数据实时入湖
本文介绍使用 Data Lake Formation (DLF)服务,实时订阅 Tablestore(原 OTS) 的数据,并以 Delta Lake 的格式投递进入 OSS,构建实时数据湖。 ## 架构介绍 表格存储是一种全托管的云原生数据库,使用表格存储您无需担心软硬件预置、配置、故障、集群扩展、安全等问题。提供高服务可用性的同时极大地减少了管理成本。 表格存储支持多种数据库模型
667 0
使用 Data Lake Formation(DLF) 进行 Tablestore 数据实时入湖
|
存储 监控 搜索推荐
海量结构化数据解决方案-表格存储场景解读
数据是驱动业务创新的最核心的资产。不同类型的数据如非结构化数据(视频、图片等)、结构化数据(订单、轨迹),面向不同业务的使用要求需要选择适合的存储引擎,能够真正发挥数据的价值。针对于海量的非强事务的海量结构化/半结构数据,表格存储一站式解决。这里详细解读该适合场景的使用解读。
4082 0
海量结构化数据解决方案-表格存储场景解读
|
存储 SQL 开发框架
阿里云物联网平台数据转发到表格存储(Table Store)示例参考
本文主要结合物模型的结构体类型属性数据,演示payLoad的设置及规则引擎的配置。
阿里云物联网平台数据转发到表格存储(Table Store)示例参考
|
SQL 存储 弹性计算
玩转Tablestore:使用Grafana快速展示时序数据
Grafana 是一款采用 go 语言编写的开源应用,主要用于大规模指标数据的可视化展现,是网络架构和应用分析中最流行的时序数据展示工具,可以通过将采集的数据查询然后可视化的展示,实现报警通知;Grafana拥有丰富的数据源,官方支持以下数据源:Graphite,Elasticsearch,InfluxDB,Prometheus,Cloudwatch,MySQ
1478 0
|
NoSQL 分布式计算 Java
通过EMR Spark Streaming实时读取Tablestore数据
本文将介绍如何在E-MapReduce中实时流式的处理Tablestore中的数据。 场景设计 随着互联网的发展,企业中积累的数据越来越多,数据的背后隐藏着巨大的价值,在双十一这样的节日中,电子商务企业都会在大屏幕上实时显示订单总量,由于订单总量巨大,不可能每隔一秒就到数据库中进行一次SQL统计,此时就需要用到流计算,而传统的方法都是需要借助Kafka消息队列来做流式计算,数据订单需要写入数据库与Kafka中,Spark Streaming 消费来自Kafka中的订单信息。
3433 0
|
流计算 NoSQL 存储
Tablestore + Blink实战:交易数据的实时统计
交易数据的实时统计是电商网站一个核心功能,可以帮助用户实时统计网站的整体销售情况,快速验证“新销售策略”的效果。我们今天介绍一个基于表格存储(Tablestore)实现交易数据的实时计算,给大家提供一个新使用方式。
4561 0
相关产品
云存储网关
文件存储NAS
推荐文章
更多