Azure Table Storage(一) : 簡單介紹

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的.

仍是那句話: 專業的地方找專業的解決方案, 每一個地方儘可能用上最合適的存儲技術.