我正在研究从 MS SQL 2012 升级到 2014 的好处。SQL 2014 的一大卖点是内存优化表,这显然使查询速度超快。
我发现内存优化表有一些限制,例如:
- 没有
(max)
大小的字段 - 每行最大约 1KB
- 没有
timestamp
字段 - 没有计算列
- 没有
UNIQUE
限制
这些都算作滋扰,但如果我真的想解决它们以获得性能优势,我可以制定一个计划。
真正的问题在于您无法运行语句,并且每次您将字段添加到索引列表中时ALTER TABLE
,您都必须经历这个繁琐的过程。INCLUDE
此外,您似乎必须将用户关闭系统才能对实时数据库上的 MO 表进行任何模式更改。
我觉得这完全令人发指,以至于我实际上无法相信微软会在这个功能上投入如此多的开发资金,却让它变得如此不切实际。这使我得出结论,我一定是弄错了。我一定误解了关于内存优化表的一些东西,这使我相信维护它们比实际情况要困难得多。
那么,我误解了什么?你用过MO表吗?是否有某种秘密开关或过程使它们易于使用和维护?
不,内存中真的是这样粗糙的。如果你熟悉敏捷,你就会知道“最小可交付产品”的概念;内存中就是这样。我觉得 MS 需要对 SAP 的 Hana 及其同类产品做出回应。这是他们可以在 2014 年发布的时间范围内调试的内容。
与内存中的其他任何东西一样,它也有与之相关的成本和收益。主要好处是可以实现的吞吐量。正如您所提到的,其中一项成本是变更管理的开销。在我看来,这并没有使它成为无用的产品,它只是减少了它将提供净收益的案例数量。正如列存储索引现在可以更新并且可以过滤索引一样,我毫不怀疑内存中的功能将在即将发布的版本中得到改进。
SQL Server 2016 现已正式发布。正如我所想的那样,内存中 OLTP已收到许多增强功能。大多数更改实现了传统表格已经享受了一段时间的功能。我的猜测是,内存表和传统表的未来功能将同时发布。临时表就是一个例子。此版本中的新增功能受内存表和基于磁盘的表的支持。
新技术的问题之一——尤其是被大声披露为功能不完整的 V1 版本——是每个人都赶上潮流,并认为它非常适合各种工作负载。它不是。Hekaton 的最佳点是 256 GB 以下的 OLTP 工作负载,并在 2-4 个套接字上进行大量点查找。这符合您的工作量吗?
许多限制与内存表与本机编译的过程相结合。当然,您可以通过使用内存表而不是使用本机编译的过程,或者至少不完全使用,来绕过其中的一些限制。
显然,您需要测试在您的环境中性能提升是否显着,如果是,权衡是否值得。如果您从内存表中获得了巨大的性能提升,我不确定您为什么担心要对 INCLUDE 列执行多少维护。根据定义,您的内存索引是覆盖。这些应该只有助于避免查找范围或传统非聚集索引的完整扫描,并且这些操作不应该发生在内存表中(同样,您应该分析您的工作负载并查看哪些操作改进了而哪些没有——这并非都是双赢的)。您今天多久在索引上使用 INCLUDE 列?
基本上,如果它的 V1 形式对您来说不值得,请不要使用它。这不是我们可以为您回答的问题,只是告诉您,许多客户愿意忍受这些限制,并且尽管存在这些限制,但仍使用该功能来获得巨大利益。
SQL 服务器 2016
如果您正在走向 SQL Server 2016,我已经在博客中介绍了您将在 In-Memory OLTP 中看到的增强功能,以及消除了一些限制。最为显着地:
您无法从 Sql Server Management Studio 中右键单击内存优化表以拉出设计器并根据需要添加新列。您也不能在表格名称内单击作为重命名表格的一种手段。(在我撰写本文时,SQL 2014。)
相反,您可以右键单击该表,然后将创建命令编写到新的查询窗口中。可以通过添加任何新列来修改此创建命令。
因此,要修改表,您可以将数据存储在新表、临时表或表变量中。然后您可以使用新模式删除并重新创建表,最后复制回实际数据。对于大多数用例来说,这个 3 容器 shell 游戏只是不太方便。
但是,如果没有您要解决的性能问题,您就没有理由为内存优化表而烦恼。
然后,您必须权衡限制和变通方法是否值得您的用例。你有性能问题吗?您是否尝试过其他所有方法?这会将您的性能提高 10-100 倍吗?无论哪种方式,使用或不使用它都可能最终变得有点轻率。
您可以在 Operational Servers 中使用 In-Memory OLTP 而不会出现任何重大问题。我们在一家银行和支付公司使用了这项技术,
一般来说,当工作量太大时,我们可以使用内存优化表。通过使用内存中 OLTP,您可以将性能提高到 30 倍!Microsoft 纠正了 SQL Server 2016 和 2017 中的大部分限制。与基于磁盘的表相比,内存优化表具有完全不同的体系结构。
内存优化表有两种类型。耐用的桌子和非耐用的桌子。持久表和非持久表维护驻留在内存中的表数据。此外,更持久的表将数据持久保存在磁盘上以用于恢复数据和架构。大多数操作场景我们应该使用持久表,因为数据丢失在这里很关键。在某些情况下,例如 ETL 加载和缓存,我们可以使用非持久表。
您可以使用这本电子书并学习如何使用这项技术:
卡伦德莱尼: https ://www.red-gate.com/library/sql-server-internals-in-memory-oltp
德米特里·科罗特克维奇: https ://www.apress.com/gp/book/9781484227718