Partager via


Windows Azure Storage性能调优(二)

上一篇我们提出的方法都是通过减少网络传输时间来提升性能。接下来,我会简介一下WAS的系统结构,然后解释如何设计程序来减少WAS端执行时间。 

 

WAS架构

Windows Azure Storage是一个三层架构,分为前端(FE)、分区层(Partition)、分布式存储层(DFS)。

前端负责接受客户端HTTP(S)连接,验证身份,计费以及写日志。

分布式存储层为实际的物理存储。无论Blob,File,Queue还是Table,其最终都已Binary形式存放在此层。此层确保数据在三个独立的物理节点上保存备份,避免数据丢失。

分区层提供了逻辑数据结构的访问能力。它理解数据的逻辑抽象结构,能够按照用户的请求来正确存取DFS层数据。同时,分区层实现了跨数据中心的备份同步功能。

 

WAS的设计目标是存储海量数据,实现大并发访问。海量存储由分布式存储层来实现,而大并发的目标是如何实现的呢?

从物理存储来看,大并发的压力来自于磁盘I/O和网络带宽。在DFS层,数据的物理存储单位是Extent,100MB-1GB不等。每个对象(Blob,Table或Queue)都由一个或多个Extent拼接而,除此之外,数据还有三个备份。这些Extent离散分布在多台独立的服务器上,因此,用户对对象的访问被分摊在多台服务器上,以达到高吞吐量。

数据逻辑结构的处理需要耗费Memory和CPU资源。Partition层将逻辑数据拆分为多个Partitions,比如:每个Blob, Queue即为一个Partition,Table中PartitionKey相同的所有实体存放在一个Partition。Partition层每台服务器负责服务一组Partitions,Master服务器会检测每台服务器的负载,并动态调整Partitions的分配。由于所有数据都存放在DFS层,因此负载调整会非常迅速。通过动态负载均衡,Partition层确保有足够的资源来响应客户请求。

 

WAS性能目标

微软在MSDN上公布了WAS的性能目标,这些数据是WAS的性能上限,若用户使用WAS超过指标时,WAS会返回给客户503(Server Busy)或500(Operation Timeout)。当用户接到此类错误时,建议用户采用回退的方式重试操作,这样可以缓解短暂高峰造成的WAS服务压力。

简要来说,性能目标有两层:Partition级和Storage Account级。Storage Account级的目标如下:

Total Account Capacity

Total Request Rate (assuming 1KB object size)

Total Bandwidth for a Geo-Redundant Storage Account

Total Bandwidth for a Locally Redundant Storage Account

500 TB

Up to 20,000 entities or messages per second

*Ingress: Up to 10 gigabits per second

*Egress: Up to 20 gigabits per second

*Ingress: Up to 20 gigabits per second

*Egress: Up to 30 gigabits per second

* Ingress refers to all data (requests) being sent to a storage account.

* Egress refers to all data (responses) being received from a storage account.

Partition级别的性能目标为:

Target Throughput for Single Blob

Target Throughput for Single Queue (1 KB messages)

Target Throughput for Single Table Partition (1 KB entities)

Up to 60 MB per second, or up to 500 requests per second

Up to 2000 messages per second

Up to 2000 entities per second

若要了解更多细节,可以访问如下官方文档

https://msdn.microsoft.com/en-us/library/azure/dn249410.aspx

 

分散工作负载

了解到WAS的性能目标后,开发者在设计时就要尽量避免达到性能上限。

举个实例。两个Role通过WAS Queue来做消息中转,消息吞吐量在高峰时段可能达到10K,那么如果设计人员只使用单Queue,则Queue会成为性能瓶颈,无论增加多少Role虚拟机数量,吞吐量被始终限制在2000 messages/sec左右。解决方案就是使用多个Queue来分散工作负载。

 

同样的道理,用户要避免使用一个WAS Account来放置过多的虚拟机磁盘,否则有可能达到WAS Account级的性能上限20,000事务/s。建议每个WAS Account最多放置40块虚拟机磁盘。

 

避免Table热区

前面提到过,一个Table中PartitionKey相同的实体放置在同一个Partition里,而Partition的性能上限是2000实体访问/s。如果应用程序设计不当的话,有可能出现Table的某些Partition访问过于频繁,造成WAS响应慢或者报错(500,503)。举个具体的例子:一个日志系统,使用日期做PartitionKey,那么所有的写操作都会hit当日的Partition。如下通过测试,给大家一个直观的感觉。

场景: 一个博客系统,使用WAS Table来存储博客内容。现有两种设计:

设计1 PartitionKey=date, RowKey=BlogThreadID+PostID

代码如下:

 

设计2 PartitionKey=date+BlogThreadID, RowKey=PostID

代码和设计1类似,唯独修改了PartitionKey

 

两种设计保存的数据内容是一致的,只是PartitionKey和RowKey的格式不同。最终执行效率能有多大区别呢?我这里使用压力测试来检验,结果差别巨大!

设计1,随着用户负载增加,服务延迟越来越高,吞吐量维持在1380/s

 

设计2,随着用户负载增加,服务延迟平稳,而吞吐量达到了2600/s

可见,开发者在设计PartitionKey,RowKey时要避免Hot Partition,否则其造成的性能差距是巨大的。

设计2仍然存在问题:Partition按照PartitionKey字符串排序,编号相近的Partition很有可能被分配在同一台Partition服务器。设计2可能造成Partition服务器压力过载,从而影响WAS响应速度。为了提高性能,用户可以考虑倒置日期字符串来避免Partition集中。

 

优化Table查询

Table的实体有多个属性,通过筛选属性值,可以返回需要的实体。筛选条件的选择会直接影响查询效率。

数据库用户都知道索引能够避免扫描操作,减少I/O,从而提升效率。Table也支持索引,不过每个Table只有一个索引,即PartitionKey+RowKey。指定了PartitionKey和RowKey的查询叫做Point Query,他的查询效率也最高。

如果没有指定PartitionKey和RowKey,而是单单筛选其它属性,则查询退化为全表的扫描操作,效率会大大降低。不仅如此,之前WAS架构提到过,Table数据保存在多个Partition中,而Partitions分布在多台Partition服务器上。如果遍历的数据散布在多台服务器,则WAS会在遍历完一台Partition服务器后返回客户端一个Token,客户端凭Token来再次请求,WAS会将请求导向到下一个服务器,多次Roundtrip过程会耗费更多时间。

 

以访问WAD Table为例,我测试了用全表查询,局部范围查询,指定Partition查询和Point查询来搜索同一个实体。

 

结果表明PartitionKey 范围越小,查询速度就越快。

 

因此,用户的查询操作要尽量指定PartitionKey或者一个PartitionKey范围,避免大数据范围的扫描。而设计者需要根据业务需求考虑如何组合PartitionKey,使查询语句尽量多的使用到PartitionKey。

Table Storage 设计模式

最近微软公布了一份官方文档,列举了使用Azure Table Storage下的一些设计技巧,感兴趣的读者可以直接访问如下文档

https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/?rnd=1