我想尝试使用Azure表存储作为Azure SQL的替代品。我们的应用程序通常写得很重（想想事件注册），而SQL长期以来一直是性能瓶颈。
但是，典型条目可能对多组列具有重复限制。例如，新条目不能包含重复的电子邮件地址，但也可能没有重复的邮寄地址。我不能使用组合键，因为必须分别检查每个重复项。在SQL中，我通常在电子邮件地址上创建唯一索引，然后在物理地址列上创建另一个唯一索引。从数据完整性的角度来看，这符合我的目的，但同样，性能也是问题。
如果我使用Azure存储，我可能会使用事件ID +每小时时间戳（UTC）作为分区键，以及每个用户的分区键的唯一ID，例如：
Partition Key Row Key <columns...>
event101_201402130500 <user's unique ID> <user data...>
我想在分区键中包含每小时时间戳，以便稍后更轻松地进行汇总报告。每小时我都可以使用批处理作业来请求前一个小时的分区键的所有实体，并执行必要的聚合，将结果存储在另一个表中以进行进一步的聚合和报告。
但是如何防止其他列上的重复？我想过使用用户的电子邮件+邮件地址的哈希值，但是，如果其中任何一个更改，则不会强制执行每个单独部分的唯一性，因为哈希值是唯一的。
我考虑过使用单独的表来跟踪每列的重复项，例如：
Partition Key Row Key User Key
event101 email_<user's email> <user's unique ID>
event101 addr_<hash of NACSZ> <user's unique ID>
我会在单个批处理事务中插入重复的实体，如果事务失败（因为重复的PK / RK），我只是避免插入用户行。只要批次<100实体且<4MB（根据ATS文档）
，这应该有效。总的来说，这似乎可以解决问题，但鉴于我缺乏以这种方式存储表存储的经验，我想确保我不会忽视某些内容或过度思考解决方案。
所以我的实际问题是：ATS真的很简单，我的解决方案是否合适，或者我应该考虑其他（我还不知道）选项吗？
答案 0 :(得分：1)
我建议你按照你的建议使用批量交易会做一些稍微不同的事情。我不确定您是否需要每个通风口的电子邮件和/或地址都是唯一的，但我已经这样做了。
我会有一个表，每次注册一个事件时会存储两个条目。一个用于电子邮件，另一个用于地址。你也已经考虑过了。
然后有一个单独的表来将实际的事件注册放入。 只有成功读取和写入第一个表以存储电子邮件和地址，然后才能将事件添加到事件表中。
我相信你可以把它放到一个交易中。