两个有些相关的问题。
1)无论如何得到表实体所依赖的服务器的ID? 2)使用GUID会给我最好的分区密钥分发吗?如果没有,会是什么?
我们一直在努力争取桌面存储性能。简而言之,它确实很糟糕,但在早期我们意识到使用随机分区键会将实体分布在许多服务器上,这正是我们想要做的事情,因为我们试图实现每秒8000次读取。显然我们的分区键不够随机,所以出于测试目的,我决定只使用GUID。第一印象是waaaaaay更快。
真的很糟糕获得性能<每秒1000。分区键是Guid.NewGuid(),行键是常量“UserInfo”。使用TableOperation和pk以及rk执行get,其他内容如下:TableOperation retrieveOperation = TableOperation.Retrieve(pk,rk); return cloudTable.ExecuteAsync(retrieveOperation)。我们总是使用索引读取而不是表扫描。此外,VM大小中等或大,从不小。并行号,异步是
答案 0 :(得分:9)
正如其他用户所指出的,Azure表由运行时严格控制,因此您无法控制/检查哪些特定存储节点正在处理您的请求。此外,任何给定的分区都由单个服务器提供,也就是说,属于同一分区的实体不能在多个存储节点之间拆分(参见HERE)
在Windows Azure表中,PartitionKey属性用作分区键。具有相同PartitionKey值的所有实体都聚集在一起,并且它们从单个服务器节点提供。这允许用户通过设置PartitionKey值来控制实体位置,并对同一分区中的实体执行实体组事务。
您提到您每秒定位8000个请求?如果是这种情况,您可能会达到需要非常好的表/分区键设计的阈值。请参阅文章“Windows Azure Storage Abstractions and their Scalability Targets”
以下摘录适用于您的情况:
这将为2012年6月7日之后创建的单个存储帐户提供以下可扩展性目标。
正如其他用户所指出的,如果您的PartitionKey编号遵循增量模式,Azure运行时将识别出这一点,并将您的某些分区分组到同一存储节点中。
此外,如果我正确理解您的问题,您当前正在通过GUID分配分区键?如果是这种情况,这意味着表中的每个PartitionKey都是唯一的,因此每个partitionkey将只有不超过1个实体。根据上面的文章,Azure表扩展的方式是通过在独立存储节点内的分区键中对实体进行分组。如果您的分区键是唯一的,因此只包含一个实体,这意味着Azure表一次只能扩展一个实体!现在,我们知道Azure不是那么愚蠢,它在分区密钥检测到模式的方式时对它们进行分组。因此,如果您在Azure中使用此触发器并且Azure正在对您的分区键进行分组,则意味着您的可伸缩性功能仅限于此分组算法的智能性。
根据2012年的可扩展性目标,每个分区密钥应该能够每秒为您提供2,000个事务。从理论上讲,在这种情况下,您应该需要不超过4个分区键(假设四个之间的工作负载均匀分配)。
我建议您设计分区键,以便每个分区每秒不超过2,000个实体,并使用GUID作为分区键删除。这将使您能够更好地支持实体事务组等功能,降低表设计的复杂性,并获得您正在寻找的性能。
答案 1 :(得分:0)
回答#1:特定的表实体不存在服务器的概念。没有特定的服务器可供选择,因为Table Storage是一个大规模的多租户存储系统。所以......没有办法检索给定表实体的服务器ID。
回答#2:选择对您的应用程序有意义的分区键。只记得它是访问给定实体的分区+行。如果你这样做,你将有一个快速,直接的阅读。如果您尝试进行表格或分区扫描,您的表现肯定会受到影响。
答案 2 :(得分:0)
请参阅 http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx了解关键选择的更多信息(注意数字是3年,但指导仍然很好)。
就最佳做法而言,这次谈话也有一些用处:http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B406#fbid=lCN9J5QiTDF。
通常,给定分区最多可支持2000 tps,因此跨分区传播数据有助于实现更大的数量。需要考虑的是原子批处理事务仅适用于共享相同分区键的实体。此外,对于较小的请求,您可以考虑禁用Nagle,因为小的请求可能会在客户端层被阻止。
从客户端,我建议使用最新的客户端lib(2.1)和Async方法,因为每秒有数千个请求。 (谈话中有一些关于客户最佳实践的幻灯片)
最后,下一个版本的存储将支持JSON和JSON没有元数据,这将显着减少相同对象的响应主体的大小,并随后解析它们所需的cpu周期。如果您使用最新的客户端库,您的应用程序将能够利用这些行为,几乎没有代码更改。