天青，MVC的Web应用程序的架构 - 如何分割SQL Azure和Azure的表的存储之间的数据？ [英] Azure, MVC web app architecture - how to split data between SQL Azure and Azure Table Storage?

问题描述

我在一个Web应用程序的典型的社会网络类型的规划阶段。这将有配置文件，邮件，即时聊天，相册，群组，虚拟presents，等等...

I am in the planning phase of the typical social network type of a web application. It will have profiles, messages, instant chat, albums, groups, virtual presents, etc...

什么是确定哪些数据应存储在SQL Azure和哪些数据应被存储在表存储器中的决定性因素？

What are the deciding factors that determine what data should be stored in the SQL Azure and what data should be stored in the Table Storage?

在Azure的所有关系数据将被存储在SQL服务器，然后使用数据对象和页面输出缓存的内存缓存将用于性能和缓解SQL服务器的负载。

Before the Azure all relational data would be stored in the SQL server and then memory caching with data objects and pages output caching would be used for performance and to ease the SQL server load.

如何天青表的存储在/适应改变了这种做法？

How does Azure Table Storage fits in/changes this approach?

非常感谢！

推荐答案

SQL Azure的

在SQL Azure中的积极的一面 - 它是免费的访问（用于存储交易没有成本），并易于使用（关系，熟悉的开发者，可以不用担心的查询将如何今后的工作中建模等。 ）

In the positive side of SQL Azure - it is free to access (no cost for storage transactions) and is easy to work with (relational, familiar to developers, can be modeled without worrying about how future queries will work, etc.)

在消极方面，SQL Azure是不是超级可扩展性 - 即使联合会，每个数据库或联盟成员仍然生活在一个多租户环境中与其他数据库和他们相互磁盘，CPU在同一台服务器上的竞争， RAM等。

On the negative side, SQL Azure is not mega scalable - even with Federations, each database or federated member still lives in a multi-tenant environment with other databases and they compete with one another on the same server for disk, CPU, RAM, etc.

从定价的角度来看，它是更昂贵的存储在SQL Azure中的数据比Azure Table中存储，但访问它是免费的（通话作出SQL Azure数据库没有成本）

From pricing perspective, it is more expensive to store data in SQL Azure than in Azure Table Storage, but accessing it is free (no cost for calls made SQL Azure database)

的Azure表的存储（ATS）

在积极Azure存储 - 这是大型可扩展性，可以支持非常大的数据量。基本上，没有关系脑的背后ATS像有SQL服务器后面的大脑。正因为如此，你不是有一个单一的大脑的限制的约束，你所有的委托关系活动，以自己的服务器/实例，其中你可以有你想要的。这给了你能力的大型规模。

On the positive of Azure Storage - it is mega-scalable and can support very large data amounts. Basically, there is no "relational brain" behind ATS like there is a brain behind SQL Server. Because of this, you're not bound by the limitations of having a single brain and you delegate all the relational activities to your own servers/instances of which you can have as many as you want. This gives you ability to mega scale.

在消极方面，ATS是很难一起工作，因为你必须非常尤其是在查询的预期钥匙（PartitionKey和RowKey）模型。你甚至可能需要重复多种方式的数据，以便将来数据访问可以是非常精简，适当地使用PartitionKey / RowKey。

On the negative side, ATS is harder to work with, because you have to model your Keys (PartitionKey and RowKey) very particularly in anticipation of your queries. You might even need to duplicate data in multiple ways so that future access to that data can be very streamlined and use PartitionKey/RowKey appropriately.

从定价的角度来看，ATS是便宜到存储数据，但收费每次访问它（有每笔交易费）的时间。价格最近由10倍下降，但仍需要考虑，您的预算的一部分

From pricing perspective, ATS is dirt cheap to store data, but charges for every time you access it (there is a fee per transaction). Price was recently dropped by 10x but still needs to be considered, as a part of your budget

建议

使用ATS当你需要大型的规模。例如，如果你有一个社交网站，如Facebook，最重要的地方，提供规模将与新闻饲料成分 - 如数据被频繁访问大型和需要是非常快的。

Use ATS when you need mega scale. For example, if you have a social site like Facebook, the most important place to provide scale would be with the News Feed component - as that data is accessed mega frequently and needs to be very quick.

使用SQL Azure的分层数据存储，其中的关系是最重要的数据是不是超级频繁访问。例如，你的用户（电子邮件/地址/登录/ preferences /等）的配置文件信息

use SQL Azure for hierarchical data storage where relationships are most important and that data is not super-frequently accessed. For example, profile information of your users (email/address/login/preferences/etc).

这篇关于天青，MVC的Web应用程序的架构 - 如何分割SQL Azure和Azure的表的存储之间的数据？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！