为什么我们要使用 Azure 表存储服务

小提示：您能找到这篇{为什么我们要使用 Azure 表存储服务}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的为什么我们要使用 Azure 表存储服务内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

Azure表存储服务（Azure Table Storage）属于微软存储服务Azure Storage的重要部分，作为云中存储非关系结构化数据（也称为结构化NoSQL数据）的服务，可以通过无架构设计提供键/属性存储。因为表存储无架构，因此可以很容易地随着应用程序需求的发展使数据适应存储。对于许多类型的应用程序来说，访问表存储数据速度快且经济高效，因此在数据量相似的情况下，其成本通常比传统SQL要低。个人早在2013年便开始关注并使用此服务。Azure表存储服务可以算是微软Azure上最早的NoSQL服务之一。

Azure表存储的适用场景

Azure表存储的常见用如何推广自己的软文途包括以下几类：

存储TB量级的结构化数据，能够为Web规模应用程序提供服务

存储无需复杂联接、外键或存储过程，并且可以对其进行非规范化以实现快速访问的数据集

使用聚集索引快速查询数据

使用OData协议和LINQ查询以及WCF数据服务.NET库访问数据

从我们实际使用情况来看，对于Azure表存储服务，我认为有几点比较重要：

在约定的设计模式下，Azure表存储服务可以提供较高的性能

存储成本低

不限制数据格式，任意字段随便存

Azure表存储的内部结构

接下来我们看看Azure表存储服务的几个层次：

首先，在一个Azure Storage下，可以新建多个表。

每个表按照规定会拥有至少3个字段：PartitionKey(分区键)/RowKey(行键)/Timestamp(时间戳，注意这里存的是UTC（时间)。

在上述三个字段之外，你也可以自定义任意自己的字段，需要注意一个实体最多1M大小的限制。如果第一行数据100个字段，第二行数据20个字段，这类数据形式，也支持用户任意更改构造。

Azure表存储性能怎么样？

Azure表存储服务的性能最主要受表实际设计影响，其中最重要的就是如何设计PartitionKey和RowKey，因为Table Storage内部有且仅有这2个索引。

关于在不同场景下表设计准则与注意事项，我这里简单的说一下：

PartitionKey分区键

相同PartitionKey内部会存储在一起，而不同的PartitionKey一般存储在不同的地方(如果你分的太多，不同的key也可能在一起)。用常规关系型数据库思维理解，这个其实是它分库分表的依据。

RowKey行键

在同一个PartitionKey内Rowkey必须是唯一，否则会报错，RowKey是按顺序存储(可以用于排序之类的需求)。同样用常规关系型数据库的思维理解，Rowkey就是主键(PrimmeryKey).

基于上述设计，Table Storage的性能会呈现出如下几个情况(按照速度由快到慢排序)：

同时命中PartitionKey和RowKey的点查询(都是wh小程序怎么使用ere=模式)；

对PartitionKey进行点查询(where=)然后对RowKey进行范围查询(where<>)；

对PartitionKey进行点查询(where=)然后对非RowKey的字段进行任意查询(任意where)；

不命中PartitionKey的查询，将触发表扫描，效率将会相当低；

总结来看，没命中Partitionkey的任意查询都会很慢，RowKey可用于辅助加速。

不过需要注意的是:PartitionKey是控制分区用的，如果一个分区里的数据太多了，也会和传统数据库那样变得比较慢，所以要控制下不要出现热分区。

Azure表存储服务贵吗?

前面提到过，Table Storage的存储成本非常低，那么有多低呢，我们来看看由世纪互联运营的Microsoft Azure官方定价：

在本地冗余存储的情况下，4毛5不到一个GB！竟然还是类似NoSQL数据库那样子的服务！

我们之前也有比对过其他云厂商的类似服务，NoSQL类型的数据库基本都是Mongo DB这种级别，存储成本基本需要几块钱一个G，而且可能还需要额外的计算资源成本。

当然关于价格，有童鞋可能会指出来：还有个操作(写入/读取等)的成本呀。但是，0.02元1万次，这是什么概念？

