TableStore數據模型 - WideColumn和Timeline

前言

TableStore是阿里雲自研的一款分佈式NoSQL數據庫，提到NoSQL數據庫，如今對不少應用研發來講都已經再也不陌生。當前不少應用系統底層不會再僅僅依賴於關係型數據庫，而是會根據不一樣的業務場景，來選型使用不一樣類型的數據庫，例如緩存型KeyValue數據會存儲在Redis，文檔型數據會存儲在MongoDB，圖數據會存儲在Neo4J等。

回顧下NoSQL的發展歷程，NoSQL誕生於Web 2.0時代，互聯網高速發展的一個時代，也帶來了一次互聯網數據的爆發。傳統的關係型數據庫很難承載如此海量的數據，須要一種具有高擴展能力的分佈式數據庫。但基於傳統的關係數據模型，去實現高可用和可擴展的分佈式數據庫是很是有挑戰的一件事。互聯網上大部分數據的數據模型很簡單，不必一律用關係模型來建模。若是能打破關係模型以一種更簡單的數據模型來對數據建模、弱化事務和約束、以高可用和可擴展爲目標，以此爲目標設計的數據庫能更好的知足業務需求，正是基於此種理念推進了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流、物聯網等領域的消息系統，歡迎使用。

本文做者：木洛

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。