使用 Azure) 生成 Real-World 云应用的数据存储选项 (

作者 ：Rick Anderson， Tom Dykstra

下载修复项目 或 下载电子书

使用 Azure 构建真实世界云应用 电子书基于 Scott Guthrie 开发的演示文稿。 本文介绍了 13 种模式和做法，可帮助你成功开发适用于云的 Web 应用。 有关电子书的信息，请参阅 第一章。

大多数人习惯于关系数据库，在设计云应用时往往忽略其他数据存储选项。 结果可能是性能不理想、费用高或更糟，因为 NoSQL (非关系) 数据库可以比关系数据库更高效地处理某些任务。 当客户要求我们帮助解决关键的数据存储问题时，通常是因为他们有一个关系数据库，其中一个 NoSQL 选项会效果更好。 在这些情况下，如果客户在将应用部署到生产环境之前实现了 NoSQL 解决方案，情况会更好。

另一方面，假设 NoSQL 数据库可以很好地完成或足够多的操作也是错误的。 对于所有数据存储任务，没有一个最佳数据管理选择：不同的数据管理解决方案针对不同的任务进行优化。 大多数实际云应用都有各种数据存储要求，通常通过多个数据存储解决方案的组合来提供最佳服务。

本章的目的是让你更广泛地了解云应用可用的数据存储选项，以及有关如何选择适合你的方案的数据存储选项的一些基本指南。 在开发应用程序之前，最好了解可用的选项并考虑其优缺点。 更改生产应用中的数据存储选项可能非常困难，例如在飞机飞行时必须更改喷气式发动机。

Azure 上的数据存储选项

借助云，可以相对轻松地使用各种关系和 NoSQL 数据存储。 下面是可在 Azure 中使用的一些数据存储平台。

该表显示了四种类型的 NoSQL 数据库：

• 键/值数据库 为每个键值存储一个序列化对象。 它们适用于存储大量数据，其中你希望为每个给定键值获取一个项，并且不必对该项的其他属性进行查询。

  Azure Blob 存储 是一个键/值数据库，其功能类似于云中的文件存储，其键值对应于文件夹和文件名。 按文件的文件夹和文件名检索文件，而不是通过搜索文件内容中的值来检索文件。

  Azure 表存储 也是键/值数据库。 每个值称为类似于行的 实体 (，由分区键和行键) 标识，并且包含多个 属性 (类似于列，但表中并非所有实体都) 共享相同的列。 查询键以外的列效率极低，应避免。 例如，可以存储用户配置文件数据，其中一个分区存储有关单个用户的信息。 可以将用户名、密码哈希、出生日期等数据存储在一个实体的单独属性或同一分区中的单独实体中。 但你不希望查询具有给定出生日期范围的所有用户，也无法在个人资料表与另一个表之间执行联接查询。 表存储比关系数据库更具可缩放性且成本更低，但它不会启用复杂的查询或联接。

• Documentdatabases 是键/值数据库，其中的值是 文档。 此处的“文档”不用于Word或 Excel 文档，而是表示命名字段和值的集合，其中任何一个都可以是子文档。 例如，在订单历史记录表中，订单文档可能有订单编号、订单日期和客户字段;客户字段可能具有名称和地址字段。 数据库以 XML、YAML、JSON 或 BSON 等格式对字段数据进行编码;或者可以使用纯文本。 将文档数据库与键/值数据库分开的一项功能是能够查询非键字段并定义辅助索引，使查询更高效。 此功能使文档数据库更适合需要根据比文档键值更复杂的条件检索数据的应用程序。 例如，在销售订单历史记录文档数据库中，可以查询各种字段，例如产品 ID、客户 ID、客户名称等。 MongoDB 是一个常用的文档数据库。

• 列系列数据库 是键/值数据存储，可用于将数据存储构造为称为列系列的相关列的集合。 例如，人口普查数据库可能具有一组列来表示人员姓名 (第一个、中间、最后一个) ，一个组用于人员地址，一组用于该人的个人资料信息 (DOB、性别等) 。 然后，数据库可以将每个列系列存储在单独的分区中，同时保留与同一键相关的一个人的所有数据。 然后，你可以读取所有配置文件信息，而无需通读所有名称和地址信息。 Cassandra 是常用的列系列数据库。

• 图形数据库 将信息存储为对象和关系的集合。 图形数据库的用途是使应用程序能够有效地执行遍历对象网络及其之间的关系的查询。 例如，对象可能是人力资源数据库中的员工，你可能想要简化查询，例如“查找直接或间接为 Scott 工作的所有员工”。 Neo4j 是一种常用的图形数据库。

与关系数据库相比，NoSQL 选项为非结构化数据的存储和分析提供了更高的可伸缩性和成本效益。 折衷是它们不提供关系数据库的丰富可查询性和可靠的数据完整性功能。 NoSQL 适用于 IIS 日志数据，其中涉及大量数据，而无需联接查询。 NoSQL 不适用于银行交易，这需要绝对的数据完整性，并且涉及与其他帐户相关数据的许多关系。

还有一个名为 NewSQL 的较新的数据库平台类别，它将 NoSQL 数据库的可伸缩性与关系数据库的可查询性和事务完整性相结合。 NewSQL 数据库设计用于分布式存储和查询处理，这在“OldSQL”数据库中通常很难实现。 NuoDB 是可在 Azure 上使用的 NewSQL 数据库的一个示例。

Hadoop 和 MapReduce

可以存储在 NoSQL 数据库中的大量数据可能难以及时有效地分析。 为此，可以使用实现 MapReduce 功能的 Hadoop 等框架。 从本质上讲，MapReduce 进程的作用如下：

• 通过仅选择实际需要分析的数据，限制需要处理的数据的大小。 例如，你希望按出生年份了解用户群的构成，因此仅从用户配置文件数据存储中选择出生年份。
• 将数据分解为各个部分，并将其发送到不同的计算机进行处理。 计算机 A 计算 1950-1959 年日期、计算机 B 1960-1969 等日期的人数。这组计算机称为 Hadoop 群集。
• 完成对部件的处理后，将每个部件的结果重新放在一起。 现在，你有一个相对简短的列表，其中列出了每个出生年份的人数，并且计算此总体列表中的百分比的任务是可管理的。

在 Azure 上，HDInsight 使你能够利用 Hadoop 的强大功能处理、分析和从大数据中获取新见解。 例如，可以使用它来分析 Web 服务器日志：

• 启用到存储帐户的 Web 服务器日志记录。 这会将 Azure 设置为将每个 HTTP 请求的日志写入到 Blob 服务。。 Blob 服务基本上是云文件存储，并且与 HDInsight 很好地集成。

  

• 当应用获取流量时，Web 服务器 IIS 日志将写入 Blob 存储。

  

• 在门户中，单击“ 新建 - 数据服务 - HDInsight - 快速创建”，并指定 HDInsight 群集名称、群集大小 (HDInsight 群集数据节点数) ，以及 HDInsight 群集的用户名和密码。

  

现在可以设置 MapReduce 作业来分析日志并获取以下问题的答案：

• 我的应用在一天中的哪些时间获得最多或最少的流量？
• 我的流量来自哪些国家/地区？
• 我的交通来自地区的社区平均收入是多少。 (有一个按 IP 地址提供邻里收入的公共数据集，你可以根据 Web 服务器日志中的 IP 地址进行匹配。)
• 邻里收入如何与网站中的特定页面或产品相关联？

然后，你可以使用这些问题的答案根据客户对特定产品感兴趣或可能购买特定产品的可能性来定位广告。

如 自动化一切一章中所述，可以在门户中执行的大多数功能都是自动化的，包括设置和执行 HDInsight 分析作业。 典型的 HDInsight 脚本可能包含以下步骤：

• 预配 HDInsight 群集并将其链接到存储帐户，以便进行 Blob 存储输入。
• 将 mapReduce 作业可执行文件 (.jar 或 .exe 文件) 上传到 HDInsight 群集。
• 提交将输出数据存储到 Blob 存储的 MapReduce。
• 等待作业完成。
• 删除 HDInsight 群集。
• 访问 Blob 存储的输出。

通过运行执行所有这些操作的脚本，可以最大程度地减少预配 HDInsight 群集的时间量，从而最大程度地降低成本。

平台即服务 (PaaS) 与基础结构即服务 (IaaS)

前面列出的数据存储选项包括平台即服务 (PaaS) 和基础结构即服务 (IaaS) 解决方案。 PaaS 意味着我们管理硬件和软件基础结构，而你只需使用该服务。 SQL 数据库是 Azure 的一项 PaaS 功能。 你要求提供数据库，Azure 在后台设置和配置 VM，并在这些 VM 上设置数据库。 你没有对 VM 的直接访问权限，也不必对其进行管理。IaaS 意味着可以设置、配置和管理在数据中心基础结构中运行的 VM，并为其添加所需的任何内容。 我们为常见 VM 配置提供预配置的 VM 映像库。 例如，可以为 Windows Server 2008、Windows Server 2012、BizTalk Server、Oracle WebLogic Server、Oracle Database 等安装预配置的 VM 映像。

Azure 提供的 PaaS 数据解决方案包括：

• Azure SQL 数据库 (以前称为 SQL Azure) 。 基于SQL Server的云关系数据库。
• Azure 表存储。 键/值 NoSQL 数据库。
• Azure Blob 存储。 云中的文件存储。

对于 IaaS，可以运行可以加载到 VM 的任何内容，例如：

• 关系数据库，例如 SQL Server、Oracle、MySQL、SQL Compact、SQLite 或 Postgres。
• 键/值数据存储，例如 Memcached、Redis、Cassandra 和 Riak。
• 列数据存储，例如 HBase。
• 记录 MongoDB、RavenDB 和 CouchDB 等数据库。
• 图形数据库，如 Neo4j。

IaaS 选项提供几乎无限的数据存储选项，其中许多选项特别易于使用，因为可以使用预配置的映像创建 VM。 例如，在管理门户中转到虚拟机，单击“映像”选项卡，然后单击“浏览 VM 仓库”。

然后，会看到 数百个预配置的 VM 映像的列表，可以从预安装了数据库管理系统的映像（例如 MongoDB、Neo4J、Redis、Cassandra 或 CouchDB）创建 VM：

Azure 使 IaaS 数据存储选项尽可能易于使用，但 PaaS 产品/服务具有许多优势，使其在很多方案中更具成本效益和实用性：

• 无需创建 VM，只需使用门户或脚本来设置数据存储。 如果需要 200 TB 的数据存储，只需单击一个按钮或运行命令，即可在几秒钟内使用。
• 无需管理或修补服务使用的 VM;Microsoft 会自动为你完成该操作。你不必担心设置基础结构以实现缩放或高可用性;Microsoft 为你处理所有这一切。
• 无需购买许可证;服务费用中包括许可证费用。
• 只需为所用的部分付费。

Azure 中的 PaaS 数据存储选项包括第三方提供商提供的产品/服务。

选择数据存储选项

没有一种方法适合所有方案。 如果有人说这项技术是答案，首先要问的是“问题是什么？”，因为不同的解决方案针对不同的事物进行优化。 关系模型有一定的优势：这就是为什么它已经存在了这么久。 但是，SQL 也有一些下侧，可以通过 NoSQL 解决方案来解决。

通常，我们认为效果最好的是组合方法，即在单个解决方案中使用 SQL 和 NoSQL。 即使人们说他们正在接受 NoSQL，如果你深入了解他们正在做什么，你经常会发现他们使用的是几个不同的 NoSQL 框架：他们使用 CouchDB、 Redis 和 Riak 进行不同的操作。 即使是广泛使用 NoSQL 的 Facebook，也对服务的不同部分使用不同的 NoSQL 框架。 混合和匹配数据存储方法的灵活性是云的优点之一，因为可以轻松使用多个数据解决方案并将其集成到单个应用中。

下面是在选择方法时要考虑的一些问题：

数据语义	- 存储关系数据或非结构化数据) (，什么是核心数据存储和数据访问语义？ 非结构化数据（如媒体文件）最适合 Blob 存储;产品、库存、供应商、客户订单等相关数据的集合最适合关系数据库。
查询支持	- 查询数据有多容易？ - 可以有效地提出哪些类型的问题？ 键/值数据存储非常擅长获取给定键值的单个行，但不太适合复杂查询。 对于始终获取某个特定用户数据的用户配置文件数据存储，键/值数据存储可以正常工作;对于要根据各种产品属性获取不同分组的产品目录，关系数据库可能效果更好。 NoSQL 数据库可以有效地存储大量数据，但必须围绕应用查询数据的方式构建数据库，这使得临时查询更难执行。 使用关系数据库，几乎可以生成任何类型的查询。
功能投影	- 问题、聚合等是否可以在服务器端执行？ 如果我从 SQL 中的表运行 SELECT COUNT (*) ，它将非常高效地在服务器上完成所有工作，并返回我要查找的数字。 如果想要从不支持聚合的 NoSQL 数据存储进行相同的计算，则这是一个低效的“无限制查询”，可能会超时。即使查询成功，我必须从服务器检索到客户端的所有数据，并计算客户端上的行数。 - 可以使用哪些语言或类型的表达式？ 对于关系数据库，我可以使用 SQL。 对于某些 NoSQL 数据库（如 Azure 表存储），我将使用 OData，我所能做的就是筛选主键并获取投影 (选择可用字段的子集) 。
易于伸缩性	- 数据需要缩放的频率和缩放量是多少？ - 平台是否本机实现横向扩展？ - 添加/删除容量 (大小和吞吐量) 有多容易？ 关系数据库和表不会自动分区，使其可缩放，因此难以超出某些限制。 NoSQL 数据存储（如 Azure 表存储）固有地对所有内容进行分区，添加分区几乎没有限制。 可以轻松地将表存储扩展到 200 TB，但Azure SQL数据库的最大数据库大小为 500 GB。 可以通过将关系数据分区到多个数据库来缩放关系数据，但设置应用程序以支持该模型需要大量的编程工作。
检测和可管理性	- 平台检测、监视和管理的简单程度如何？ 你需要随时了解数据存储的运行状况和性能，因此需要提前了解平台免费提供的指标，以及需要自行开发的内容。
Operations	- 平台在 Azure 上部署和运行有多容易？ Paas？ Iaas？ Linux？ 表存储和SQL 数据库很容易在 Azure 上设置。 非内置 Azure PaaS 解决方案的平台需要付出更多努力。
API 支持	- 是否提供可用于轻松使用平台的 API？ 对于 Azure 表服务，有一个 SDK，其中包含支持 .NET 4.5 异步编程模型的 .NET API。 如果要编写 .NET 应用，与另一个没有 API 或不太全面的键/值列数据存储平台相比，为 Azure 表服务编写和测试代码要容易得多。
事务完整性和数据一致性	- 平台支持事务以确保数据一致性是否至关重要？ 为了跟踪发送的批量电子邮件，性能和低数据存储成本可能比自动支持数据平台中的事务或引用完整性更重要，因此 Azure 表服务是一个不错的选择。 对于跟踪银行账户余额或采购订单，更好的选择是提供强大事务保证的关系数据库平台。
业务连续性	- 备份、还原和灾难恢复的简单程度如何？ 生产数据迟早会损坏，你需要撤消函数。 关系数据库通常具有更精细的还原功能，例如还原到某个时间点的功能。 了解你考虑的每个平台中可用的还原功能是需要考虑的一个重要因素。
开销	- 如果多个平台可以支持数据工作负载，那么它们的成本比较如何？ 例如，如果使用 ASP.NET 标识，则可以将用户配置文件数据存储在 Azure 表服务或 Azure SQL 数据库中。 如果不需要SQL 数据库丰富的查询功能，则可以选择 Azure 表，部分原因是给定存储量的成本要低得多。

我们通常建议在选择数据存储解决方案之前，先了解每个类别中问题的答案。

此外，工作负载可能具有特定的要求，某些平台可以比其他平台更好地支持这些要求。 例如：

• 应用程序是否需要审核功能？
• 数据寿命要求是什么 - 是否需要自动存档或清除功能？
• 你有专门的安全需求吗？ 例如，数据包括 PII (个人身份信息) 但你必须能够确保从查询结果中排除 PII。
• 如果由于法规或技术原因，某些数据无法存储在云中，则可能需要一个有助于与本地存储集成的云数据存储平台。

演示 - 在 Azure 中使用 SQL 数据库

Fix It 应用使用关系数据库来存储任务。 自动化一章中显示的环境创建Windows PowerShell脚本创建两个SQL 数据库实例。 可以通过单击“ SQL 数据库 ”选项卡在门户中查看这些内容。

使用门户创建数据库也很容易。

单击“新建”-“数据服务 -- SQL 数据库 -- 快速创建”，输入数据库名称，选择帐户中已有的服务器或创建新服务器，然后单击“创建SQL 数据库。

等待几秒钟，Azure 中的数据库可供使用。

因此，Azure 可在几秒钟内完成本地环境中可能需要一天、一周或更长时间的时间。 而且，由于可以在脚本中或使用管理 API 轻松自动创建数据库，因此可以通过将数据分散到多个数据库来动态横向扩展，只要应用程序已为此进行了编程。

这是平台即服务模型的示例。 你不必管理服务器，我们来管理服务器。 你不必担心备份，我们这样做。 它在高可用性中运行 - 数据库中的数据会自动跨三个服务器复制。 如果计算机发生故障，我们会自动进行故障转移，不会丢失任何数据。 服务器会定期修补，你无需担心。

单击一个按钮，即可获得所需的确切连接字符串，并可以立即开始使用新数据库。

仪表板显示连接历史记录和使用的存储量。

可以在门户中或使用已熟悉SQL Server工具（包括SQL Server Management Studio (SSMS) 和 Visual Studio 工具SQL Server 对象资源管理器 (SSOX) 和服务器资源管理器）来管理数据库。

另一个好东西是定价模型。 可以使用免费的 20 MB 数据库开始开发，生产数据库每月的起价约为 5 美元。 只需为数据库中实际存储的数据量付费，而不是最大容量。 无需购买许可证。

SQL 数据库易于缩放。 对于 Fix It 应用，我们在自动化脚本中创建的数据库上限为 1 千兆。 如果要将其纵向扩展到 150 千兆，只需转到门户并更改该设置，或执行 REST API 命令，在几秒钟内即可获得一个可将数据部署到的 150 gig 数据库。

这就是云的强大功能，可快速轻松地建立基础结构并立即开始使用它。

Fix It 应用使用两个 SQL 数据库，一个用于成员身份 (身份验证和授权) ，一个用于数据，这就是预配和缩放它所要做的。 你之前已经了解了如何通过Windows PowerShell脚本预配数据库，现在还了解了在门户中执行操作的简单程度。

实体框架与使用 ADO.NET 的直接数据库访问

Fix It 应用使用实体框架（Microsoft 推荐的 ORM (适用于 .NET 应用程序的对象关系映射器) ）访问这些数据库。 ORM 是一个很好的工具，可提高开发人员的工作效率，但在某些情况下，工作效率会降低性能。 在实际云应用中，你不会在使用 EF 或直接使用 ADO.NET 之间进行选择， 你将同时使用这两者。 大多数情况下，在编写适用于数据库的代码时，获得最佳性能并不重要，你可以利用实体框架获得的简化编码和测试。 在 EF 开销会导致性能不可接受的情况下，可以使用 ADO.NET 编写和执行自己的查询，最好是通过调用存储过程。

无论使用哪种方法来访问数据库，都希望尽可能减少“闲聊”。 换句话说，如果可以在一个更大的查询结果集中而不是几十个或数百个较小的查询结果集中获取所需的所有数据，则通常更可取。 例如，如果需要列出学生及其注册的课程，通常最好在一个联接查询中获取所有数据，而不是让学生在一个查询中并为每个学生的课程执行单独的查询。

修复应用中的 SQL 数据库和实体框架

在 Fix It 应用中 FixItContext ，派生自 Entity Framework DbContext 类的类标识数据库并指定数据库中的表。 上下文指定一个实体集 (表) 任务，代码将连接字符串名称传入上下文。 该名称引用Web.config文件中定义的连接字符串。

public class MyFixItContext : DbContext
{
    public MyFixItContext()
        : base("name=appdb")
    {
    }

    public DbSet<MyFixIt.Persistence.FixItTask> FixItTasks { get; set; }
}

Web.config 文件中的连接字符串名为 appdb， (此处指向本地开发数据库) ：

<connectionStrings>
    <add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;Initial Catalog=aspnet-MyFixIt-20130604091232_4;Integrated Security=True" providerName="System.Data.SqlClient" />
    <add name="appdb" connectionString="Data Source=(localdb)\v11.0; Initial Catalog=MyFixItContext-20130604091609_11;Integrated Security=True; MultipleActiveResultSets=True" providerName="System.Data.SqlClient" />
  </connectionStrings>

实体框架基于实体类中包含的FixItTask属性创建 FixItTasks 表。 这是一个简单的 POCO (Plain Old CLR 对象) 类，这意味着它不继承自实体框架，也不依赖于实体框架。 但实体框架知道如何基于表创建表并执行 CRUD (create-read-update-delete) 操作。

public class FixItTask
{
    public int FixItTaskId  { get; set; }
    public string CreatedBy { get; set; }
    [Required]
    public string Owner     { get; set; }
    [Required]
    public string Title     { get; set; }
    public string Notes     { get; set; }
    public string PhotoUrl  { get; set; }
    public bool IsDone      { get; set; } 
}

Fix It 应用包含一个存储库接口，该接口用于处理数据存储的 CRUD 操作。

public interface IFixItTaskRepository
{
    Task<List<FixItTask>> FindOpenTasksByOwnerAsync(string userName);
    Task<List<FixItTask>> FindTasksByCreatorAsync(string userName); 

    Task<MyFixIt.Persistence.FixItTask> FindTaskByIdAsync(int id);

    Task CreateAsync(FixItTask taskToAdd);
    Task UpdateAsync(FixItTask taskToSave);
    Task DeleteAsync(int id);
}

请注意，存储库方法都是异步的，因此所有数据访问都可以以完全异步的方式完成。

存储库实现调用 Entity Framework 异步方法来处理数据，包括 LINQ 查询以及插入、更新和删除操作。 下面是用于查找“修复它”任务的代码示例。

public async Task<FixItTask> FindTaskByIdAsync(int id)
{
    FixItTask fixItTask = null;
    Stopwatch timespan = Stopwatch.StartNew();

    try
    {
        fixItTask = await db.FixItTasks.FindAsync(id);
        
        timespan.Stop();
        log.TraceApi("SQL Database", "FixItTaskRepository.FindTaskByIdAsync", timespan.Elapsed, "id={0}", id);
    }
    catch(Exception e)
    {
        log.Error(e, "Error in FixItTaskRepository.FindTaskByIdAsynx(id={0})", id);
    }

    return fixItTask;
}

你会注意到这里还有一些计时和错误日志记录代码，稍后我们将在 监视和遥测一章中介绍。

在 Azure 中的 VM (IaaS) 中选择SQL 数据库 (PaaS) 与SQL Server

SQL Server 和 Azure SQL Database 的一个好事是，这两者的核心编程模型是相同的。 可以在这两种环境中使用大多数相同的技能。 甚至可以在开发中使用 SQL Server 数据库，在云中使用 SQL 数据库 实例，这就是 Fix It 应用的设置方式。

作为替代方法，可以在云中运行与在本地运行的相同SQL Server，方法是在 IaaS VM 上安装它。 对于某些旧版应用程序，在 VM 中运行SQL Server可能是更好的解决方案。 由于SQL Server数据库在专用 VM 上运行，因此其可用资源比在共享服务器上运行的SQL 数据库数据库更多。 这意味着SQL Server数据库可以更大，但仍能正常运行。 通常，数据库大小和表大小越小，用例就越适用于 SQL 数据库 (PaaS) 。

下面是有关如何在这两种模型之间进行选择的一些指南。

Azure SQL 数据库 (PaaS)	虚拟机 (IaaS) 中的SQL Server
专业 - 无需创建或管理 VM、更新或修补 OS 或 SQL;Azure 会为你执行该工作。 - 内置高可用性，具有数据库级 SLA。 - 总拥有成本 (TCO) 低，因为只需为使用的内容付费 (无需许可证) 。 - 适用于处理大量小型数据库， (<每个) =500 GB。 - 可轻松动态创建新数据库以启用横向扩展。	优点 - 功能与本地SQL Server兼容。 - 可以在 2 个以上的 VM 中使用 VM 级 SLA 通过 AlwaysOn 实现SQL Server高可用性。 - 可以完全控制 SQL 的管理方式。 - 可以重复使用已拥有的 SQL 许可证，或按小时支付一个许可证。 - 适用于处理更少但更大的 (1 TB 以上的) 数据库。
缺点 - 与本地相比，一些功能差异SQL Server (缺少 CLR 集成、TDE、压缩支持、SQL Server Reporting Services等) - 数据库大小限制为 500GB。	缺点 - (OS 和 SQL) 汇报/修补程序由你负责 - 创建和管理数据库由你负责 - 磁盘 IOPS (每秒输入/输出操作) 限制为大约 8000 (，通过 16 个数据驱动器) 。

如果要在 VM 中使用SQL Server，可以使用自己的SQL Server许可证，也可以按小时支付一个许可证。 例如，在门户中或通过 REST API，可以使用SQL Server映像创建新的 VM。

创建具有SQL Server映像的 VM 时，我们会根据 VM 的使用情况按小时对SQL Server许可证成本进行评分。 如果你有一个只运行几个月的项目，按小时支付会更便宜。 如果你认为你的项目将持续数年，那么按照平时的方式购买许可证会更便宜。

摘要

云计算使混合和匹配数据存储方法变得实用，以最好地满足应用程序的需求。 如果要生成新应用程序，请仔细考虑此处列出的问题，以便选择在应用程序增长时继续正常运行的方法。 下一章将介绍一些可用于合并多种数据存储方法的分区策略。

资源

有关详细信息，请参阅以下资源。

选择数据库平台：

• Highly-Scalable解决方案的数据访问：使用 SQL、NoSQL 和 Polyglot 持久性。 由 Microsoft 模式和实践提供的电子书，深入介绍可用于云应用程序的不同类型的数据存储。
• Microsoft 模式和做法 - Azure 指南。 请参阅数据一致性入门、数据复制和同步指南、索引表模式、具体化视图模式。
• BASE：酸替代品。 有关数据一致性和可伸缩性之间的权衡的文章。
• 七周内的七个数据库：新式数据库和 NoSQL 运动指南。 由埃里克·雷德蒙德和吉姆·威尔逊出版。 强烈建议向自己介绍目前可用的各种数据存储平台。

在SQL Server和SQL 数据库之间进行选择：

• 高级预览版SQL 数据库指南。 SQL 数据库 Premium 简介，以及有关何时在 SQL 数据库 Web 版和企业版中进行选择的指导。
• 数据库) (Azure SQL准则和限制。 链接到有关SQL 数据库限制的文档的门户页面，其中包括重点介绍SQL 数据库不支持的SQL Server功能。
• Azure 虚拟机 中的SQL Server。 链接到有关在 Azure 中运行SQL Server的文档的门户页。
• Scott Guthrie 介绍了 Azure 中的 SQL 数据库。 斯科特·古斯里SQL 数据库的 6 分钟视频介绍。
• Azure 虚拟机中SQL Server的应用程序模式和开发策略。

在 ASP.NET Web 应用中使用实体框架和SQL 数据库

• 入门使用 MVC 5 的 EF 6。 教程系列由九部分组成，指导你构建使用 EF 并将数据库部署到 Azure 和 SQL 数据库 的 MVC 应用。
• 使用 Visual Studio ASP.NET Web 部署。 由 12 个部分构成的系列教程更深入地介绍如何使用 EF Code First 部署数据库。
• 将具有成员资格、OAuth 和SQL 数据库的安全 ASP.NET MVC 5 应用部署到 Azure 网站。 分步教程指导你创建使用身份验证的 Web 应用、将应用程序表存储在成员资格数据库中、修改数据库架构以及将应用部署到 Azure。
• ASP.NET 数据访问内容映射。 指向使用 EF 和 SQL 数据库 的资源的链接。

在 Azure 上使用 MongoDB：

• Azure 上的 MongoDB Atlas。 有关在 Azure 上运行 MongoDB Atlas 的文档的门户页。
• 创建一个 Azure 网站，用于连接到在 Azure 中的虚拟机上运行的 MongoDB。 分步教程介绍如何在 ASP.NET Web 应用程序中使用 MongoDB 数据库。

Azure) 上的 HDInsight (Hadoop：

• HDInsight。 Azure 网站上的 HDInsight 文档门户。
• Hadoop 和 HDInsight：Azure 中的大数据。 Bruno Terkaly 和 Ricardo Villalobos 撰写的 MSDN 杂志文章介绍了 Azure 上的 Hadoop。
• Microsoft 模式和做法 - Azure 指南。 请参阅 MapReduce 模式。

上一页下一页