為什么我們要使用 Azure 表存儲(chǔ)服務(wù)

Azure表存儲(chǔ)服務(wù)（Azure Table Storage）屬于微軟存儲(chǔ)服務(wù)Azure Storage的重要部分，作為云中存儲(chǔ)非關(guān)系結(jié)構(gòu)化數(shù)據(jù)（也稱為結(jié)構(gòu)化NoSQL數(shù)據(jù)）的服務(wù)，可以通過無架構(gòu)設(shè)計(jì)提供鍵/屬性存儲(chǔ)。因?yàn)楸泶鎯?chǔ)無架構(gòu)，因此可以很容易地隨著應(yīng)用程序需求的發(fā)展使數(shù)據(jù)適應(yīng)存儲(chǔ)。對(duì)于許多類型的應(yīng)用程序來說，訪問表存儲(chǔ)數(shù)據(jù)速度快且經(jīng)濟(jì)高效，因此在數(shù)據(jù)量相似的情況下，其成本通常比傳統(tǒng)SQL要低。個(gè)人早在2013年便開始關(guān)注并使用此服務(wù)。Azure表存儲(chǔ)服務(wù)可以算是微軟Azure上最早的NoSQL服務(wù)之一。

Azure表存儲(chǔ)的適用場景

Azure表存儲(chǔ)的常見用途包括以下幾類：

存儲(chǔ)TB量級(jí)的結(jié)構(gòu)化數(shù)據(jù)，能夠?yàn)閃eb規(guī)模應(yīng)用程序提供服務(wù)

存儲(chǔ)無需復(fù)雜聯(lián)接、外鍵或存儲(chǔ)過程，并且可以對(duì)其進(jìn)行非規(guī)范化以實(shí)現(xiàn)快速訪問的數(shù)據(jù)集

使用聚集索引快速查詢數(shù)據(jù)

使用OData協(xié)議和LINQ查詢以及WCF數(shù)據(jù)服務(wù).NET庫訪問數(shù)據(jù)

從我們實(shí)際使用情況來看，對(duì)于Azure表存儲(chǔ)服務(wù)，我認(rèn)為有幾點(diǎn)比較重要：

在約定的設(shè)計(jì)模式下，Azure表存儲(chǔ)服務(wù)可以提供較高的性能

存儲(chǔ)成本低

不限制數(shù)據(jù)格式，任意字段隨便存

Azure表存儲(chǔ)的內(nèi)部結(jié)構(gòu)

接下來我們看看Azure表存儲(chǔ)服務(wù)的幾個(gè)層次：

首先，在一個(gè)Azure Storage下，可以新建多個(gè)表。

每個(gè)表按照規(guī)定會(huì)擁有至少3個(gè)字段：PartitionKey(分區(qū)鍵)/RowKey(行鍵)/Timestamp(時(shí)間戳，注意這里存的是UTC（時(shí)間)。

在上述三個(gè)字段之外，你也可以自定義任意自己的字段，需要注意一個(gè)實(shí)體最多1M大小的限制。如果第一行數(shù)據(jù)100個(gè)字段，第二行數(shù)據(jù)20個(gè)字段，這類數(shù)據(jù)形式，也支持用戶任意更改構(gòu)造。

Azure表存儲(chǔ)性能怎么樣？

Azure表存儲(chǔ)服務(wù)的性能最主要受表實(shí)際設(shè)計(jì)影響，其中最重要的就是如何設(shè)計(jì)PartitionKey和RowKey，因?yàn)門able Storage內(nèi)部有且僅有這2個(gè)索引。

關(guān)于在不同場景下表設(shè)計(jì)準(zhǔn)則與注意事項(xiàng)，我這里簡單的說一下：

PartitionKey分區(qū)鍵

相同PartitionKey內(nèi)部會(huì)存儲(chǔ)在一起，而不同的PartitionKey一般存儲(chǔ)在不同的地方(如果你分的太多，不同的key也可能在一起)。用常規(guī)關(guān)系型數(shù)據(jù)庫思維理解，這個(gè)其實(shí)是它分庫分表的依據(jù)。

RowKey行鍵

在同一個(gè)PartitionKey內(nèi)Rowkey必須是唯一，否則會(huì)報(bào)錯(cuò)，RowKey是按順序存儲(chǔ)(可以用于排序之類的需求)。同樣用常規(guī)關(guān)系型數(shù)據(jù)庫的思維理解，Rowkey就是主鍵(PrimmeryKey).

