我们所有的表实体'RowKey都有他们的种类 例如,在用户表中:
PK: yahoo.com
RK: U_user1 ----------- the kind is 'U' it means User
PK: yahoo.com
RK: U_user2
PK: yahoo.com
RK: U_user3
PK: Store1
RK: M_user4 ----------- the kind is 'M' it means Merchant
PK: Store1
RK: M_user5
PK: Store1
RK: M_user6
PK: Store2
RK: M_user7
如果我想在不确切知道PartitionKey的情况下搜索所有用户,我会这样做:
在Azure存储资源管理器中:
RowKey gt 'U_' and RowKey lt 'V_'
在Linq:
var list = from e in dao.Table()
where string.Compare(e.RowKey, "U_") > 0 && string.Compare(e.RowKey, "V_") < 0
select e;
现在我的问题是,如果记录变大,它还会很快吗?或者我应该将Kind放入PartitionKey?但这样做并不容易。
Less fast: querying on only RowKey. Doing this will give table storage no pointer on
which partition to search in, resulting in a query that possibly spans multiple partitions,
possibly multiple storage nodes as well. Wihtin a partition, searching on RowKey is still
pretty fast as it’s a unique index.
编辑
我刚做了一些测试:
PK: M_Sample
RK: GUID
500 records
并且
PK: Sample
RK: U_GUID
500 records
使用这些查询:
PartitionKey gt 'M_' and PartitionKey lt 'N_' --- 26 seconds
RowKey gt 'U_' and RowKey lt 'V_' ----- 36 seconds
它表明,我必须真正使用PartitionKey作为搜索键。
答案 0 :(得分:1)
现在我的问题是,如果记录变大,它还会很快吗?要么 我应该把Kind放在PartitionKey中吗?但这样做不会 很容易。
不,因为您的查询是全桌扫描。您必须在查询中包含PartitionKey
才能获得最快的效果。
不确定这是否会有所帮助,但在我们的项目中,我们采取了不同的方法。因此,如果我采用上面的示例,我们每个用户存储两条记录(换句话说,我们正在对数据进行非规范化):
根据我们查询用户的方式,我们选择以下两个标准之一。