摘要： 前语 TableStore是阿里云自研的一款分布式NoSQL数据库，说到NoSQL数据库，现在对许多运用研制来说都现已不再生疏。当时许多运用体系底层不会再只是依赖于联系型数据库，而是会依据不同的事务场景，来选型运用不同类型的数据库，例如缓存型KeyValue数据会存储在Redis，文档型数据会存储在MongoDB，图数据会存储在Neo4J等。
TableStore是阿里云自研的一款分布式NoSQL数据库，说到NoSQL数据库，现在对许多运用研制来说都现已不再生疏。当时许多运用体系底层不会再只是依赖于联系型数据库，而是会依据不同的事务场景，来选型运用不同类型的数据库，例如缓存型KeyValue数据会存储在Redis，文档型数据会存储在MongoDB，图数据会存储在Neo4J等。
回忆下NoSQL的开展进程，NoSQL诞生于Web 2.0年代，互联网高速开展的一个年代，也带来了一次互联网数据的迸发。传统的联系型数据库很难承载如此海量的数据，需求一种具有高扩展才能的分布式数据库。但根据传统的联系数据模型，去完成高可用和可扩展的分布式数据库对错常有应战的一件事。互联网上大部分数据的数据模型很简略，没必要一概用联系模型来建模。如果能打破联系模型以一种更简略的数据模型来对数据建模、弱化事务和束缚、以高可用和可扩展为方针，以此为方针规划的数据库能更好的满意事务需求，正是根据此种理念推进了NoSQL的开展。
总结下，NoSQL的开展是根据互联网年代对事务的新应战以及数据库的新需求而推进的，根据此开展起来的NoSQL，有其明显的特征：
从DBEngines的开展趋势计算上也能够看到，各类NoSQL数据库在近几年都是处于一个蓬勃开展的状况。阿里云TableStore作为一款分布式NoSQL数据库，在数据模型上挑选了多模型的架构，一起支撑WideColumn和Timeline。
WideColumn模型是由Bigtable提出，后被其他同类型体系广泛运用的一种经典模型，现在世界上的绝大部分半结构化、结构化数据都是存储在该模型体系中。除了WideColumn模型外，咱们推出了另一种全新的数据模型：Timeline，Timeline模型是一种用于音讯数据的新一代模型，适用于IM、Feeds和物联网设备音讯下推等音讯体系中音讯的存储和同步，现在现已开端被广泛运用。接下来，咱们详细了解下这两种模型。
上图是Wide Column模型的一个模型图，为更好的了解这个模型，咱们拿联系模型来做一个比照。联系模型能够简略的了解为一个二维的模型，由队伍组成，每一行的列固定Schema。所以联系模型的特征是：二维以及固定Schema，这是一个最简略的了解，抛开事务和束缚来看的话。Wide Column模型是一个三维的模型，内行与列二维的基础上，增加了一个时刻维度。时刻维度体现在特点列上，特点列能够具有多个值，每个值对应一个Timestamp作为版别。而且每一行是Schema Free的，没有强Schema界说。所以Wide Column模型比照联系模型，简略总结就是：三维、Schema Free、简化事务和束缚。
再详细看下这个模型的组成，有几个首要部分：
Wide Column模型的特征，总结来说就是：三维结构（行、列和时刻）、宽行、多版别数据以及生命周期办理。一起Wide Column模型在数据操作层面，供给两类数据拜访API，Data API和Stream API。
Data API关于Data API的详细文档请参阅这儿，Data API是标准的数据API，供给数据的在线读写，包含：
Stream API在联系模型数据库中是没有对数据库内增量数据界说标准API的，但是在传统联系数据库的许多运用场景中，增量数据（binlog）的用处是不行忽视的。这个在阿里内部场景中，有很广泛的运用，而且供给了DRC这类中间件将这部分数据的才能彻底发掘了出来。将增量数据的才能发掘出来后，咱们能够在技能架构上做许多事：
但即便联系数据库的增量数据如此有用，业界也没有标准的API界说来获取这部分增量数据。TableStore是早早发觉了这部分数据存在的价值，供给了标准化的API来将这部分数据的才能敞开出来，这就是咱们的Stream API（文档）。
Stream API大致包含：
TableStore Stream的完成会比MySQL Binlog杂乱许多，因为TableStore自身是一个分布式的架构，Stream也是一个分布式的增量数据消费结构。Stream的数据消费有必要保序获取，Stream的Shard与TableStore内部的表的分区一一对应，表的分区会存在割裂和兼并，为确保在分区割裂和兼并后老Shard和新增Shard的数据消费依然能保序，咱们规划了一套比较精细的机制。关于TableStore Stream的规划，不在这儿赘述，咱们之后会发布更详细的规划文档。
当时因为Stream内部架构的杂乱，将这部分杂乱度也引进到了Stream数据消费侧，在用户运用Stream API时并不是那么简略。在本年咱们也规划了一个全新的数据消费通道效劳，来简化Stream数据的消费，供给更简略易用的API，纵情等待。
Timeline模型是咱们针对音讯数据场景所新创的一个数据模型，它的特征在于能够满意音讯数据场景对音讯保序、海量音讯存储、实时同步的特别需求。
如上图是Timeline的模型图，将一张大表内的数据笼统为多个Timeline，一个大表能够承载的Timeline个数无上限。
Timeline的构成首要包含：
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流、物联网等范畴的音讯体系，欢迎运用。
作者：木洛
