开发者社区> 木洛> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

TableStore数据模型 - WideColumn和Timeline

简介: 前言 TableStore是阿里云自研的一款分布式NoSQL数据库,提到NoSQL数据库,现在对很多应用研发来说都已经不再陌生。当前很多应用系统底层不会再仅仅依赖于关系型数据库,而是会根据不同的业务场景,来选型使用不同类型的数据库,例如缓存型KeyValue数据会存储在Redis,文档型数据会存储在MongoDB,图数据会存储在Neo4J等。
+关注继续查看

前言


TableStore是阿里云自研首款分布式多模型数据库,属于NoSQL的类别。提到NoSQL数据库,现在对很多应用研发来说都已经不再陌生。当前很多应用系统底层不会再仅仅依赖于关系型数据库,而是会根据不同的业务场景,来选型使用不同类型的数据库,例如缓存型KeyValue数据会存储在Redis,文档型数据会存储在MongoDB,图数据会存储在Neo4J等。
回顾下NoSQL的发展历程,NoSQL诞生于Web 2.0时代,互联网高速发展的一个时代,也带来了一次互联网数据的爆发。传统的关系型数据库很难承载如此海量的数据,需要一种具备高扩展能力的分布式数据库。但基于传统的关系数据模型,去实现高可用和可扩展的分布式数据库是非常有挑战的一件事。互联网上大部分数据的数据模型很简单,没必要一概用关系模型来建模。如果能打破关系模型以一种更简单的数据模型来对数据建模、弱化事务和约束、以高可用和可扩展为目标,以此为目标设计的数据库能更好的满足业务需求,正是基于此种理念推动了NoSQL的发展。
d7f428846f277b2ad9550b7ffdafeee39c14ce63
总结下,NoSQL的发展是基于互联网时代对业务的新挑战以及数据库的新需求而推动的,基于此发展起来的NoSQL,有其显著的特征:
  • 多数据模型:为满足不同数据的需求,诞生出了很多不同的数据模型,例如KeyValue、Document、Wide Column、Graph以及Time Series等。这是NoSQL数据库发展的一个最显著特征,打破了关系模型的约束,选择一个多元的发展方向。数据模型的选择是更加场景化的,更贴近业务的实际需求,能够做更深层次的优化。
  • 高并发、低延迟:NoSQL数据库的发展更多由在线业务的需求推动,其设计目标更多的是面向在线业务提供高并发、低延迟的访问。
  • 高可扩展:为应对爆发的数据量增长,可扩展是最核心的设计目标之一,所以底层架构往往在设计之初即考虑分布式架构。
4bf392d3f4c5bda0efa2730618a05d281f0c8970
从DBEngines的发展趋势统计上也可以看到,各类NoSQL数据库在近几年都是处于一个蓬勃发展的状态。阿里云TableStore作为一款分布式NoSQL数据库,在数据模型上选择了多模型的架构,同时支持WideColumn和Timeline。
WideColumn模型是由Bigtable提出,后被其他同类型系统广泛应用的一种经典模型,目前世界上的绝大部分半结构化、结构化数据都是存储在该模型系统中。除了WideColumn模型外,我们推出了另一种全新的数据模型:Timeline,Timeline模型是一种用于消息数据的新一代模型,适用于IM、Feeds和物联网设备消息下推等消息系统中消息的存储和同步,目前已经开始被广泛使用。接下来,我们详细了解下这两种模型。
 

Wide Column模型

