Table Store是阿里巴巴云的第一个分布式多模型数据库，它是一个NoSQL数据库。 目前，许多应用系统不再仅仅依赖底层的关系数据库，而是根据不同的业务场景使用不同的数据库。 例如，缓存键值数据将存储在Redis中，文档数据将存储在MongoDB中，图形数据将存储在Neo4J中。
回顾NoSQL的发展:NoSQL诞生于网络2时代。0. 互联网飞速发展的时代也带来了互联网数据的爆炸式增长。 传统的关系数据库无法处理如此大量的数据，需要一个具有高扩展性的分布式数据库。 然而，基于传统的关系数据模型实现高可用性和可伸缩性的分布式数据库是非常具有挑战性的。 互联网上大多数数据的数据模型都很简单，不需要关系模型来建模。 如果可以使用更简单的数据模型来代替关系模型到模型的数据，削弱事务和约束，并以高可用性和可伸缩性为目标，那么以这种方式设计的数据库将更好地满足业务需求。 这样的理念促进了NoSQL的发展。
总之，NoSQL的发展是基于新的业务挑战和互联网时代对数据库的新需求。 在此基础上发展起来的NoSQL具有鲜明的特点:
- 多数据模型: 为了满足不同数据类型的需要，已经创建了许多不同的数据模型，例如键值、文档、宽列、图形和时间序列。 这是NoSQL数据库最显著的特点之一，它突破了关系模型的约束，选择了多元化的发展方向。 数据模型的选择更加面向场景，更加符合业务的实际需求，并且可以进一步优化。
- 高并发性和低延迟: NoSQL数据库的发展主要受网上业务需求的驱动，其设计目标更多的是为网上业务提供高并发、低延迟的访问。
- 高可用性: 为了应对数据量的爆炸式增长，可扩展性是核心设计目标之一，因此在设计之初就倾向于考虑分布式底层架构。
数据库引擎的发展趋势表明，近年来各种NoSQL数据库经历了重大发展。 作为一个分布式NoSQL数据库，阿里巴巴云的表存储在数据模型方面采用了多模型架构，并且支持宽列和时间序列。
宽列模型是BigTable提出的一个经典模型，被其他同类系统广泛使用。 目前，世界上大多数半结构化和结构化数据都是用这种模型存储的。 除了宽柱模型之外，我们还引入了另一种新的数据模型:时间序列，这是一种新一代的消息数据模型，适用于即时消息、订阅源和物联网设备下推等消息传递系统中的消息存储和同步，现已得到广泛应用。 接下来，将详细描述这两个模型。
以上是宽柱模型的示意图。 为了更好地理解这个模型，我们采用一个关系模型进行比较。 关系模型可以简单地理解为由行和列组成的二维模型，每行都有固定的模式。 因此，关系模型的特征是二维和固定模式，这是除了事务和约束之外最简单的理解。 宽列模型是一个三维模型，除了行和列这两个维度之外，还有一个时间维度。 时间维度反映在属性列中，属性列有多个值，每个值对应一个时间戳作为版本。 每一行都是无模式的，没有强模式定义。 因此宽列模型和关系模型的区别在于:三维、无模式、简化的事务和约束。
该模型包括:
- 主键:每行都有一个主键，由多个(1 – 4)列组成。 主键是用固定模式定义的，主要用于唯一标识一行数据。
- 分区键:主键的第一列称为分区键，用于对表进行分区。 每个分区被分配给不同的机器进行服务。 在同一个分区键中，提供了跨行事务。
- 属性列:行中除主键列之外的所有列都是属性列。 一个属性列对应多个值，不同的值对应不同的版本，一行可以存储无限多个属性列。
- 版本:每个值对应一个不同的版本，其值是一个定义数据生存时间的时间戳。
- 数据类型:表存储支持多种数据类型，包括字符串、二进制、双精度、整数和布尔。
- 生存时间:可以为每个表定义生存时间。 例如，如果生存时间被配置为一个月，则在一个月之前写入表数据的数据将被自动清除。 数据的写入时间由版本决定，通常由服务器端写入数据的时间决定，也可以由应用程序指定。
- 最大版本:可以为每个表定义每个列中保存的最大版本数，用于控制一列中的版本数。 超过最大版本号的数据将被自动清除。
宽列模型的特征概括为三维结构(行、列和时间)、宽行、多版本数据和生存时间管理。 另外，在数据操作方面，宽列模型提供了两个数据访问接口，数据接口和流接口。
数据应用编程接口是一个标准的数据应用编程接口，提供在线数据读/写，包括:
- 插入一个新行，如果它存在，覆盖相同的行。
- 更新行:更新行，可用于添加或删除行中的属性列，或更新现有属性列的值。 如果该行不存在，将插入一个新行。
- 删除行:删除一行。
- 批量更新:批量更新多个表中的多行数据，可以组合PutRow、UpdateRow和DeleteRow。
- 从一行中读取数据。
- 按升序或降序扫描一个范围内的数据。
- 批量读取多个表中的多个行。
在关系模型数据库中，对于数据库中的增量数据没有标准的应用编程接口，而在传统关系数据库的许多应用场景中，不能忽略增量数据(binlog)的使用。 这在阿里巴巴内部被广泛使用，并提供了数字版权控制中间件来充分利用这部分数据。 在充分利用增量数据后，我们可以在技术架构方面做很多事情:
- 异构数据源复制:MySQL数据可以增量同步到NoSQL进行冷数据存储。
- 与StreamCompute的集成:MySQL数据可以为一些控制室显示应用程序进行实时分析。
- 与搜索系统的集成:搜索系统可以扩展到MySQL的二级索引，以增强MySQL中的数据检索。
然而，即使关系数据库的增量数据是有用的，行业也没有标准的应用编程接口定义来获取这些数据。 表存储早就认识到了这些数据的价值，并提供了一个标准的应用编程接口来充分利用这些数据。 这是我们的流应用编程接口(文档)。
流应用编程接口通常包括:
- 列表流: 获取表的流和范围流的标识。
- 描述流: 获取流的细节，并在流中提取碎片列表和碎片树。
- GetShardIterator: 获取碎片当前增量数据的迭代器。
- GetStreamRecord: 根据分片迭代器获取分片中的增量数据。
表存储流的实现比MySQL Binlog复杂得多，因为表存储有一个分布式体系结构，而流也有一个分布式增量数据消费框架。 流的数据消耗必须以保持顺序的方式获得。 流的碎片对应于表存储中的表的分区。 表的分区可以拆分和合并。 为了确保分区分割和合并后新旧碎片的数据消耗保持有序，我们设计了一种更复杂的机制。 这里不描述表存储流的设计，稍后我们将提供更详细的设计文档。
因为流的内部架构的复杂性也影响了流的数据消费方面，所以用户使用流应用编程接口并不容易。 我们今年计划的新数据消费渠道服务即将推出，以简化数据流的数据消费，并提供一个更简单易用的应用编程接口。
时间序列模型是我们为消息数据场景创建的新数据模型。 它可以满足消息数据场景对消息顺序保持、海量消息存储和实时同步的特殊要求。
上面是时间序列模型的示意图，它将一个大表中的数据抽象成多个时间序列。 大型表中时间序列的数量没有限制。
时间序列包括:
- 时间序列标识:该标识唯一标识一个时间序列。
- 时间序列元数据:时间序列元数据，可以包含任何键值对属性。
- 消息序列:它携带时间序列中的所有消息。 消息按顺序存储，并根据写入顺序分配递增的标识。 一个消息序列可以携带无限数量的消息。 可以随机使用消息标识来定位序列中的消息，并且可以提供升序或降序扫描。
- 消息条目:它包含消息的详细内容，并且可以包含任何键值对。
时间序列模型在逻辑上类似于消息队列，时间序列类似于消息序列中的主题。 区别在于表存储时间序列更关注主题的规模。 在即时消息场景中，用户的收件箱或发件箱都是一个主题。 在物联网消息场景中，每个设备对应一个主题，主题的规模将达到1000万甚至1亿。 表存储时间序列基于底层分布式引擎。 单个表理论上可以支持无限数量的时间序列(主题)，这简化了序列的发布/订阅模型。 它还支持消息顺序保存、随机定位以及升序和降序扫描。 它更好地满足了具有大量消息数据的场景的需求，例如即时消息、订阅源和物联网消息系统。
时间序列是去年推出的一种新的数据模型，目前正在不断优化。 基于这一模式，我们已经帮助鼎新、菜鸟智能客服、桃朴小常、智能设备管理等服务建立了即时消息、订阅源和物联网消息的消息传递系统。