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

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

Azure Table Storage(一) : 简单介绍的更多相关文章

  1. Azure Table storage 基本用法 -- Azure Storage 之 Table

    Azure Storage 是微软 Azure 云提供的云端存储解决方案,当前支持的存储类型有 Blob.Queue.File 和 Table,其中的 Table 就是本文的主角 Azure Tabl ...

  2. 自定义 Azure Table storage 查询过滤条件

    本文是在Azure Table storage 基本用法一文的基础上,介绍如何自定义 Azure Table storage 的查询过滤条件.如果您还不太清楚 Azure Table storage ...

  3. Azure Table storage 之改进DynamicTableEntity类为其添加动态语言扩展

    在之前的一篇文章中提到,storage类库中包含一个可以用来动态获取Azure table storage 表结构的类-DynamicTableEntity. 我们可以通过这个类,我们无需为每一个表提 ...

  4. Windows Azure Table storage 之 动态Table类 DynamicTableEntity

    在一般情况下,当我们在.net中使用Azure table storage的时候都会为该表建立一个TableEntity的派生类,如下所示. public class CustomerEntity : ...

  5. Windows Azure Table Storage 解决 Guid 查询问题

    在使用 Windows Azure Table Storage 的 CloudTableClient 对Azure 进行数据查询时,会发现在自定义类的Guid类型始终无法去成功查询出数据,对比发现 G ...

  6. 微软Azure 存储管理器的简单介绍

    Windows Azure存储用户经常希望能够在“管理器”中查看他们的数据,管理器指的是一款可用于显示存储帐户数据的工具.我们之前提供了我们所知的存储管理器列表.在本文中,我们将对此列表进行更新,使其 ...

  7. Azure 基础:Table storage

    Azure Storage 是微软 Azure 云提供的云端存储解决方案,当前支持的存储类型有 Blob.Queue.File 和 Table.其中的 Table 就是本文的主角 Azure Tabl ...

  8. Azure 基础:自定义 Table storage 查询条件

    本文是在 <Azure 基础:Table storage> 一文的基础上介绍如何自定义 Azure Table storage 的查询过滤条件.如果您还不太清楚 Azure Table s ...

  9. Azure Storage 系列(四)在.Net 上使用Table Storage

    一,引言 今天我们就不多说废话了,直接进入正题,Azure Table Storage.开始内容之前,我们先介绍一下Azure Table Storage. 1,什么是Azure Table Stor ...

随机推荐

  1. eclipse/myeclipse 使用技巧

    一.变量名自动补全 原理是:在输入变量名后,去掉按下空格或=后,代码上屏 以前只知道alt+/调出assist,后来发现可以所有字母都激活content assist(8.1里有写).用起来果然很爽, ...

  2. 史上最全单链表的增删改查反转等操作汇总以及5种排序算法(C语言)

    目录 1.准备工作 2.创建链表 3.打印链表 4.在元素后面插入元素 5.在元素前面增加元素 6.删除链表元素,要注意删除链表尾还是链表头 7.根据传入的数值查询链表 8.修改链表元素 9.求链表长 ...

  3. Consul的使用

    Consul的使用 ​ 生产部署中,Consul安装在要注册服务的每个节点上.Consul有两种运行模式:客户端和服务器端,每个Consul数据中心必须至少有一个服务器,负责维护Consul状态,为了 ...

  4. CMake将生成的可执行文件保存到其他目录

    在运行一些程序的时候,我们一般会把数据文件放在其他位置.而当在修改程序时,需要不断的修改代码,编译,执行.每次编译之后,都得将可执行文件复制到数据文件的目录. 这一问题有两种解决方法,一是直接在数据目 ...

  5. js 获取某月第一天和最后一天

    1.获取某月第一天和最后一天日期 function getDateByMonth (timeStamp) { let inDate = new Date(timeStamp) let year = i ...

  6. sqli-labs Less24 登录出现报错Cannot send session cache limiter....

    问题描述 这是一道二次注入题,注册完成后,应该登录然后修改密码,但是登录的时候出现: Warning: session_start(): Cannot send session cache limit ...

  7. 聊聊自学大数据flume中容易被人忽略的细节

    ​前言:老刘不敢保证说的有多好,但绝对是非常良心地讲述自学大数据开发路上的一些经历和感悟,保证会讲述一些不同于别人技术博客的细节. 01 自学flume的细节 老刘现在想写点有自己特色的东西,讲讲自学 ...

  8. 小白都能理解的Python多继承

    本文主要做科普用,在真实编程中不建议使用多重继承,或者少用多重继承,避免使代码难以理解. 方法解析顺序(MRO) 关于多重继承,比较重要的是它的方法解析顺序(可以理解为类的搜索顺序),即MRO.这个跟 ...

  9. NET 5 依赖注入多个服务实现类

    依赖注入在 ASP.NET Core 中起中很重要的作用,也是一种高大上的编程思想,它的总体原则就是:俺要啥,你就给俺送啥过来. 服务类型的实例转由容器自动管理,无需我们在代码中显式处理. 因此,有了 ...

  10. net core 3.1使用ElasticSearch 全文搜索引擎

    ElasticSearch 是一个开源的搜索引擎,建立在一个全文搜索引擎库 Apache Lucene 基础之上. Lucene 可以说是当下最先进.高性能.全功能的搜索引擎库,无论是开源还是私有. ...