e62e310507aa9c98d719f632dddad1fe2128b7ad
上图是Wide Column模型的一个模型图,为更好的理解这个模型,我们拿关系模型来做一个对比。关系模型可以简单的理解为一个二维的模型,由行列组成,每一行的列固定Schema。所以关系模型的特征是:二维以及固定Schema,这是一个最简单的理解,抛开事务和约束来看的话。Wide Column模型是一个三维的模型,在行与列二维的基础上,增加了一个时间维度。时间维度体现在属性列上,属性列可以拥有多个值,每个值对应一个Timestamp作为版本。并且每一行是Schema Free的,没有强Schema定义。所以Wide Column模型对比关系模型,简单总结就是:三维、Schema Free、简化事务和约束。
再详细看下这个模型的组成,有几个主要部分:
  • 主键(Primary Key):每一行都会有主键,主键会由多列(1-4列)构成,主键的定义是固定Schema,主键的作用主要是唯一区分一行数据。
  • 分区键(Partition Key):主键的第一列称为分区键,分区键用于对表进行范围分区,每个分区会分布式的调度到不同的机器上进行服务。在同一个分区键内,我们提供跨行事务。
  • 属性列(Attribute Column):一行中除开主键列外,其余都是属性列。属性列会对应多个值,不同值对应不同的版本,一行可存储不限个数个属性列。
  • 版本(Version):每一个值对应不同的版本,版本的值是一个时间戳,用于定义数据的生命周期。
  • 数据类型(Data Type):TableStore支持多种数据类型,包含String、Binary、Double、Integer和Boolean。
  • 生命周期(Time To Live):每个表可定义数据生命周期,例如生命周期配置为一个月,则该表数据中在一个月之前写入的数据就会被自动清理。数据的写入时间由版本来决定,版本一般由服务端在数据写入时根据服务器时间来定,也可由应用自己指定。
  • 最大版本数(MaxVersion):每个表可定义每一列最多保存的版本数,用于控制一列的版本的个数,老版本的超过个数上限的数据会被自动清理。
 
Wide Column模型的特色,总结来说就是:三维结构(行、列和时间)、宽行、多版本数据以及生命周期管理。同时Wide Column模型在数据操作层面,提供两类数据访问API,Data API和Stream API。

Data API

关于Data API的详细文档请参考这里,Data API是标准的数据API,提供数据的在线读写,包括:
  • PutRow:新插入一行,如果存在相同行,则覆盖。
  • UpdateRow:更新一行,可增加、删除一行中的属性列,或者更新已经存在的属性列的值。如果该行不存在,则新插入一行。
  • DeleteRow:删除一行。
  • BatchWriteRow:批量更新多张表的多行数据,可组合PutRow、UpdateRow和DeleteRow。
  • GetRow:读取一行数据。
  • GetRange:范围扫描数据,可正序扫描或者逆序扫描。
  • BatchGetRow:批量查询多张表的多行数据。

Stream API

在关系模型数据库中是没有对数据库内增量数据定义标准API的,但是在传统关系数据库的很多应用场景中,增量数据(binlog)的用途是不可忽视的。这个在阿里内部场景中,有很广泛的应用,并且提供了DRC这类中间件将这部分数据的能力完全挖掘了出来。将增量数据的能力挖掘出来后,我们可以在技术架构上做很多事:
  • 异构数据源复制:MySQL数据增量同步到NoSQL,做一个冷数据存储。
  • 对接流计算:可实时对MySQL内数据做统计,做一些大屏类应用。
  • 对接搜索系统:可将搜索系统扩展为MySQL的二级索引,增强MySQL内数据的检索能力。
 
但即使关系数据库的增量数据如此有用,业界也没有规范的API定义来获取这部分增量数据。TableStore是早早发觉了这部分数据存在的价值,提供了标准化的API来将这部分数据的能力开放出来,这就是我们的Stream API(文档)。
Stream API大致包括:
  • ListStream:获取表的Stream,范围Stream的ID。
  • DescribeStream:获取Stream的详细信息,拉取Stream内Shard列表,以及Shard结构树。
  • GetShardIterator:获取Shard当前增量数据的Iterator。
  • GetStreamRecord:根据Shard Iterator获取Shard内的增量数据。
 
