我正处于 Web 应用程序的典型社交网络类型的规划阶段。它将包含个人资料、消息、即时聊天、相册、群组、虚拟礼物等...
决定哪些数据应该存储在 SQL Azure 中以及哪些数据应该存储在 Table Storage 中的决定因素是什么？
在 Azure 之前，所有关系数据都将存储在 SQL 服务器中，然后使用数据对象的内存缓存和页面输出缓存来提高性能并减轻 SQL 服务器的负载。
Azure 表存储如何适应/改变这种方法？
【问题讨论】：
标签： sql azure database-design azure-storage
SQL Azure
在 SQL Azure 的积极方面 - 它可以免费访问（无需存储事务成本）并且易于使用（关系型、开发人员熟悉、可以建模而无需担心未来查询将如何工作等）。 )
不利的一面是，SQL Azure 不是超级可扩展的——即使有联邦，每个数据库或联邦成员仍然与其他数据库一起生活在一个多租户环境中，并且它们在同一台服务器上相互竞争磁盘、CPU、内存等
从定价的角度来看，在 SQL Azure 中存储数据比在 Azure 表存储中更昂贵，但访问它是免费的（调用 SQL Azure 数据库没有成本）
Azure 表存储 (ATS)
Azure 存储的优点 - 它具有超大规模的可扩展性，可以支持非常大的数据量。基本上，ATS 背后没有“关系大脑”，就像 SQL Server 背后有大脑一样。因此，您不受单一大脑的限制，您可以将所有相关活动委托给您自己的服务器/实例，您可以拥有任意数量的服务器/实例。这使您能够实现超大规模。
不利的一面是，ATS 更难使用，因为您必须对密钥（PartitionKey 和 RowKey）进行建模，尤其是在预测查询时。您甚至可能需要以多种方式复制数据，以便将来可以非常简化地访问该数据并适当地使用 PartitionKey/RowKey。
从定价的角度来看，ATS 存储数据非常便宜，但每次访问都会收费（每次交易都需要收费）。价格最近下降了 10 倍，但仍需要考虑，作为预算的一部分
建议
当您需要超大规模时使用 ATS。例如，如果您有一个像 Facebook 这样的社交网站，提供规模的最重要的地方就是新闻提要组件 - 因为该数据被频繁地访问并且需要非常快速。
使用 SQL Azure 进行分层数据存储，其中关系最为重要且数据访问频率不高。例如，您的用户的个人资料信息（电子邮件/地址/登录/首选项/等）。
【讨论】：
SO 更适用于特定的编程问题。首先在 SQL 中调整大小，看看要花多少钱。如果您有大量数据，Azure 表存储 (ATS) 会更便宜。 ATS 没有连接。具有大量数据的日志文件是 ATS 的候选者。
【讨论】：