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

前言

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

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

總結(jié)下，NoSQL的發(fā)展是基于互聯(lián)網(wǎng)時代對業(yè)務(wù)的新挑戰(zhàn)以及數(shù)據(jù)庫的新需求而推動的，基于此發(fā)展起來的NoSQL，有其顯著的特征：

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

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

• 高可擴展：為應(yīng)對爆發(fā)的數(shù)據(jù)量增長，可擴展是最核心的設(shè)計目標之一，所以底層架構(gòu)往往在設(shè)計之初即考慮分布式架構(gòu)。

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

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

?

Wide Column模型

上圖是Wide Column模型的一個模型圖，為更好的理解這個模型，我們拿關(guān)系模型來做一個對比。關(guān)系模型可以簡單的理解為一個二維的模型，由行列組成，每一行的列固定Schema。所以關(guān)系模型的特征是：二維以及固定Schema，這是一個最簡單的理解，拋開事務(wù)和約束來看的話。Wide Column模型是一個三維的模型，在行與列二維的基礎(chǔ)上，增加了一個時間維度。時間維度體現(xiàn)在屬性列上，屬性列可以擁有多個值，每個值對應(yīng)一個Timestamp作為版本。并且每一行是Schema Free的，沒有強Schema定義。所以Wide Column模型對比關(guān)系模型，簡單總結(jié)就是：三維、Schema Free、簡化事務(wù)和約束。

再詳細看下這個模型的組成，有幾個主要部分：

• 主鍵（Primary Key）：每一行都會有主鍵，主鍵會由多列（1-4列）構(gòu)成，主鍵的定義是固定Schema，主鍵的作用主要是唯一區(qū)分一行數(shù)據(jù)。

• 分區(qū)鍵（Partition Key）：主鍵的第一列稱為分區(qū)鍵，分區(qū)鍵用于對表進行范圍分區(qū)，每個分區(qū)會分布式的調(diào)度到不同的機器上進行服務(wù)。在同一個分區(qū)鍵內(nèi)，我們提供跨行事務(wù)。

• 屬性列（Attribute Column）：一行中除開主鍵列外，其余都是屬性列。屬性列會對應(yīng)多個值，不同值對應(yīng)不同的版本，一行可存儲不限個數(shù)個屬性列。

• 版本（Version）：每一個值對應(yīng)不同的版本，版本的值是一個時間戳，用于定義數(shù)據(jù)的生命周期。

• 數(shù)據(jù)類型（Data Type）：TableStore支持多種數(shù)據(jù)類型，包含String、Binary、Double、Integer和Boolean。

• 生命周期（Time To Live）：每個表可定義數(shù)據(jù)生命周期，例如生命周期配置為一個月，則該表數(shù)據(jù)中在一個月之前寫入的數(shù)據(jù)就會被自動清理。數(shù)據(jù)的寫入時間由版本來決定，版本一般由服務(wù)端在數(shù)據(jù)寫入時根據(jù)服務(wù)器時間來定，也可由應(yīng)用自己指定。

• 最大版本數(shù)（MaxVersion）：每個表可定義每一列最多保存的版本數(shù)，用于控制一列的版本的個數(shù)，老版本的超過個數(shù)上限的數(shù)據(jù)會被自動清理。

?

Wide Column模型的特色，總結(jié)來說就是：三維結(jié)構(gòu)（行、列和時間）、寬行、多版本數(shù)據(jù)以及生命周期管理。同時Wide Column模型在數(shù)據(jù)操作層面，提供兩類數(shù)據(jù)訪問API，Data API和Stream API。

Data API

關(guān)于Data API的詳細文檔請參考這里，Data API是標準的數(shù)據(jù)API，提供數(shù)據(jù)的在線讀寫，包括：

• PutRow：新插入一行，如果存在相同行，則覆蓋。

• UpdateRow：更新一行，可增加、刪除一行中的屬性列，或者更新已經(jīng)存在的屬性列的值。如果該行不存在，則新插入一行。

• DeleteRow：刪除一行。

• BatchWriteRow：批量更新多張表的多行數(shù)據(jù)，可組合PutRow、UpdateRow和DeleteRow。

• GetRow：讀取一行數(shù)據(jù)。

• GetRange：范圍掃描數(shù)據(jù)，可正序掃描或者逆序掃描。

• BatchGetRow：批量查詢多張表的多行數(shù)據(jù)。

Stream API

在關(guān)系模型數(shù)據(jù)庫中是沒有對數(shù)據(jù)庫內(nèi)增量數(shù)據(jù)定義標準API的，但是在傳統(tǒng)關(guān)系數(shù)據(jù)庫的很多應(yīng)用場景中，增量數(shù)據(jù)（binlog）的用途是不可忽視的。這個在阿里內(nèi)部場景中，有很廣泛的應(yīng)用，并且提供了DRC這類中間件將這部分數(shù)據(jù)的能力完全挖掘了出來。將增量數(shù)據(jù)的能力挖掘出來后，我們可以在技術(shù)架構(gòu)上做很多事：

• 異構(gòu)數(shù)據(jù)源復(fù)制：MySQL數(shù)據(jù)增量同步到NoSQL，做一個冷數(shù)據(jù)存儲。

