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可用于辅助加速.
另: 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，请求单位）级别的性能保证
