摘要：?前言 TableStore是阿里云自研的一款分布式NoSQL數據庫，提到NoSQL數據庫，現在對很多應用研發來說都已經不再陌生。當前很多應用系統底層不會再僅僅依賴于關系型數據庫，而是會根據不同的業務場景，來選型使用不同類型的數據庫，例如緩存型KeyValue數據會存儲在Redis，文檔型數據會存儲在MongoDB，圖數據會存儲在Neo4J等。

前言

TableStore是阿里云自研的一款分布式NoSQL數據庫，提到NoSQL數據庫，現在對很多應用研發來說都已經不再陌生。當前很多應用系統底層不會再僅僅依賴于關系型數據庫，而是會根據不同的業務場景，來選型使用不同類型的數據庫，例如緩存型KeyValue數據會存儲在Redis，文檔型數據會存儲在MongoDB，圖數據會存儲在Neo4J等。

回顧下NoSQL的發展歷程，NoSQL誕生于Web 2.0時代，互聯網高速發展的一個時代，也帶來了一次互聯網數據的爆發。傳統的關系型數據庫很難承載如此海量的數據，需要一種具備高擴展能力的分布式數據庫。但基于傳統的關系數據模型，去實現高可用和可擴展的分布式數據庫是非常有挑戰的一件事?；ヂ摼W上大部分數據的數據模型很簡單，沒必要一概用關系模型來建模。如果能打破關系模型以一種更簡單的數據模型來對數據建模、弱化事務和約束、以高可用和可擴展為目標，以此為目標設計的數據庫能更好的滿足業務需求，正是基于此種理念推動了NoSQL的發展。

總結下，NoSQL的發展是基于互聯網時代對業務的新挑戰以及數據庫的新需求而推動的，基于此發展起來的NoSQL，有其顯著的特征：

• 多數據模型：為滿足不同數據的需求，誕生出了很多不同的數據模型，例如KeyValue、Document、Wide Column、Graph以及Time Series等。這是NoSQL數據庫發展的一個最顯著特征，打破了關系模型的約束，選擇一個多元的發展方向。數據模型的選擇是更加場景化的，更貼近業務的實際需求，能夠做更深層次的優化。

• 高并發、低延遲：NoSQL數據庫的發展更多由在線業務的需求推動，其設計目標更多的是面向在線業務提供高并發、低延遲的訪問。

• 高可擴展：為應對爆發的數據量增長，可擴展是最核心的設計目標之一，所以底層架構往往在設計之初即考慮分布式架構。

從DBEngines的發展趨勢統計上也可以看到，各類NoSQL數據庫在近幾年都是處于一個蓬勃發展的狀態。阿里云TableStore作為一款分布式NoSQL數據庫，在數據模型上選擇了多模型的架構，同時支持WideColumn和Timeline。

WideColumn模型是由Bigtable提出，后被其他同類型系統廣泛應用的一種經典模型，目前世界上的絕大部分半結構化、結構化數據都是存儲在該模型系統中。除了WideColumn模型外，我們推出了另一種全新的數據模型：Timeline，Timeline模型是一種用于消息數據的新一代模型，適用于IM、Feeds和物聯網設備消息下推等消息系統中消息的存儲和同步，目前已經開始被廣泛使用。接下來，我們詳細了解下這兩種模型。

?

Wide Column模型

上圖是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模型是我們針對消息數據場景所新創的一個數據模型，它的特色在于能夠滿足消息數據場景對消息保序、海量消息存儲、實時同步的特殊需求。

如上圖是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）進行交流。

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。