假设你一条数据1KB，你塞满1G那应该是要1024*1024=1,048,576，然后除以10,000后再乘以0.02，也就是说成本只需要2块钱人民币！

另外，Azure是入站流量不收费，所以没有额外的网络费用，上述成本就是公司使用这个服务要掏的所有成本。

Azure表存储服务能干什么?

一直以来，我自己脑子里都是一种NoSQL的思想。我的NoSQL的意思是Not Only SQL。诚然传统关系型数据库，其实真的是一个银弹，只要是”存东西”的活儿，它基本都能干。

但是这类服务也有局限性，比如随着如今数据量的暴涨，在大数据(仅指数据量特别大)情况下传统关系型数据库真的有点力不从心。

所以我观点是:

专业的场景找专业的解决方案，使用最适合的存储技术。

Azure表存储服务结合下它几个特点:

限定PartitionKey(潜在RowKey辅助加速)下有比较好性能；

成本低；

第一个应用场景是:记录参数日志

参数日志数据的特点是:量大，每条日志的价值点较低，而且绝大多数数据都不会被查询，但是企业有希望数据保存完整，真要用的时候数据不能丢。

以前我们参数日志记录到数据库里，由于营销推广公司量过大，基本都是三周一清。于是就会出现：如果有一个问题活到三周以外的话，对我们很大概率就是个头疼的问题：核心日志缺失，排查难度+++。

不过，自从我们2020年开始将参数日志迁移到Azure表存储服务后，妈妈再也不用担心我的数据量问题拉。（日志部分，后续我们有机会再给大家详细介绍下，如何基于表存储服务解决我们日志问题的设计体系。）

第二个场景是：用来存储类似GPS之类的轨迹数据

GPS的设备ID作为PartitionKey，然后时间是RowKey，那么我要查这个GPS信息时候大概率可以通过“对PartitionKey进行点查询(where=)然后对RowKey进行范围查询(where<>)”的模式进行快速查找。

Azure表存储服务怎么用？

我觉得作为一个软系的程序员，每当问到软家产品怎么用的时候，我总是会说出:docs.microsoft.com。毕竟厂商文档比绝大多数人写的都更加的专业，在此我就不多作赘述。

传送门：.Net SDK使用Table Storage

需要注意的是，微软近期也有推出表存储的替代服务：Azure Cosmos DB表AP。此API提供更高的性能和可用性、全局分发和自动辅助索引。它还可用于基于使用量的无服务器模式。

这个服务是和Azure Storage里的Table是兼容的，两者的关系官方上有对比。

使用Azure表存储API和Azure Cosmos DB进行开发

我简单挑选了两个重点区别说明下：

Cosmos DB价格比表存储服务高，(每GB存储成本约2元多RMB)，优势是性能更高更快，而且是全表索性，而Table只有PartitionKey和RowKey两种索引方式。

如何选择取决于实际场景需要，比如我前面说的日志是属于量大但是每个数据的价值相对较低的，那么应该用Table，但是如果数据价值较高且对性能敏感，那么建议选择Azure Cosmos DB。

还是那句话:专业的地方找专业的解决方案，每个地方尽量用上最合适的存储技术。

Azure存储服务实际部署情况

我们实际业务使用Table Storage到现在大概半年左右时间，用量分了几个存储账号最大的快200G。

然后以上述截图第三行131G的那个存储账号为例

我们在上面存了有123M，大概有1亿2千万条数据。需要说下，如果此时我们应用的传统数据库，怕是早就崩溃了。

在目前的数据量下，Azure存储服务对应性能也是不错的。

Get类型请求是查，Post类型请求是写入，我们目前用于做参数日志，所以是写多查少

但是细心的人可能会发现，虽然绝大多数情况下效率还可以。

但是我们之前也说过，Azure表存储服务在适合的场景可以提供不错的性能，但是不能保证所有情况，所以实际应用过程，需要灵活调整，切换到更高阶的Azure Cosmos DB服务，从而提供基于RU（request unit，请求单位）级别的性能保证。

今天的分享到这儿，大家有任何问题，可以在下方留言区一起交流探讨，也可以点击文末阅读原文，访问我的博客主页。祝大家2021年新年快乐。