Azure 表存储和 Windows Azure SQL Database - 比较与对照
本文转自：https://msdn.microsoft.com/library/azure/jj553018
更新时间: 2014年10月
作者：Valery Mizonov 和 Seth Manheim
审阅者：Brad Calder、Jai Haridas、Paolo Salvatori、Silvano Coriani、Prem Mehra、Rick Negrin、Stuart Ozer、Michael Thomassy、Ewan Fairweather
本主题比较 支持的两种结构化存储类型： 表存储和 Microsoft Azure SQL Database，后者以前称为“SQL Azure”。本文旨在提供相应技术的比较，以便你可以了解它们之间的相似性和差异。这一分析可帮助你正确选择能够最好地满足你的具体需要的技术。
当考虑数据存储和持久性选项时， 提供了两种基于云的技术供你选择：Microsoft Azure SQL Database 和 表存储。
Microsoft Azure SQL Database 是一种将核心 SQL Server 功能扩展到云环境的关系数据库服务。通过使用 Azure SQL Database，你可以在云中设置和部署关系数据库解决方案。优势包括托管的基础结构、高可用性、可伸缩性、熟悉的开发模型以及数据访问框架和工具 -- 类似于传统 SQL Server 环境中的对应概念。Azure SQL Database 还提供了一些功能，使你能够在本地 SQL Server 数据库与 Azure SQL 数据库之间进行迁移、导出和持续同步（通过 SQL 数据同步）。
表存储是一种容错且经 ISO 27001 认证的 NoSQL 键值存储区。 表存储可能适用于以下应用：必须存储大量的非关系数据且需要附加结构来存储此类数据。借助于表，可以通过简化的数据访问模式，以低的应用程序成本对未架构化的数据进行基于键的访问。尽管 表存储在存储结构化数据时并不使用架构，但它不提供任何方式来表示数据之间的关系。
尽管存在一些明显的差异，但 Microsoft Azure SQL Database 和 表存储都是具有高可用性的托管服务，其 SLA 达到每月 99.9%。
与 Azure SQL Database 类似， 表存储可存储结构化数据。Azure SQL Database 与 表存储之间的主要区别是：Azure SQL Database 是一个关系数据库管理系统，它基于 SQL Server 引擎并建立在标准关系原则和实践基础之上。因此，它通过 Transact-SQL 查询、ACID 事务以及在服务器端执行的存储过程来提供关系数据管理功能。
表存储是一种灵活的键/值存储区，使你能够轻松地构建云应用程序，而不必将应用程序模型锁定到特定的一组架构。它不是关系数据存储区，不提供与 Azure SQL Database 相同的关系数据管理功能（如联接和存储过程）。 表存储对服务器端查询提供了有限支持，但提供了事务功能。此外，同一个表中的不同行在 表存储中可能具有不同的结构。 表的这一无架构属性也使你能够高效地存储和检索简单的关系数据。
如果你的应用程序存储并检索不需要丰富关系功能的大型数据集，则 表存储可能是更好的选择。如果你的应用程序要求对架构化的数据集进行数据处理并在本质上属于关系型，则 Azure SQL Database 可能更适合你的需要。在 Azure SQL Database 和 表存储之间做出决定之前，应考虑若干其他因素。下一部分列出了其中的某些注意事项。
在确定哪种数据存储技术适用于给定的解决方案时，解决方案架构师和开发人员应考虑以下建议。
作为解决方案架构师/开发人员，在以下情况时，你应考虑使用 表存储：
- 你的应用程序必须存储非常大的数据卷（几个 TB），但同时使成本保持在较低水平。
- 你的应用程序存储和检索大型数据集，但没有需要服务器端联接、辅助索引或复杂服务器端逻辑的复杂关系。
- 你的应用程序需要灵活的数据架构以存储非一致性对象，而这些对象的结构在设计时可能是未知的。
- 你的业务要求跨多个地理位置执行灾难恢复功能，以便满足特定的合规性要求。 表可在一个大洲中相隔数百英里的两个数据中心之间进行地理复制。这种复制可在出现重大灾难的情况下提供额外的数据可持续性。
- 你需要存储高于 150 GB 的数据，而不需要实现分片或分区逻辑。
- 你需要实现高级别的可伸缩性，但不必手动对数据集分片。
作为解决方案架构师/开发人员，在以下情况时，你应考虑使用 Microsoft Azure SQL Database：
- 你的应用程序要求对架构化、高度结构化的数据集以及关系进行数据处理。
- 你的数据在本质上是关系数据，要求采用关系数据编程模型的关键原则，以便使用数据唯一性规则、参考约束以及主键或外键来实施一致性。
- 在你的数据卷中，并置数据集的每个单位（这通常转换为单个数据库）不超过 150 GB。但是，你可以跨多个数据集对数据进行分区，以超出规定的限制。请注意，这一限制将来可能会进行更改。
- 现有的以数据为中心的应用程序已经使用 SQL Server，并且你要求通过使用数据访问框架对结构化数据进行基于云的访问。同时，应用程序要求在本地与 之间具有无缝的可移植性。
- 你的应用程序计划利用 T-SQL 存储过程在数据层内执行计算，这样就最大限度地减少了应用程序与数据存储之间的往返次数。
- 你的应用要求通过一致的查询语义（包括联接、聚合和复杂的谓词）来支持空间数据、丰富的数据类型以及复杂的数据访问模式。
- 你的应用程序必须使用现成的报告工具，针对数据模型提供可视化和商业智能 (BI) 报告。
 备注 |
