我们的数据简化结构如下：
>用户
>对话(将消息分组到同一收件人)
>消息
>收件人(用户集)
我想将其移动到非规范状态,以便当用户请求查看从EITHER读取的消息的源：
Azure表存储中存在非规范化表示
> UserID作为PartitionKey
> ConversationID作为RowKey
>任何容易变化的易失性数据存储为实体
>在实体中序列化为JSON的消息
>所述消息的收件人在一个实体中序列化为JSON
>这个主要问题是表存储中的一行有限(960KB)
>“volatile data”列中的任何查询都会很慢,因为它们不是密钥的一部分
Azure表存储中保存的归一化表示
>对话详细信息,消息和收件人的不同表
>存储在对话表中的消息和收件人的分区密钥.
>酒吧吧这遵循与上述相同的结构
>获取最大行大小问题
>但是归一化状态会降低非规格化表的性能提升吗？
要么
在sql Azure中持有的非规范化表示
> UserID&对话ID作为复合主键保存
>任何容易变化的易失性数据存储在单独的列中
>在列中序列化为JSON的消息
>所有邮件的收件人在列中序列化为JSON
>索引的最大灵活性和非规范化数据的结构
>性能比表存储查询慢得多
我问的是,有没有人有任何经验在Table Storage或sql Azure中实现非规范化的结构,你会选择哪一种？还是有更好的方法我错过了？
我的直觉说,表格存储中的数据的归一化(至少在一定程度上)将是要走的路;不过,我担心这样会降低性能提升,进行3次查询,以便获取用户的所有数据.
解决方法
以下是我对这项索赔的怀疑的一些原因：
> sql Azure使用本机/高效TDS协议返回数据; Azure表使用JSON格式,这是更详细的
>只要您在sql Azure中使用主键或具有索引,sql Azure中的连接/过滤器将非常快速; Azure表没有索引,连接必须在客户端执行
> Azure表返回的记录数限制(每次1,000条记录)意味着需要实施多次往返以获取许多记录
虽然您可以通过创建其他持有自定义索引的表来伪造Azure Tables中的索引,但您拥有维护该索引的职责,这将减缓您的操作,并且如果您不小心,可能会创建孤立方案.
最后但并非最不重要的是,当您尝试降低存储成本(比sql Azure更便宜)时,使用Azure表通常是有意义的,当您需要比sql Azure可以提供的更多存储空间(尽管现在可以使用联合中断单数据库最大存储限制).例如,如果您需要存储10亿个客户记录,则使用Azure Table可能有意义.但是,使用Azure表仅增加速度在我看来是相当可疑的.
如果我在你的鞋子,我会非常努力的质疑这个说法,并确保你有专家的sql开发技能的工作人员,可以演示您正在完成sql Server / sql Azure固有的性能瓶颈,完全改变您的架构.
此外,我将定义您的绩效目标.您是否正在浏览100倍的访问时间？你考虑过缓存吗？您在数据库中正确使用索引吗？
我的2美分…
