【IT168 技术】在去年11月召开的SQL PASS大会上，微软公布了内存OLTP数据库技术(代号为‘Hekaton’)，旨在为SQL Server的下一个版本做好准备。微软技术研究员Dave Campbell在博客中对该技术的预期作用及设计原理做出了阐释，同时总结出四项创建原则：一、优化主内存数据访问;二、加快业务逻辑处理速度;三、提供无冲突扩展能力;四、内置于SQL Server中。在本文中，笔者将专注于解读前三项原则背后的实际功能组件——包括新组件的作用以及如何以高效可扩展方式实现这三项原则。

　　全新内存OLTP架构利用更加高效的存储执行流程实现性能提升。这种对执行效率的关注是为了满足单CPU运算核心用例的实际需求，其意义不言而喻。由于OLTP存储程序中的访问命令行数相对较少，多核心并行处理能力往往没有机会一展拳脚。有鉴于此，研究人员与SQL性能设计团队达成一项共识：必须使数据库系统代码更具执行效率，从而实现性能的显著提升。

　　但是，数据库引擎中到底有哪些方面需要获得效率提升?要回答这个问题，我们必须首先了解处理时间被用在了数据库系统中的哪些方面。上图以比较简略的方式显示出数据库组件堆栈，右侧的百分数则代表上一代SQL Server版本中各组件在OLTP工作负载运行过程时所花费的时间百分比。绿色框体对应关系类引擎，蓝色框体则代表存储引擎。

　　看到这幅图表，大家肯定会马上意识到，单独提升任何单一区域的处理速度无法带来显著的性能提升。另外，如果能建立起一套速度极快、效率两倍于前代版本的主记忆体引擎(本质上是一套精简化存储引擎)，那么过去被浪费在查询与存储处理过程当中的时间会得到大幅缩短。不过最大的挑战在于，随着连续多个版本的持续优化，如今SQL Server的改进空间已经非常有限。

　　与其改变已经高度优化过的现有SQL Server组件，不如将注意力集中在新的流程化组件针对OLTP工作负载进行优化，并将使用频率最高、对性能需求最强烈的数据始终驻留在内存当中。最后，把这些组件直接添加到SQL Server当中。

　　这种注重效率的处理方式对两大关键性架构化组件提出要求：一套内存优化引擎，外加一个将针对内存优化引擎的程序与查询请求保存为本机代码的编译器。

　　内存优化引擎

　　内存优化引擎管理着包括索引、事务、检查点(即存储)以及表示为memory_optimized的恢复列表在内的多个方面，因此将作为SQL Server列表存储引擎的核心组成部分出现。

　　在Dave Campbell的博文中表示，这套引擎通过对始终驻留在内存当中的相关数据进行“乐观”的处理方式来实现性能提升。在大多数情况下，该引擎的精简与优化方案都能起到理想的性能改善效果;不过在极少数情况下它的处理速度并不像想象中那么快。如果将数据驻留在内存中的优化机制确实效果明显，那么这套引擎将成为切实可行的高性能方案。早在2008年，Facebook就曾经尝试将28TB的数据驻留在主内存中以加快数据库处理速度。

　　这套“乐观型”优化方案在很多细节层面都能有所贡献。举例来说，SQL Server的存储引擎会在每一次列表或者索引更新后生成事务日志记录。日志记录中不仅包含重新执行操作所必要的信息，还囊括了撤销操作信息，因此必须被立即安置在日志缓冲区当中(这一操作目前仍备受争议)——之所以这么做，是因为过去的存储引擎往往会以“悲观”的态度假设缓冲页面中包含的新近更新记录可能会在更新事务完成之前就被发往检查点或者磁盘端。事实上，典型的OLTP事务处理流程根本不可能出现这类问题，缓冲池的大小也非常合理。为了解决这个问题，新引擎采取“乐观”的态度，直接禁止将未提交的更新传送至检查点或磁盘处，这样系统就不必撤销这些变化信息或者主动将其发送至日志缓冲区。而在短期事务方面，引擎会在事务提交时生成一个单独的日志记录，用于描述事务内容。

