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可用於輔助加速.
另: PartitionKey是控制分區用的,如果一個分區里的數據太多了,也會和傳統數據庫那樣變得比較慢,所以要控制下不要出現熱分區
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
別人寫的比絕大多數人寫的都更加的專業.
我就不贅述了.
另:
后面微軟出的CosmosDb里也包含了一個Table Api
這個是和Azure Storage里的Table是兼容的, 兩者的關系官方上有對比.
使用 Azure 表存儲 API 和 Azure Cosmos DB 進行開發
我簡單挑幾個我認為重點的區別說下:
CosmosDB的更貴,(每GB存儲成本到2塊多了),但是能保證性能(也有更快的性能)而且不再像Table那樣只有PartitionKey和RowKey是索引, 它是全表索引.
反正就更隔壁家其他雲的mongdb之類的差不多了, 只是API用的是同一套而已.
怎么選擇看自己場景, 比如我前面說的日志是屬於量大但是每個數據的價值相對較低的, 那么應該用Table, 但是如果你數據價值較高且對性能敏感的那么應該要用CosmosDb的.
還是那句話: 專業的地方找專業的解決方案, 每個地方盡量用上最合適的存儲技術.
我們的使用情況
我們使用Table到現在大概半年左右，用量分了幾個存儲賬號最大的快200G
然后以上述截圖第三行131G的那個存儲賬號為例
我們在上面存了有123M（1億2千萬）條數據了（如果是傳統數據庫早死透了）
在此前提下，對應的性能也是可以的
Get類型請求是查，Post類型請求是寫入，我們目前用於做參數日志，所以是寫多查少
但是細心的人可能會發現，雖然絕大多數情況下效率還可以。
但是並不穩定，之前說過，table是提供較好的性能但是不保證性能，因為它是依托在Azure Storage存儲服務上
本身是不提供性能保證的，如果需要性能保證則需要用到更高階的CosmosDb了，那邊可以提供基於RU（request unit，請求單位）級別的性能保證