TableStore Stream的实现会比MySQL Binlog复杂很多,因为TableStore本身是一个分布式的架构,Stream也是一个分布式的增量数据消费框架。Stream的数据消费必须保序获取,Stream的Shard与TableStore内部的表的分区一一对应,表的分区会存在分裂和合并,为保证在分区分裂和合并后老Shard和新增Shard的数据消费仍然能保序,我们设计了一套比较精密的机制。对于TableStore Stream的设计,不在这里赘述,我们之后会发布更详细的设计文档。
当前由于Stream内部架构的复杂,将这部分复杂度也引入到了Stream数据消费侧,在用户使用Stream API时并不是那么简单。在今年我们也规划了一个全新的数据消费通道服务,来简化Stream数据的消费,提供更简单易用的API,尽情期待。
 

Timeline模型

Timeline模型是我们针对消息数据场景所新创的一个数据模型,它的特色在于能够满足消息数据场景对消息保序、海量消息存储、实时同步的特殊需求。
b1d78af1aae4c48835a2f651841cf4c192a322fd
如上图是Timeline的模型图,将一张大表内的数据抽象为多个Timeline,一个大表能够承载的Timeline个数无上限。
Timeline的构成主要包括:
  • Timeline ID:唯一标识Timeline的ID。
  • Timeline Meta:Timeline的元数据,元数据内可包含任意键值对属性。
  • Message Sequence:消息队列,承载该Timeline下的所有消息。消息在队列里有序保存,并且根据写入顺序分配自增的ID。一个消息队列可承载的消息个数无上限,在消息队列内部可根据消息ID随机定位某条消息,并提供正序或者反序扫描。
  • Message Entry:消息体,包含消息的具体内容,可以包含任意键值对。
 
Timeline的模型逻辑上与消息队列有一些相似之处,Timeline类似于消息队列中的Topic。不同之处在于,TableStore Timeline更侧重Topic的规模。在即时通讯场景,每个用户的收件箱和寄件箱都是一个Topic,在物联网消息场景,每个设备对应一个Topic,Topic的量级会达到千万甚至亿级别。TableStore Timeline基于底层的分布式引擎,单表能支持理论无上限的Timeline(Topic),简化队列的Pub/Sub模型,支持消息保序、随机定位以及正反序扫描,更贴近即时通讯(IM)、Feeds流以及物联网消息系统等海量消息数据场景的需求。
 
关于Timeline模型的起源,可以看下这篇文章 - 《现代IM系统中消息推送和存储架构的实现》,具体的应用可以参考下这篇文章 - 《TableStore Timeline:轻松构建千万级IM和Feed流系统》。
 
Timeline是在去年新推出的一个数据模型,我们还在不断的打磨。基于这个模型,我们已经帮助钉钉、菜鸟智能客服、淘票票小聚场、智能设备管理等业务构建即时通讯、Feeds流、物联网等领域的消息系统,欢迎使用。
 