基于上述設(shè)計(jì)，Table Storage的性能會(huì)呈現(xiàn)出如下幾個(gè)情況(按照速度由快到慢排序)：

同時(shí)命中PartitionKey和RowKey的點(diǎn)查詢(都是where=模式)；

對(duì)PartitionKey進(jìn)行點(diǎn)查詢(where=)然后對(duì)RowKey進(jìn)行范圍查詢(where<>)；

對(duì)PartitionKey進(jìn)行點(diǎn)查詢(where=)然后對(duì)非RowKey的字段進(jìn)行任意查詢(任意where)；

不命中PartitionKey的查詢，將觸發(fā)表掃描，效率將會(huì)相當(dāng)?shù)停?/em>

總結(jié)來看，沒命中Partitionkey的任意查詢都會(huì)很慢，RowKey可用于輔助加速。

不過需要注意的是:PartitionKey是控制分區(qū)用的，如果一個(gè)分區(qū)里的數(shù)據(jù)太多了，也會(huì)和傳統(tǒng)數(shù)據(jù)庫那樣變得比較慢，所以要控制下不要出現(xiàn)熱分區(qū)。

Azure表存儲(chǔ)服務(wù)貴嗎?

前面提到過，Table Storage的存儲(chǔ)成本非常低，那么有多低呢，我們來看看由世紀(jì)互聯(lián)運(yùn)營的Microsoft Azure官方定價(jià)：

在本地冗余存儲(chǔ)的情況下，4毛5不到一個(gè)GB！竟然還是類似NoSQL數(shù)據(jù)庫那樣子的服務(wù)！

我們之前也有比對(duì)過其他云廠商的類似服務(wù)，NoSQL類型的數(shù)據(jù)庫基本都是Mongo DB這種級(jí)別，存儲(chǔ)成本基本需要幾塊錢一個(gè)G，而且可能還需要額外的計(jì)算資源成本。

當(dāng)然關(guān)于價(jià)格，有童鞋可能會(huì)指出來：還有個(gè)操作(寫入/讀取等)的成本呀。但是，0.02元1萬次，這是什么概念？

假設(shè)你一條數(shù)據(jù)1KB，你塞滿1G那應(yīng)該是要1024*1024=1,048,576，然后除以10,000后再乘以0.02，也就是說成本只需要2塊錢人民幣！

另外，Azure是入站流量不收費(fèi)，所以沒有額外的網(wǎng)絡(luò)費(fèi)用，上述成本就是公司使用這個(gè)服務(wù)要掏的所有成本。

Azure表存儲(chǔ)服務(wù)能干什么?

一直以來，我自己腦子里都是一種NoSQL的思想。我的NoSQL的意思是Not Only SQL。誠然傳統(tǒng)關(guān)系型數(shù)據(jù)庫，其實(shí)真的是一個(gè)銀彈，只要是”存東西”的活兒，它基本都能干。

但是這類服務(wù)也有局限性，比如隨著如今數(shù)據(jù)量的暴漲，在大數(shù)據(jù)(僅指數(shù)據(jù)量特別大)情況下傳統(tǒng)關(guān)系型數(shù)據(jù)庫真的有點(diǎn)力不從心。

所以我觀點(diǎn)是:

專業(yè)的場景找專業(yè)的解決方案，使用最適合的存儲(chǔ)技術(shù)。

Azure表存儲(chǔ)服務(wù)結(jié)合下它幾個(gè)特點(diǎn):

限定PartitionKey(潛在RowKey輔助加速)下有比較好性能；

成本低；

第一個(gè)應(yīng)用場景是:記錄參數(shù)日志

參數(shù)日志數(shù)據(jù)的特點(diǎn)是:量大，每條日志的價(jià)值點(diǎn)較低，而且絕大多數(shù)數(shù)據(jù)都不會(huì)被查詢，但是企業(yè)有希望數(shù)據(jù)保存完整，真要用的時(shí)候數(shù)據(jù)不能丟。

以前我們參數(shù)日志記錄到數(shù)據(jù)庫里，由于量過大，基本都是三周一清。于是就會(huì)出現(xiàn)：如果有一個(gè)問題活到三周以外的話，對(duì)我們很大概率就是個(gè)頭疼的問題：核心日志缺失，排查難度+++。

