全部产品
阿里云办公

Table Store 数据模型 - Wide Column 和 Timeline

更新时间:2018-08-17 21:29:17

前言

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

传统的关系型数据库很难承载如此海量的数据,需要一种具备高扩展能力的分布式数据库。但基于传统的关系数据模型,实现高可用和可扩展的分布式数据库非常困难。如果能打破关系模型,以一种更简单的数据模型对数据建模、弱化事务和约束、以高可用和可扩展、能更好地满足业务需求为设计理念,基于这样的理念推动了 NoSQL 的发展。

1

NoSQL 具有以下特征:

  • 多数据模型

    为满足不同数据的需求,提供了多数据模型供您选择,例如 KeyValue、Document、Wide Column、Graph 以及 Time Series 等。NoSQL数据库打破了关系模型的约束,选择了多元的发展方向。多数据模型更贴近不同场景的实际需求。

  • 高并发、低延迟

    NoSQL 的设计目标是面向在线业务提供高并发、低延迟的访问。

  • 高可扩展

    为应对爆发的数据量增长,可扩展是核心的设计目标之一。

DB-Engines 旨在收集和介绍数据库管理系统(DBMS)方面的信息。下面展示了 DB-Engines 收集到的各类 NoSQL 数据库从 2013 年到 2018 年的发展趋势。

2

从 DB-Engines 的发展趋势来看,各类 NoSQL 数据库在近几年都处于一个蓬勃发展的状态。阿里云 Table Store 作为一款分布式 NoSQL 数据库,在数据模型上选择了多模型的架构,同时支持 Wide Column 和 Timeline。

Wide Column 模型由 Bigtable 提出,后被其他同类型系统广泛应用的一种经典模型。目前绝大部分半结构化、结构化数据都存储在该模型系统中。除了 Wide Column 模型外,我们推出了另一种全新的数据模型 Timeline。Timeline 模型是一种用于消息数据的新一代模型,适用于 IM、Feeds 和物联网设备消息下推等消息系统中消息的存储和同步,目前已被广泛使用。接下来,我们详细了解下这两种模型。

Wide Column 模型

3

Wide Column 模型对比关系模型的区别如下:

  • Wide Column 模型具有以下特征:三维结构(行、列和时间)、schema-free、宽行、多版本数据以及生命周期管理。

  • 关系模型的特征如下:二维(行、列)以及固定的Schema。

Wide Column 模型由以下几个部分组成:

  • 主键(Primary Key):每一行都会有主键,主键会由多列(1-4列)构成,主键的定义是固定 Schema,主键主要用于唯一区分一行数据。

  • 分区键(Partition Key):主键的第一列称为分区键,分区键用于对表进⾏范围分区。每个分区会分布式的调度到不同的机器上进行服务。在同一个分区键内,我们提供跨行事务。

  • 属性列(Attribute Column):一行中除主键列外,其余都是属性列。属性列会对应多个值,不同值对应不同的版本,一行可存储不限个数个属性列。

  • 版本(Version):每一个值对应不同的版本,版本的值是一个时间戳,用于定义数据的生命周期。

  • 数据类型(Data Type):Table Store 支持多种数据类型,包含 String、Binary、Double、Integer 和 Boolean。

  • 生命周期(Time To Live):每个表可定义数据生命周期。例如生命周期配置为一个月,则该表数据中在一个月之前写入的数据就会被自动清理。数据的写入时间由版本来决定,版本一般由服务端在数据写入时根据服务器时间来定,也可由应用指定。

  • 最大版本数(Max Versions):每个表可定义每一列最多保存的版本数,用于控制一列的版本的个数。当一个属性列的版本个数超过 Max Versions 时,最早的版本将被异步删除。

同时 Wide Column 模型在数据操作层面,提供两类数据访问 API:Data API 和 Stream API。

Data API

关于 Data API 的详细文档,请参考表格存储的数据操作。Data API 是标准的数据 API,提供数据的在线读写,包括:

  • PutRow:新插入一行,如果存在相同行,则覆盖。

  • UpdateRow:更新一行,可增加、删除一行中的属性列,或者更新已经存在的属性列的值。如果该行不存在,则新插入一行。

  • DeleteRow:删除一行。

  • BatchWriteRow:批量更新多张表的多行数据。

  • GetRow:读取一行数据。

  • GetRange:范围扫描数据,可正序扫描或者逆序扫描。

  • BatchGetRow:批量查询多张表的多行数据。

Stream API

在关系模型数据库中没有对数据库内增量数据定义标准的 API,但是在传统关系数据库的很多应用场景中,增量数据(Binlog)的用途不可忽视。Table Store将增量数据的能力挖掘出来后可以在技术架构上实现:

  • 异构数据源复制:MySQL 数据增量同步到 NoSQL,做冷数据存储。
  • 对接流计算:可实时对MySQL内数据做统计,做一些大屏类应用。
  • 对接搜索系统:可将搜索系统扩展为 MySQL 的二级索引,增强 MySQL 内数据的检索能力。

Table Store挖掘了增量数据存在的价值,并提供了标准的Stream API。Steam API提供的接口如下:

  • ListStream:获取表的 Stream 信息,如 StreamID。
  • DescribeStream:获取 Stream 的详细信息,如 Shard 列表、Shard 结构树等。
  • GetShardIterator:获取 Shard 当前增量数据的 Iterator。
  • GetStreamRecord:根据 ShardIterator 获取 Shard 内的增量数据。

Table Store Stream 的实现会比 MySQL Binlog 复杂得多。因为 Table Store 本身是一个分布式的架构,Stream 也是一个分布式的增量数据消费框架。Stream 的数据消费必须保序获取,Stream 的 Shard 与 Table Store 内部表的分区一一对应,且表的分区会存在分裂和合并。

Timeline 模型

Timeline 模型是针对消息数据场景所设计的数据模型,它能满足消息数据场景对消息保序、海量消息存储、实时同步的特殊需求。

4

说明:将一张大的数据表内的数据抽象为多个 Timeline,能够承载的 Timeline 个数无上限。

Timeline 的构成主要包括:

  • Timeline ID:用于唯一标识 Timeline。
  • Timeline Meta:Timeline 的元数据,元数据内可包含任意键值对属性。
  • Message Sequence:消息队列,承载该 Timeline下的所有消息。

    说明: 消息在队列里有序保存,并且根据写入顺序分配自增的 ID。一个消息队列可承载的消息个数无上限,在消息队列内部可根据消息 ID 随机定位某条消息,并提供正序或者反序扫描。

  • Message Entry:消息体,包含消息的具体内容,可以包含任意键值对。

有关 Timeline 模型的起源,请查看现代IM系统中消息推送和存储架构的实现。有关 Timeline 模型的具体应用,请查看Table Store Timeline:轻松构建千万级 IM 和 Feed 流系统

本文导读目录