　　引擎架构中的“乐观”型方案最显著的特色在于，引擎优化所针对的事务之间不存在冲突。多版本机制消除了多数不同事务之间的潜在冲突机率，其余事务则依靠回滚机制而非粗暴阻断来避免问题的发生。

　　这种刻意避免阻塞处理的方式正是新引擎的设计核心，其重要意义并不仅限于事务并行领域。处理器运算核心的增加需要由数据库引擎针对大量并发性事务的严格调整方可实现。尽管SQL Server在多OLTP工作负载的扩展性方面表现出色，但索引末尾等因素仍然会对某些应用程序的资源扩展产生障碍。新引擎的设计方案规避了锁存器及自旋锁对关键领域性能表现的负面影响，并利用多版本“乐观”并发控制消除了由争用引发的锁定，从而解决了扩展性难题。“乐观”并发控制、多版本以及无锁存器数据架构的组合让整套系统中的线程执行不再面临拖延或者等待。这样的新特性非常重要，因为阻塞会导致运行背景切换，这对于引擎所处的系统而言是一种严重的效率影响因素。事实上，通过前文列出的图表可以看出，下方标注为“线程管理”的灰色框体就代表着由环境切换引发的时耗。

　　存储程序编译器

　　正如前文所述，高速引擎在处理OLTP事务时的执行成本将降低一半还多。对T-SQL存储程序及其查询计划的解释工作也是成本支出中的重点。对于一项OLTP工作负载而言，其主要目标在于提升一次编译、多次执行类工作负载的执行效率，而非对暂时性查询进行优化。出于这样的考虑，存储程序编译器正式亮相。它能将T-SQL存储程序及其查询加以变换(标注为native_compiled)，最终转化为高度定制化的本地代码。这款编译器能够重复使用大部分SQL Server T-SQL语言堆栈，其中包括元数据、分析器、名称解析、类型推导以及查询优化等。这种紧密的集成机制有助于实现同现有SQL Server T-SQL语言一一对应的语义及语法匹配。存储程序编译器的输出结果为C代码，并能利用微软Visual C/C+编译器将C代码转化为机器代码。

　　决定代码最终执行效率的因素在于对转译成果的大量优化。大部分代码都由专门的生成机制处理而非采用通用性编译程序。换句话来说，系统会优先分配代码的编译时间、从而最大程度缩短未来的实际执行时间。其它方面的优化还有很多。举例来说，即使原始版本无法变更，所生成的代码也能够享受内存优化引擎带来的性能提升。由于生成获得的代码并非简单复制原始数据，因此能够被指针直接引导至内存中的实时数据库。

　　总结

　　main_memory引擎与存储程序编译器的出现最终使得程序与查询所耗用的指令及处理器周期相较常规SQL服务器上运行的内存内数据减少了十到四十倍。当然，系统中还存在与代码生成及引擎并无关联的计算任务，例如客户端/服务器通信以及事务日志处理等。由于全局执行时间中包含全部任务所产生的影响，因此某些特定工作负载的加速效果可能不太明显。微软将在未来的后续版本中解决这些问题。

　　当然，数据库产品并不能单单依靠执行速度与可扩展组件来吸引客户——使用者们还希望获得安全性保障、高可用性、管理工具以及丰富的编程语言等等。内存OLTP系统根据客户的实际需求向SQL Server添加了大量经过高度优化的功能性组件，并在功能扩展的同时保证了出色的原始性能。

　　本文深入探讨了新组件与SQL Server之间的紧密集成，希望能为大家带来帮助，感兴趣的朋友可以点击此处下载SQL Server 2014 CTP1版本。

　　原文链接：Architectural Overview of SQL Server 2014’s In-Memory OLTP Technology