Azure Table Storage是什麼:

Azure Table Storage是隸屬於微軟Azure Storage這個大服務下的一個子服務, 這個服務在Azure上算是老字號了, 個人大概在2013年的時候就已經用過了(那會還叫Windows Azure的年代).

也算是微軟Azure上最早的NoSql服務之一(那會NoSql也才開始興起).

Table Storage有大概如下幾個我認為比較重要的特點:

①在它約定的設計模式下可以提供(但不保證)較高的效能

②廉價的儲存

③NoSql, 任意欄位隨便存

Table Storage的內部結構:

其大概分為如下幾個層次:

首先是在你的一個Azure Storage下,可以新建多個表.

每個表按照規定會擁有至少3個欄位欄位:PartitionKey(分割槽鍵)/RowKey(行鍵)/Timestamp(時間戳,注意這個存的是Utc時間).

在上述三個欄位之外,你可以自定義任意自己的欄位(但是注意一個實體最多1M大小的限制), 而且可以我第一行資料100個欄位,第二行資料20個欄位,類似這樣結構可以自己任意改任意構造.

Table Storage的效能最主要受你自己的表是如何設計的影響

其中最重要的就是如何設計PartitionKey和RowKey, 因為Table Storage內部有且僅有這2個索引.

微軟有文章詳細闡述各種場景下如何設計 表設計準則

我這裡簡單的說一下:

PartitionKey是分割槽鍵

相同PartitionKey它內部會儲存在一起,而不同的PartitionKey則(理論上)儲存在不同的地方(如果你分的太多,不同的key有概率也是在一起).

用常規關係型資料庫的思維去理解的話,就是這個是它分庫分表的依據.

RowKey是行鍵

在同一個PartitionKey內Rowkey必須是唯一,否則會報錯,RowKey是按順序儲存(可以用於排序之類的需求).

用常規關係型資料庫的思維去理解的話,Rowkey就是主鍵(PrimmeryKey).

基於上述的設計,Table Storage的效能大概會呈現出如下幾個情況(按照速度由快到慢排序)

①同時命中PartitionKey和RowKey的點查詢(都是where =模式)

②對PartitionKey進行點查詢(where =)然後對RowKey進行範圍查詢(where <>)

③對PartitionKey進行點查詢(where =)然後對非RowKey的欄位進行任意查詢(任意where)

④不命中PartitionKey的查詢,將觸發表掃描,效率將會相當低

一句話總結: 沒命中Partitionkey的任意查詢都會很慢,RowKey可用於輔助加速.

Table Storage貴嗎?

前面說過,Table Storage的儲存是廉價的,有多廉價呢:

上述價格是Azure世紀互聯版(國內版)的價格.

在本地冗餘儲存的情況下, 4毛5不到一個GB.

4毛5啊, Azure上存東西的服務中比4毛5更低的也就blob那類存檔案的了.

但這玩意卻提供你一個類似nosql資料庫那樣子的服務(雖然有點兒約束).

隔壁家其他雲的, nosql型別的資料庫基本都是mongdb這種級別的, 但是儲存成本基本都是幾塊錢一個G, 而且一般還要額外的計算資源成本(多少核多少記憶體).

當然關於價格有人還會說還有個操作(寫入/讀取等)的成本, 但是0.02元1萬次, 這是什麼概念……

假設你一條資料1kb, 你塞滿1g那應該是要 1024 * 1024 = 1,048,576, 然後除以10000後再乘以 0.02, 也就是2塊錢左右.

另外Azure是入站流量不收費,所以沒有額外的網路有關的費用,上述成本將是你對這個服務要掏的所有成本.

Table Storage能幹什麼?

一直以來,我自己腦子裡都是一種NoSQL的思想.

我的NoSql的意思是  Not Only Sql

誠然傳統關係型資料庫,其實真的是一個銀彈, 只要是”存東西” 活兒它基本都能幹.

但是隨著時代發展, 雖然它能幹這個活, 但它乾的並不好.

比如最常見的就是隨著現代資料量的暴漲, 在大資料(僅指資料量多)的情況下傳統關係型資料庫真的有點力不從心.

所以我觀點是: 專業的地方找專業的解決方案, 每個地方儘量用上最合適的儲存技術.

而Table Storage結合下它幾個特點:

限定PartitionKey(潛在RowKey輔助加速)下能有較好效能.

廉價的儲存.

首先第一個場景就應用而生了: 記錄引數日誌

我們想下引數日誌的資料有什麼特點: 量大, 每條日誌的價值點很低, 絕大多數資料都不會被查詢, 但是真要用的時候又希望資料不能丟的完整都有.

之前我們引數日誌記錄到資料庫裡,由於量過大,基本都是三週一清.

於是乎如果有一個問題活到三週以外的話, 對我們很大概率就是個蛋疼的問題了(一個核心日誌缺失,排查難度+++).

而2020年我們開始將引數日誌且到Table之後, 媽媽再也不用擔心我的資料量問題拉.

關於這個日誌的事情, 後續會在第二篇章再寫一篇部落格出來詳細介紹下我們基於Table如何解決我們的的日誌問題的設計體系.

第二個場景還在構思中, 就是能否用來儲存類似GPS之類的軌跡資料

GPS的裝置Id作為PartitionKey, 然後時間是RowKey, 那麼我要查這個GPS資訊時候大概率可以通過 “對PartitionKey進行點查詢(where =)然後對RowKey進行範圍查詢(where <>)”的模式進行快速查詢.

Table Storage怎麼用:

我覺得作為一個軟系的程式設計師, 每當問到軟家產品怎麼用的時候,我總是會說出: docs.microsoft.com

別人寫的比絕大多數人寫的都更加的專業.

我就不贅述了.

傳送門: .Net SDK使用Table Storage 

另:

後面微軟出的CosmosDb裡也包含了一個Table Api

這個是和Azure Storage裡的Table是相容的, 兩者的關係官方上有對比.

使用 Azure 表儲存 API 和 Azure Cosmos DB 進行開發

我簡單挑幾個我認為重點的區別說下:

CosmosDB的更貴,(每GB儲存成本到2塊多了),但是能保證效能(也有更快的效能)而且不再像Table那樣只有PartitionKey和RowKey是索引, 它是全表索引.

反正就更隔壁家其他雲的mongdb之類的差不多了, 只是API用的是同一套而已.

怎麼選擇看自己場景, 比如我前面說的日誌是屬於量大但是每個資料的價值相對較低的, 那麼應該用Table, 但是如果你資料價值較高且對效能敏感的那麼應該要用CosmosDb的.

還是那句話: 專業的地方找專業的解決方案, 每個地方儘量用上最合適的儲存技