Windows Azure的表访问延迟分区键和行键的选择 [英] Windows Azure table access latency Partition keys and row keys selection
问题描述
我们已经有了一个Windows Azure的表存储系统回事，我们有一个白天的报告值，所以我们得到了以下的分区和行键情景各种实体类型：
We've got a windows azure table storage system going on where we have various entity types that report values during the day so we've got the following partition and row key scenario:
有大约4000 - 5000实体。有6个实体类型和类型都大致均匀地分布。所以各地800'ish每个
There are about 4000 - 5000 entities. There are 6 entity types and the types are roughly evenly distributed. so around 800'ish each.
ParitionKey：的EntityType-日期
ParitionKey: entityType-Date
行键：ENTITYID
Row key: entityId
每个行记录了该特定日的一个实体的值。这是目前JSON序列。
Each row records the values for an entity for that particular day. This is currently JSON serialized.
中的数据非常详细。
我们将定期想在过了一个月在这些分区中的值，或根据我们网站的用户想看看什么两个月回头。
We will periodically want to look back at the values in these partitions over a month or two months depending on what our website users want to look at.
我们遇到如果我们想查询一个实体数据的一个月，我们发现，我们必须通过ENTITYID查询31分区键中的一个问题。
We are having a problem in that if we want to query a month of data for one entity we find that we have to query 31 partition keys by entityId.
这是非常缓慢的开始，但结果被缓存在第一次调用后。
This is very slow initially but after the first call the result is cached.
不幸的是，网站的性质是将有不同数量的不同的查询，所以，它不可能将数据从高速缓存多受益。
Unfortunately the nature of the site is that there will be a varying number of different queries so it's unlikely the data will benefit much from caching.
我们可以明显使分区越大，即数据的可能了整整一个星期，扩大rowKeys到ENTITYID和日期。
We could obviously make the partitions bigger i.e. perhaps a whole week of data and expand the rowKeys to entityId and date.
还有什么其他的选择是开放给我，或者仅仅是Windows Azure的表遭受相当高延迟的情况？
What other options are open to me, or is simply the case that Windows Azure tables suffer fairly high latency?
推荐答案
一些选项包括：
-
请并行查询31
Make the 31 queries in parallel
请在分区键范围内的单个查询，也就是
Make a single query on a partition key range, that is
分区键> =的EntityType，起始日期和分区键＆LT; =的EntityType，结束日期和行键= ENTITYID
Partition key >= entityType-StartDate and Partition key <= entityType-EndDate and Row key = entityId.
这可能是取决于您的数据，该查询可能比当前的查询延迟少。
It is possible that depending on your data, this query may have less latency than your current query.
这篇关于Windows Azure的表访问延迟分区键和行键的选择的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
