我是否将Azure Table Storage或SQL Azure用于我们的CQRS读取系统？

Question

bounty到期在7天内。该问题的答案有资格获得+ 500声望赏金。l--''''''---------''''''''''''正在寻找来自信誉良好的来源的答案。

我们将在内部实现CQRS系统的读取部分，目标是极大地提高我们的读取性能。当前，我们的读取是通过Web服务进行的，该服务对规范化数据运行Linq-to-SQL查询，涉及从SQL Azure数据库进行一定程度的反序列化。

我们的数据的简化结构是：

• 用户
• 对话（向相同收件人的邮件分组）
• 消息
• 收件人（用户组）

我想将其移至非规范化状态，以便当用户请求查看消息源时，它会从EITHER中读取：

Azure表存储中保留的非规范化表示形式

• UserID作为PartitionKey
• ConversationID作为RowKey
• 易于存储为实体的任何易失数据发生变化
• 消息在实体中序列化为JSON
• 所述消息的收件人在实体中序列化为JSON
• 与此有关的主要问题是表存储中行的大小受限制（960KB）
• 此外，对“易失性数据”列的任何查询都将很慢，因为它们不是键的一部分

Azure表存储中的规范化表示形式

• 会话详细信息，消息和收件人的不同表
• 会话表上存储的邮件和收件人的分区键。
• 禁止；这遵循与上述相同的结构
• 解决最大行大小问题
• 但是规范化状态会降低非规范化表的性能增益吗？

OR

SQL Azure中保存的非规范化表示形式

• 作为复合主键保存的UserID和ConversationID
• 任何易于更改的易失性数据存储在单独的列中
• 消息在列中序列化为JSON
• [所述邮件的收件人在列中序列化为JSON
• 最大的索引和非规范化数据结构的灵活性
• 比表存储查询慢得多的性能

我想问的是，是否有人在表存储或SQL Azure上实现非规范化结构方面有任何经验，您会选择哪种？还是我错过了更好的方法？

我的直觉说，表存储中的归一化（至少在某种程度上）数据将是必经之路；但是，我担心进行3次查询以获取用户的所有数据会降低性能。

Answer 1

您考虑Azure表的主要驱动力是极大地提高读取性能，根据您在SQL Azure中持有的非规范化表示形式下的最后一点，在使用SQL Azure的情况下，“慢得多”。我个人出于某些原因感到非常惊讶，并希望就此主张的产生方式进行详细分析。我的默认立场是，在大多数情况下，SQL Azure会快得多。

以下是我对该声明表示怀疑的一些原因：

• SQL Azure使用本机/高效的TDS协议返回数据； Azure表使用JSON格式，这更加冗长]
• 只要您在SQL Azure中使用主键或具有索引，SQL Azure中的联接/筛选器将非常快； Azure表没有索引，必须在客户端执行联接
• Azure表返回的记录数限制（一次限制为1,000条记录，这意味着您需要实施多次往返以获取许多记录

尽管您可以通过创建其他包含自定义索引的表来伪造Azure表中的索引，但是您有责任维护该索引，如果不小心，它将降低您的操作速度并可能创建孤立方案。

最后但并非最不重要的一点是，当您试图降低存储成本（比SQL Azure便宜）并且需要的存储量超过SQL Azure所提供的容量时，使用Azure表通常是有意义的（尽管现在可以使用联合身份验证来打破单个数据库的最大存储限制）。例如，如果您需要存储10亿条客户记录，则使用Azure表可能很有意义。但是在我看来，仅使用Azure Tables来提高速度是相当可疑的。

[如果我不知所措，我会对此提出质疑，并确保您在员工方面拥有熟练的SQL开发技能，可以证明您在完全更改体系结构之前已达到SQL Server / SQL Azure固有的性能瓶颈。

此外，我将定义您的绩效目标。您是否正在将访问时间提高100倍？您是否考虑过缓存？您在数据库中使用索引正确吗？

我的2美分...：）