|---|
| 许多 应用程序可以同时利用这两种技术。因此，建议你考虑结合使用这些选项。
|
此部分比较 表存储与 Azure SQL Database 提供的一些基本存储功能。
| 比较条件 | 表存储 | Azure SQL Database |
|---|---|---|
|
数据关系 |
否 表存储不提供任何方式来表示数据之间的关系。你可以通过使用表的无架构属性并以所需格式对数据进行结构化，以获取简单的关系。 |
是 与 SQL Server 类似，Azure SQL Database 允许你通过使用外键来定义不同表中存储的数据之间的关系。 |
|
服务器端处理 |
否 支持基本操作（如 insert、update、delete 和 select），但它在存储引擎端上不支持联接、外键、存储过程、触发器或任何处理。 |
是 提供标准的 SQL Server 功能，如存储过程、视图、多个索引、联接和聚合。 |
|
事务支持 |
受限 对同一个表和同一分区中的实体支持事务。一个事务中支持多达 100 个操作。支持开放式并发。有关详细信息，请参阅 TechNet 上的实体组事务。 |
是 支持同一数据库中的典型 ACID 事务。但不支持跨数据库的事务。Azure SQL Database 也支持乐观并发。 |
|
地理复制 |
是 默认情况下，表复制到其他区域。这种复制可提供高级别的灾难恢复功能。 |
否 截至撰写本文之时，Azure SQL Database 实例不复制到其他区域。此行为在将来可能发生变化。 |
|
表架构 |
已放宽 每个实体（行）都可以具有不同的属性。例如，在同一个表，你可以在一行中存储订单信息，而在另一行中存储客户信息。 |
托管 在定义整个表的固定架构之后，可随时进行更改。所有行都必须遵守架构规则。考虑使用 XML 类型或稀疏列来获得附加灵活性。 |
|
与本地使用的现有数据存储区的相似性 |
否 基于云的存储，目前本地没有对应的替代项。 |
是 类似于具有某些限制的 SQL Server。有关详细信息，请参阅 TechNet 上的 一般性的指导原则和限制。 |
|
向外扩展 |
自动 基于 PartitionKey 属性进行分区。一个表可以存储在不同存储设备上的不同分区中。此结构允许客户端并行访问数据。 |
手动 通过使用 SQL 联合或自定义分片方法，跨数据库实例的托管组进行分片。 |
|
数据类型 |
简单 有关有关支持的数据类型的详细信息，请参阅“附加信息”部分的表。 |
简单、复杂和用户定义 Azure SQL Database 支持一组丰富的数据类型，包括自定义的用户定义类型。 |
- 当你创建 表时，你不必定义任何列。表自身没有结构化且不具备设计时架构。列名称是表中存储的实体（行）的一部分，它们针对单个表中的不同实体可能不同。 表甚至可能具有两个属性名称相同的实体，但对于属性值使用不同类型。但是，属性名称在单个实体中必须是唯一的。
- 表存储不支持关系功能（如查询或事务中的联接和聚合）以跨多个表协调修改。存储在 表中且具有相同分区密钥的实体是在存储区中一起提供的。你可以高效地检索这些实体，并可以使用实体组事务在单个请求中修改它们。
- 使用实体组事务时，应注意某些限制。这些限制包括 4 MB 最大批处理大小，以及批处理中的所有实体都必须共享相同的分区键值。有关详细信息，请参阅本文。
- 表存储类型提供了一个聚集索引，结果始终按 PartitionKey 和 RowKey 以升序排列。PartitionKey 和 RowKey 值唯一标识表中的行。如果你尝试使用相同的 PartitionKey 和 RowKey 创建两行，则会生成异常。
- 本文提供有关在 Azure SQL Database 与本地 SQL Server 之间进行选择的决策树。还可以将这些决策条件应用于 Azure SQL Database 与 表存储。
- 应用于这两种技术的吞吐量条件是一个具有许多变量的复杂方程式。这些因素包括查询类型及其复杂性、数据访问模式、结果集大小、存储基础结构的临近性以及网络延迟。始终建议你执行自己的性能测试，以更好和更可靠地衡量相关的指标，同时考虑特定一类应用程序的具体细节。有关 Azure 表的有关最佳实践的详细信息，请参阅此博客文章。
- 下表列出了针对 表中的属性值支持的数据类型。有关 Azure SQL Database 支持的数据类型的列表，请参阅Data Types (Azure SQL Database)。
属性类型 详细信息 Binary
一个大小高达 64 KB 的字节数组。
Bool
一个布尔值。
DateTime
一个表示为 UTC 时间的 64 位值。支持的值范围为 1/1/1601 到 12/31/9999。
Double
一个 64 位浮点值。
GUID
一个 128 位的全局唯一标识符。
Int
一个 32 位整数。
Int64
一个 64 位整数。
String
一个 UTF-16 编码的二进制值。字符串值的大小可高达 64 KB。
本节比较 表存储和 Azure SQL Database 提供的高级功能。
| 比较条件 | 表存储 | Azure SQL Database |
|---|---|---|
|
可通过本地应用程序或非 平台中承载的应用程序进行访问 |
是 |
是 |
|
一致性模型 |
强 |
强 |
|
Windows Communication Foundation (WCF) 数据服务客户端支持 |
是 |
是 |
|
REST 客户端支持 |
是 内在支持基于 REST 的访问。 |
是 通过在 SQL 数据库的顶部添加一个 OData 层，支持基于 REST 的访问。 |
|
防火墙防护（受限 IP 范围访问） |
否 |
是 使用 Azure 防火墙，此防火墙可以从门户或使用命令行工具来配置。 |
|
事务限制行为 |
是 有关详细信息，请参阅 TechNet 上的 此博客文章。 |
是 有关详细信息，请参阅 TechNet 上的 本文。 |
|
容错 |
是 为了提供高级别的容错功能，将在区域内复制三次存储的数据，并在另一个相隔至少 400 英里（644 公里）的区域内另外复制三次。 |
是 在所选的数据中心内保留 Azure SQL Database 实例的三个副本。 |
|
日志记录和度量 |
是 有关详细信息，请参阅 TechNet 上的 此博客文章。 |
否 |
|
事务日志 |
否 |
是 事务日志大小上限为 10 GB，单个事务限制为 1 GB。 |
- 可以使用内置的防火墙功能在网络级别限制对 Azure SQL Database 实例的访问。此外，还可以通过 门户配置防火墙访问规则。相比较而言，任何可通过 HTTP/HTTPS 连接到 存储帐户端点的客户端都可以获得对 表的访问权限。
- 表存储为针对表中单一实体的插入/更新/删除事务以及实体组事务提供 ACID 事务保证。为针对服务的每个单一查询请求提供快照隔离。执行查询时，从该查询开始以及整个事务期间，将保持分区的一致视图。应用程序开发人员负责维护多个表之间的一致性。
- 表支持日志记录，使你能够查看针对你的服务执行的每个请求。日志记录还提供针对你的服务的聚合请求度量。
- Microsoft Azure SQL Database 目前不提供日志记录和度量；但它提供动态管理视图 (DMV) 子集，以诊断查询性能问题、监视数据库连接、查看活动的事务并检查查询计划。
- 因为 Microsoft Azure SQL Database 建立在 SQL Server 引擎基础之上，所以某些概念（如 TempDB 和事务）仍然是相关的。为了防止事务日志文件的增长超出预期，Azure SQL Database 对日志大小强加了 10 GB 的限制。Azure SQL Database 基础结构管理你无法直接访问的这些事务日志。 表存储没有与事务日志等同的项。 表存储支持的日志记录和度量功能不同于事务日志，因为它跟踪对服务的请求，而不跟踪正在修改的实际数据。
- 为防止在多租户环境中过度占用资源， 表存储和 Azure SQL Database 两者都使用可控制系统阈值的机制。此机制也称为“限制”，其行为在这两项服务之间有所不同。例如，Azure SQL Database 使用两种限制策略：“软限制”和“硬限制”。本文详细介绍了这些限制机制。
本部分从可能适用的容量和配额的角度比较 表存储和 Azure SQL Database。请注意，此处说明的所有容量和配额将来可能会进行更改。
| 比较条件 | 表存储 | Azure SQL Database |
|---|---|---|
|
最大行大小 |
1 MB 属性不超过 255 个，包括三个必需属性：PartitionKey、RowKey、Timestamp。 |
2 GB 可包含多达 1024 列（或者，如果使用稀疏列，则为 30,000 列）。使用 varchar(max)、varbinary(max)、xml、text 或 image 列可提供高达 2 GB 的行外存储。 |
|
最大数据大小 |
每个表 200 TB 如果是在 2012 年 6 月 8 日或之后创建的，单个存储帐户（包含表、blob 和队列）可最多包含 200TB 的 blob、队列和表数据；对于在该日期之前创建的存储帐户，总容量为 100TB。因此， 表的最大大小为 200 TB。 |
每个数据库 150 GB 尽管允许的最大数据库大小将来可能会增加，但请考虑使用 SQL 联合（或自定义分片）来存储更大的数据集。 |
|
每个查询检索的最大行数 |
1,000 响应单一请求时，返回的行（实体）数不超过 1,000。如果查询结果多于此数值，将返回一个继续标记，以允许查询继续处理更多请求。 |
无限制 如果未正确优化，连接和查询超时可能会限制所提取的行数。 |
- 表存储在响应标题中使用继续标记，以指示查询具有更多结果。你可以通过发出另一个请求（已通过继续标记进行参数化）来检索这些结果。通过此方案，你检索的项可超过 1,000 个实体的限制。将针对每个请求维护快照一致性，但不会跨查询的继续标记请求维护快照一致性。
- 表行（实体）中所有字段（属性）的组合大小不能超过 1 MB。此限制包括属性名称的大小以及属性值或其类型，包括两个必需的关键属性（PartitionKey 和 RowKey）。
- Azure SQL Database 目前支持 5 GB 数据库 (Web Edition) 或最高 150 GB 数据库 (Business Edition)。为了将其大小保持在给定的阈值内，开发人员应负责监视数据库。Azure SQL Database 最大大小可通过管理操作进行预配置，而不会随着存储的数据卷增长自动递增。有关详细信息，请参阅 TechNet 上的 Azure SQL Database 文档中的 ALTER DATABASE (Azure SQL Database)。
- 常规 Azure SQL Database 表中的列数限制为 1024（类似于本地 SQL Server）。使用稀疏列时，一个表可以包含多达 30,000 列，其中最多有 1023 列可以是非稀疏列。但是，至少 28,976 列必须是稀疏列。如果总列数大于 1024，则将一个非稀疏列用于必需的列集。
本部分比较 表存储和 Azure SQL Database 提供的管理功能。
| 比较条件 | 表存储 | Azure SQL Database |
|---|---|---|
|
管理协议和工具 |
HTTP/HTTPS 上的 REST 可以使用 Azure 存储资源管理器或其他第三方工具，如 Cloud Storage Studio。 |
ODBC/JDBC HTTP/HTTPS 上的 REST 可以使用 管理门户或 SQL Server Management Studio 来管理 Azure SQL Database 实例。 |
|
数据访问 |
OData 协议接口 你可以通过使用 Azure SDK 中随附的 HTTP(S) REST API 或用于 WCF Data Services 的 .NET 客户端库来访问数据。 |
ODBC/JDBC 通过使用现有技术（如 ADO.NET 和 ODBC）编写的可与 SQL Server 通信的应用程序，只需经过很少的代码更改，即可访问 Azure SQL Database 实例。 |
|
Java API 支持 |
是 |
是 |
|
Node.js API 支持 |
是 |
是 |
|
PHP API 支持 |
是 |
是 |
|
LINQ 支持 |
是 |
是 |
|
Python 支持 |
是 |
否 |
|
离线开发人员体验 |
是 由 SDK 中随附的本地存储模拟器提供。 |
否 SQL Express 或 SQL Server 的其他版本是不同的产品，不提供对 Microsoft Azure SQL Database 环境的完全模拟。 |
本部分讨论 表存储和 Azure SQL Database 支持的身份验证和授权功能。
| 比较条件 | 表存储 | Azure SQL Database |
|---|---|---|
|
身份验证 |
对称密钥 共享的访问签名 512 位 HMAC 密钥用于验证用户的身份。 |
SQL 身份验证 标准 SQL 身份验证用于验证用户的身份。 |
|
基于角色的访问 |
否 |
是 支持标准的 SQL 数据库和应用程序角色。 |
|
支持 Azure Active Directory（以前称为 ACS） |
否 |
否 |
|
标识提供商联合 |
否 |
否 |
- Azure SQL Database 支持的基于角色的访问提供了完全的灵活性，用于配置只读、只写和读写模式。此功能可以提供一组丰富的数据访问选项，具体取决于各应用程序的需要。
- 因为任一种技术当前都不支持联合身份验证、基于证书的身份验证或 Active Directory 身份验证，所以，你必须确保安全凭据（例如，HMAC 密钥或 SQL 用户名和密码）由适当的保护措施（如加密）来涵盖。当对这些凭据的访问要符合 IT 策略时，这种保护尤其重要。
- 表存储提供经签名的基于 URL 的访问，称为“表 SAS”（共享的访问签名）。通过 SAS，你可以授予对客户端的基于时间的访问，而不需要泄露存储帐户密钥。有关详细信息，请参阅此博客文章。
本部分从成本角度对 表存储和 Azure SQL Database 进行比较。此处说明的所有成本将来可能会进行更改。
| 比较条件 | 表存储 | Azure SQL Database |
|---|---|---|
|
存储成本 |
$0.125 每月存储的每 GB（基于日平均值） 有关定价详细信息，请参阅 Azure 定价概述。 |
根据数据库大小按照渐变费率进行计费。 有关定价详细信息，请参阅 Azure 定价概述。 |
|
事务成本 |
$0.01 每 100,000 个存储事务。 |
$0.00 Azure SQL Database 不对事务进行收费。 |
|
计费操作 |
全部 除了存储成本之外，还将根据针对表的事务量来计算事务成本。 |
无 成本不依赖于事务量，而只取决于数据库大小。 |
|
流出成本 |
$0.12 - $0.19 每 GB，基于渐变、特定于区域的规模 |
$0.12 - $0.19 每 GB，基于渐变、特定于区域的规模 |
决定何时使用 表存储或 Microsoft Azure SQL Database 取决于很多因素。这些因素可能很大程度上取决于应用程序的独特需要、其体系结构以及工作负荷和数据访问模式。这一部分汇总了一些重要注意事项。
表存储支持将大量数据存储在云中具有极高可伸缩性的表中。这些表可以存储 TB 级的数据和几十亿个实体。为了达到这一可伸缩性级别， 表存储采用扩展模型以在多个存储节点间分布实体。它使用 NoSQL 数据模型来支持如此高的可伸缩性和强一致性。如果你要求以较低的成本持久保留大量的非关系或简化数据模型，请考虑使用 表存储。
你可以将 Microsoft Azure SQL Database 视为扩展到云平台的 SQL Server 数据库引擎，同时提供熟悉的 SQL Server 开发人员体验、丰富的查询语义、通过不同隔离级别支持 ACID 事务以及复杂的数据处理功能。如果你的数据属于高度关系数据，并且你要求关系数据管理与这些功能相结合，则 Azure SQL Database 可能是更好的选择。
注意，决定何时使用特定的技术并非总是两者选一的问题，你可能始终无法决定偏爱某个单一技术。你可以评估是否能将这两种技术平衡结合以满足你的解决方案的需要，并考虑在各自领域应用这两种技术来解决你要解决的特定问题类别。
通过对两种技术的更深入了解，你可以更加明确地决定在 中使用哪种数据存储技术以及在何种情况下使用。
另请参阅
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