不過，自從我們2020年開始將參數(shù)日志遷移到Azure表存儲(chǔ)服務(wù)后，媽媽再也不用擔(dān)心我的數(shù)據(jù)量問題拉。（日志部分，后續(xù)我們有機(jī)會(huì)再給大家詳細(xì)介紹下，如何基于表存儲(chǔ)服務(wù)解決我們?nèi)罩締栴}的設(shè)計(jì)體系。）

第二個(gè)場景是：用來存儲(chǔ)類似GPS之類的軌跡數(shù)據(jù)

GPS的設(shè)備ID作為PartitionKey，然后時(shí)間是RowKey，那么我要查這個(gè)GPS信息時(shí)候大概率可以通過“對(duì)PartitionKey進(jìn)行點(diǎn)查詢(where=)然后對(duì)RowKey進(jìn)行范圍查詢(where<>)”的模式進(jìn)行快速查找。

Azure表存儲(chǔ)服務(wù)怎么用？

我覺得作為一個(gè)軟系的程序員，每當(dāng)問到軟家產(chǎn)品怎么用的時(shí)候，我總是會(huì)說出:docs.microsoft.com。畢竟廠商文檔比絕大多數(shù)人寫的都更加的專業(yè)，在此我就不多作贅述。

傳送門：.Net SDK使用Table Storage

需要注意的是，微軟近期也有推出表存儲(chǔ)的替代服務(wù)：Azure Cosmos DB表AP。此API提供更高的性能和可用性、全局分發(fā)和自動(dòng)輔助索引。它還可用于基于使用量的無服務(wù)器模式。

這個(gè)服務(wù)是和Azure Storage里的Table是兼容的，兩者的關(guān)系官方上有對(duì)比。

使用Azure表存儲(chǔ)API和Azure Cosmos DB進(jìn)行開發(fā)

我簡單挑選了兩個(gè)重點(diǎn)區(qū)別說明下：

Cosmos DB價(jià)格比表存儲(chǔ)服務(wù)高，(每GB存儲(chǔ)成本約2元多RMB)，優(yōu)勢是性能更高更快，而且是全表索性，而Table只有PartitionKey和RowKey兩種索引方式。

如何選擇取決于實(shí)際場景需要，比如我前面說的日志是屬于量大但是每個(gè)數(shù)據(jù)的價(jià)值相對(duì)較低的，那么應(yīng)該用Table，但是如果數(shù)據(jù)價(jià)值較高且對(duì)性能敏感，那么建議選擇Azure Cosmos DB。

還是那句話:專業(yè)的地方找專業(yè)的解決方案，每個(gè)地方盡量用上最合適的存儲(chǔ)技術(shù)。

Azure存儲(chǔ)服務(wù)實(shí)際部署情況

我們實(shí)際業(yè)務(wù)使用Table Storage到現(xiàn)在大概半年左右時(shí)間，用量分了幾個(gè)存儲(chǔ)賬號(hào)最大的快200G。

然后以上述截圖第三行131G的那個(gè)存儲(chǔ)賬號(hào)為例

我們在上面存了有123M，大概有1億2千萬條數(shù)據(jù)。需要說下，如果此時(shí)我們應(yīng)用的傳統(tǒng)數(shù)據(jù)庫，怕是早就崩潰了。

在目前的數(shù)據(jù)量下，Azure存儲(chǔ)服務(wù)對(duì)應(yīng)性能也是不錯(cuò)的。

Get類型請求是查，Post類型請求是寫入，我們目前用于做參數(shù)日志，所以是寫多查少

但是細(xì)心的人可能會(huì)發(fā)現(xiàn)，雖然絕大多數(shù)情況下效率還可以。

但是我們之前也說過，Azure表存儲(chǔ)服務(wù)在適合的場景可以提供不錯(cuò)的性能，但是不能保證所有情況，所以實(shí)際應(yīng)用過程，需要靈活調(diào)整，切換到更高階的Azure Cosmos DB服務(wù)，從而提供基于RU（request unit，請求單位）級(jí)別的性能保證。

今天的分享到這兒，大家有任何問題，可以在下方留言區(qū)一起交流探討，也可以點(diǎn)擊文末閱讀原文，訪問我的博客主頁。祝大家2021年新年快樂。