最后,欢迎加入我们的内部钉钉群(群号:11789671)进行交流。
ddae6563c197804daf28eea94d985cb05a927376

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
亿级消息系统的核心存储:Tablestore发布Timeline 2.0模型
互联网快速发展的今天,社交类应用、消息类功能大行其道,占据了大量网络流量。大至钉钉、微信、微博、知乎,小至各类App的推送通知,消息类功能几乎成为所有应用的标配。根据场景特点,我们可以将消息类场景归纳成三大类:IM(钉钉、微信)、Feed流(微博、知乎)以及常规消息队列。
10455 0
TableStore Timeline:轻松构建千万级IM和Feed流系统
在文章《现代IM系统中消息推送和存储架构的实现》中介绍了一种适用于IM的消息存储和推送模型Timeline,在本篇文章中,会扩展Timeline模型到IM和Feed流系统中,并且提供成熟的LIB实现。用户基于TableStore-Timeline LIB可轻松实现千万级的IM和Feed流系统。
16025 0
表格存储数据多版本介绍| 学习笔记
快速学习表格存储数据多版本介绍。
0 0
基于TableStore的海量气象格点数据解决方案实战 王怀远
基于TableStore的海量气象格点数据解决方案实战 王怀远
0 0
基于Tablestore 实现大规模订单系统海量订单/日志数据分类存储的实践
前言:从最早的互联网高速发展、到移动互联网的爆发式增长,再到今天的产业互联网、物联网的快速崛起,各种各样新应用、新系统产生了众多订单类型的需求,比如电商购物订单、银行流水、运营商话费账单、外卖订单、设备信息等,产生的数据种类和数据量越来越多;其中订单系统就是一个非常广泛、通用的系统。而随着数据规模的快速增长、大数据技术的发展、运营水平的不断提高,包括数据消费的能力要求越来越高,这对支撑订单系统的数据库设计、存储系统也提出了更多的要求。在新的需求下,传统的经典架构面临着诸多挑战,需要进一步思考架构优化,以更好支撑业务发展;
0 0
使用 Data Lake Formation(DLF) 进行 Tablestore 数据实时入湖
本文介绍使用 Data Lake Formation (DLF)服务,实时订阅 Tablestore(原 OTS) 的数据,并以 Delta Lake 的格式投递进入 OSS,构建实时数据湖。 ## 架构介绍 表格存储是一种全托管的云原生数据库,使用表格存储您无需担心软硬件预置、配置、故障、集群扩展、安全等问题。提供高服务可用性的同时极大地减少了管理成本。 表格存储支持多种数据库模型
0 0
海量结构化数据解决方案-表格存储场景解读
数据是驱动业务创新的最核心的资产。不同类型的数据如非结构化数据(视频、图片等)、结构化数据(订单、轨迹),面向不同业务的使用要求需要选择适合的存储引擎,能够真正发挥数据的价值。针对于海量的非强事务的海量结构化/半结构数据,表格存储一站式解决。这里详细解读该适合场景的使用解读。
0 0
阿里云物联网平台数据转发到表格存储(Table Store)示例参考
本文主要结合物模型的结构体类型属性数据,演示payLoad的设置及规则引擎的配置。
0 0
玩转Tablestore:使用Grafana快速展示时序数据
Grafana 是一款采用 go 语言编写的开源应用,主要用于大规模指标数据的可视化展现,是网络架构和应用分析中最流行的时序数据展示工具,可以通过将采集的数据查询然后可视化的展示,实现报警通知;Grafana拥有丰富的数据源,官方支持以下数据源:Graphite,Elasticsearch,InfluxDB,Prometheus,Cloudwatch,MySQ
0 0
通过EMR Spark Streaming实时读取Tablestore数据
本文将介绍如何在E-MapReduce中实时流式的处理Tablestore中的数据。 场景设计 随着互联网的发展,企业中积累的数据越来越多,数据的背后隐藏着巨大的价值,在双十一这样的节日中,电子商务企业都会在大屏幕上实时显示订单总量,由于订单总量巨大,不可能每隔一秒就到数据库中进行一次SQL统计,此时就需要用到流计算,而传统的方法都是需要借助Kafka消息队列来做流式计算,数据订单需要写入数据库与Kafka中,Spark Streaming 消费来自Kafka中的订单信息。
2431 0
+关注
木洛
阿里云高级技术专家,表格存储(TableStore)研发,专注NoSQL领域技术和解决方案。
文章
问答
来源圈子
更多
阿里云存储基于飞天盘古2.0分布式存储系统,产品包括对象存储OSS、块存储Block Storage、共享文件存储NAS、表格存储、日志存储与分析、归档存储及混合云存储等,充分满足用户数据存储和迁移上云需求,连续三年跻身全球云存储魔力象限四强。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
玩转 Tablestore 入门与实战
立即下载
TableStore在社交类场景下的应用
立即下载
一站式结构化数据存储Tablestore实战手册
立即下载