使用 Azure SQL 数据库中的内存中技术可在各种工作负荷上实现性能改善:事务工作负荷(联机事务处理 (OLTP))、分析工作负荷(联机分析处理 (OLAP))和混合工作负荷(混合事务 / 分析处理 (HTAP))。 由于查询和事务处理的效率提升,内存中技术还可降低成本。 用户通常不需要升级数据库的定价层即可实现性能提升。 在某些情况下,即使是降低定价层,使用内存中技术也能实现性能改善。
以下两个示例演示了如何借助内存中 OLTP 大幅改善性能:
- 使用内存中 OLTP,仲裁商业解决方案能够使其工作负荷增加一倍,同时节省 70% 的 DTU 。
- DTU 表示“数据库吞吐量单位”,包括资源消耗量的测量值。
- 这个视频使用示例工作负荷演示资源消耗方面的重大改进: In-Memory OLTP in Azure SQL Database Video (“Azure SQL 数据库中的内存中 OLTP”视频)。
- 有关更多详细信息,请参阅博客文章: In-Memory OLTP in Azure SQL Database Blog Post (“Azure SQL 数据库中的内存中 OLTP”博客文章)
可在高级层中的所有数据库(包括高级弹性池中的数据库)内使用内存中技术。
该视频介绍了使用 Azure SQL 数据库中的内存中技术可带来的潜在性能提升。 请记住,实际带来的性能提升取决于许多因素,包括工作负荷和数据的性质、数据库的访问模式,等等。
Azure SQL 数据库采用以下内存中技术:
- 内存中 OLTP 可提升吞吐量并降低事务处理的延迟。 可受益于内存中 OLTP 的情况有:高吞吐量事务处理(例如贸易和游戏)、从事件或 IoT 设备引入数据、缓存、数据加载以及临时表和表变量等情况。
- 聚集列存储索引可减少存储占用(高达 10 倍)并提高报告和分析查询的性能。 将其与数据集市中的事实数据表结合使用,可在数据库中容纳更多数据并提升性能。 此外,将其与操作数据库中的历史数据结合使用,可存档并查询高达 10 倍的额外数据。
- 用于 HTAP 的非聚集列存储索引:通过直接查询操作数据库来帮助获取业务的实时见解,无需运行开销不菲的提取、转换和加载 (ETL) 过程并等待填充数据仓库。 非聚集列存储索引允许非常快速地对 OLTP 数据库执行分析查询,同时减少对操作工作负荷的影响。
- 也可以使用内存优化表与列存储的组合。 使用这种组合可以针对相同的数据极快执行事务处理和并发运行分析查询。
列存储索引和内存中 OLTP 分别在 2012 年和 2014 年加入 SQL Server 产品。 Azure SQL 数据库和 SQL Server 共享内存中技术的相同实现。 今后,这些技术的新功能将首先在 Azure SQL 数据库中发布,再加入到下一个版本的 SQL Server。
本主题全面介绍特定于 Azure SQL 数据库的内存中 OLTP 和列存储索引,并提供示例:
- 介绍这些技术对存储和数据大小限制的影响。
- 介绍如何控制使用这些技术的数据库在不同定价层之间的移动。
- 介绍两个示例,演示如何使用 Azure SQL 数据库中的内存中 OLTP 和列存储索引。
有关详细信息,请参阅以下资源。
有关这些技术的深入信息:
- 内存中 OLTP 的概述和使用方案(包括客户案例研究参考和入门信息)
- 内存中 OLTP 的文档
- 列存储索引指南
- 混合事务 / 分析处理 (HTAP),也称为实时运行分析
有关内存中 OLTP 的快速入门教程:快速入门 1:通过内存中 OLTP 技术加速 T-SQL 性能(另一篇帮助用户入门的文章)
深入介绍这些技术的视频:
- Azure SQL 数据库中的内存中 OLTP (包含性能优势的演示和自行重现这些结果的步骤)
- In-Memory OLTP Videos: What it is and When/How to use it (内存中 OLTP 相关视频:定义及其适用时间和使用方法)
- Columnstore Index: In-Memory Analytics Videos from Ignite 2016 (列存储索引:来自 Ignite 2016 的内存中分析相关视频)
存储和数据大小
内存中 OLTP 的数据大小和存储上限
内存中 OLTP 包括用于存储用户数据的内存优化表。 这些表必需在内存可容纳的范围内。由于内存是直接在 SQL 数据库服务中管理的,因此我们提出了用户数据配额的概念。 这种概念称为内存中 OLTP 存储。
每个受支持的独立数据库定价层和每个弹性池定价层都包括一定量的内存中 OLTP 存储。在编写本文时,每 125 个数据库事务单位 (DTU) 或弹性数据库事务单位 (eDTU) 可使用 1 GB 存储。
对于每个受支持的独立数据库和弹性池定价层可用的内存中 OLTP 存储, SQL 数据库服务层一文提供了正式列表。
以下各项计入内存中 OLTP 存储上限:
- 内存优化表中的活动用户数据行和表变量。 请注意,旧行版本不计入上限。
- 内存优化表中的索引。
- ALTER TABLE 操作的运营开销。
如果达到上限,将会出现超出配额错误,且无法再插入或更新数据。若要解决此错误,可删除数据或提升数据库或池的定价层。
有关监视内存中 OLTP 存储利用率及配置即将达到上限时的警报的详细信息,请参阅监视内存中存储。
关于弹性池
使用弹性池时,池中的所有数据库共享内存中 OLTP 存储。因此一个数据库中的使用量可能对其他数据库造成影响。对此,有
两个缓解方法:
- 为低于池的 eDTU 计数的数据库整体配置最大 eDTU。此最大值将池中任意数据库中的内存中 OLTP 存储利用率限制为与 eDTU 计数对应的大小。
- 配置大于 0 的最小 eDTU。此最小值可保证池中的每个数据库都有与配置的最小 eDTU 对应的可用内存中 OLTP 存储量。
列存储索引的数据大小和存储
列存储索引不需要在内存可容纳的范围内。因此,索引大小的唯一上限是最大整体数据库大小,此大小在 SQL 数据库服务层一文中有述。
使用聚集列存储索引时,对基础表存储使用列式压缩。这种压缩可显著减少用户数据的存储占用,意味着数据库中可容纳更多数据。使用纵栏表存档压缩可进一步提高压缩率。 可实现的压缩量取决于数据的性质,但 10 倍压缩并不少见。
例如,如果数据库的最大大小为 1 TB,则使用列存储索引实现 10 倍压缩时,该数据库中可容纳总共 10 TB 的用户数据。
使用非聚集列存储索引时,仍以传统行存储格式存储基础表。 因此节省的存储小于使用聚集列存储索引节省的空间。但是,如果使用单个列存储索引取代众多传统非聚集索引,则仍可整体减少表的存储占用。
在定价层之间移动使用内存中技术的数据库
升级到更高的定价层时(例如,从标准层升级到高级层),绝对不会出现任何不兼容性或其他问题。 可用的功能和资源只会增加。
但是,降级定价层可能会对数据库造成负面影响。 如果数据库包含内存中 OLTP 对象,则从高级层降级到标准或基本层时,影响就尤为明显。 降级后,内存优化表和列存储索引不可用(即使它们保持可见)。 降低弹性池的定价层或将使用内存中技术的数据库移动到标准或基本弹性池时,也应考虑这些问题。
内存中 OLTP
降级到基本 / 标准层:标准或基本层中的数据库不支持内存中 OLTP。 此外,不能将包含任何内存中 OLTP 对象的数据库移到标准或基本层。
将数据库降级到标准 / 基本层之前,请删除所有内存优化表和表类型,以及所有本机编译的 T-SQL 模块。
可通过编程方式了解给定的数据库是否支持内存中 OLTP。 可执行以下 Transact-SQL 查询:
评论