• 對接流計算：可實時對MySQL內(nèi)數(shù)據(jù)做統(tǒng)計，做一些大屏類應(yīng)用。

• 對接搜索系統(tǒng)：可將搜索系統(tǒng)擴展為MySQL的二級索引，增強MySQL內(nèi)數(shù)據(jù)的檢索能力。

?

但即使關(guān)系數(shù)據(jù)庫的增量數(shù)據(jù)如此有用，業(yè)界也沒有規(guī)范的API定義來獲取這部分增量數(shù)據(jù)。TableStore是早早發(fā)覺了這部分數(shù)據(jù)存在的價值，提供了標準化的API來將這部分數(shù)據(jù)的能力開放出來，這就是我們的Stream API（文檔）。

Stream API大致包括：

• ListStream：獲取表的Stream，范圍Stream的ID。

• DescribeStream：獲取Stream的詳細信息，拉取Stream內(nèi)Shard列表，以及Shard結(jié)構(gòu)樹。

• GetShardIterator：獲取Shard當前增量數(shù)據(jù)的Iterator。

• GetStreamRecord：根據(jù)Shard Iterator獲取Shard內(nèi)的增量數(shù)據(jù)。

?

TableStore Stream的實現(xiàn)會比MySQL Binlog復(fù)雜很多，因為TableStore本身是一個分布式的架構(gòu)，Stream也是一個分布式的增量數(shù)據(jù)消費框架。Stream的數(shù)據(jù)消費必須保序獲取，Stream的Shard與TableStore內(nèi)部的表的分區(qū)一一對應(yīng)，表的分區(qū)會存在分裂和合并，為保證在分區(qū)分裂和合并后老Shard和新增Shard的數(shù)據(jù)消費仍然能保序，我們設(shè)計了一套比較精密的機制。對于TableStore Stream的設(shè)計，不在這里贅述，我們之后會發(fā)布更詳細的設(shè)計文檔。

當前由于Stream內(nèi)部架構(gòu)的復(fù)雜，將這部分復(fù)雜度也引入到了Stream數(shù)據(jù)消費側(cè)，在用戶使用Stream API時并不是那么簡單。在今年我們也規(guī)劃了一個全新的數(shù)據(jù)消費通道服務(wù)，來簡化Stream數(shù)據(jù)的消費，提供更簡單易用的API，盡情期待。

?

Timeline模型

Timeline模型是我們針對消息數(shù)據(jù)場景所新創(chuàng)的一個數(shù)據(jù)模型，它的特色在于能夠滿足消息數(shù)據(jù)場景對消息保序、海量消息存儲、實時同步的特殊需求。

如上圖是Timeline的模型圖，將一張大表內(nèi)的數(shù)據(jù)抽象為多個Timeline，一個大表能夠承載的Timeline個數(shù)無上限。

Timeline的構(gòu)成主要包括：

• Timeline ID：唯一標識Timeline的ID。

• Timeline Meta：Timeline的元數(shù)據(jù)，元數(shù)據(jù)內(nèi)可包含任意鍵值對屬性。

• Message Sequence：消息隊列，承載該Timeline下的所有消息。消息在隊列里有序保存，并且根據(jù)寫入順序分配自增的ID。一個消息隊列可承載的消息個數(shù)無上限，在消息隊列內(nèi)部可根據(jù)消息ID隨機定位某條消息，并提供正序或者反序掃描。

• Message Entry：消息體，包含消息的具體內(nèi)容，可以包含任意鍵值對。

?

Timeline的模型邏輯上與消息隊列有一些相似之處，Timeline類似于消息隊列中的Topic。不同之處在于，TableStore Timeline更側(cè)重Topic的規(guī)模。在即時通訊場景，每個用戶的收件箱和寄件箱都是一個Topic，在物聯(lián)網(wǎng)消息場景，每個設(shè)備對應(yīng)一個Topic，Topic的量級會達到千萬甚至億級別。TableStore Timeline基于底層的分布式引擎，單表能支持理論無上限的Timeline（Topic），簡化隊列的Pub/Sub模型，支持消息保序、隨機定位以及正反序掃描，更貼近即時通訊（IM）、Feeds流以及物聯(lián)網(wǎng)消息系統(tǒng)等海量消息數(shù)據(jù)場景的需求。

?

關(guān)于Timeline模型的起源，可以看下這篇文章 - 《現(xiàn)代IM系統(tǒng)中消息推送和存儲架構(gòu)的實現(xiàn)》，具體的應(yīng)用可以參考下這篇文章 - 《TableStore Timeline：輕松構(gòu)建千萬級IM和Feed流系統(tǒng)》。

?

Timeline是在去年新推出的一個數(shù)據(jù)模型，我們還在不斷的打磨。基于這個模型，我們已經(jīng)幫助釘釘、菜鳥智能客服、淘票票小聚場、智能設(shè)備管理等業(yè)務(wù)構(gòu)建即時通訊、Feeds流、物聯(lián)網(wǎng)等領(lǐng)域的消息系統(tǒng)，歡迎使用。

?

最后，歡迎加入我們的內(nèi)部釘釘群（群號：11789671）進行交流。

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。