内存优化表-它们真的很难维护吗?


18

我正在研究从MS SQL 2012升级到2014的好处。SQL2014的最大卖点之一是内存优化表,该表显然使查询超快。

我发现在内存优化表上有一些限制,例如:

  • 没有(max)大小字段
  • 每行最大〜1KB
  • 没有timestamp领域
  • 没有计算列
  • UNIQUE约束

这些都是令人讨厌的东西,但是如果我真的想解决这些问题以获得性能上的好处,我可以制定一个计划。

真正的缺点是您不能运行一条ALTER TABLE语句,并且每次将一个字段添加到索引列表中时,都必须经过这个严格INCLUDE的规定。此外,似乎必须将用户拒之于系统之外,以便对实时DB上的MO表进行任何模式更改。

我发现这完全是令人发指的,以至于我实际上无法相信Microsoft可以在此功能上投入这么多的开发资金,而使它的维护非常不切实际。这使我得出一个结论,就是我一定弄错了方向。我一定对内存优化表有误解,这使我相信维护它们的难度要比实际困难得多。

那么,我误会了什么?您是否使用过MO表?是否有某种秘密的开关或过程使它们易于使用和维护?

Answers:


18

不,内存中的内存确实不够完善。如果您熟悉敏捷,您将了解“最小可运输产品”的概念;在内存中就是这样。我感觉到MS需要对SAP的Hana及其同类产品做出回应。这就是他们可以在2014年发行版的时间范围内对其进行调试的原因。

像其他任何东西一样,内存具有相关的成本和收益。主要优点是可以实现的吞吐量。正如您提到的,成本之一是变更管理的开销。在我看来,这并不是使它成为无用的产品,它只是减少了可以带来净收益的案例数量。正如列存储索引现在可以更新并且可以过滤索引一样,毫无疑问,内存功能将在以后的发行版中得到改进。


SQL Server 2016现在普遍可用。就像我想的那样,In-Memory OLTP获得了许多增强。大多数更改实现了传统表已经使用了一段时间的功能。我的猜测是,内存表和传统表将同时发布将来的功能。临时表就是一个很好的例子。内存表和基于磁盘的表均支持此版本中的新增功能。


14

新技术的问题之一-尤其是V1版本已被大声地公开,称其功能不完善-是每个人都跃跃欲试,并认为它非常适合每种工作负载。不是。Hekaton的优点是256 GB以下的OLTP工作负载,并在2-4个套接字上进行了很多点查找。这符合您的工作量吗?

许多限制与内存表和本机编译过程结合在一起。当然,您可以使用内存中的表而不是使用本机编译的过程,或者至少不是排他性的,来绕开其中的一些限制。

显然,您需要测试性能提升是否在您的环境中是可观的,如果是,则权衡是否值得。如果您从内存表中获得了可观的性能提升,我不确定为什么您担心要对INCLUDE列执行多少维护。根据定义,您的内存索引。这些仅应真正有助于避免在传统的非聚集索引的范围或完整扫描上进行查找,并且这些操作实际上不应该在内存表中进行(同样,您应该分析工作负载并查看哪些操作可以改进)而不是-并非双赢)。您今天多久使用一次索引中的INCLUDE列?

基本上,如果以V1形式对您来说还不值得,请不要使用它。这不是我们能回答你一个问题,只是告诉你,很多客户愿意住与局限,以及正在使用的功能来获取巨大利益,尽管他们。

SQL Server 2016

如果您正在迈向SQL Server 2016,我已经在博客中介绍了您将在内存中OLTP中看到的增强功能以​​及一些限制的消除。最为显着地:

  • 增加的最大耐用表大小:256 GB => 2 TB
  • LOB / MAX列,可为空的列上的索引,删除BIN2排序规则要求
  • 修改和重新编译程序
  • 对ALTER TABLE的一些支持-它会脱机,但是您应该能够更改和/或删除/重新创建索引(但是,当前的CTP版本似乎不支持此功能,因此请不要以此作为保证)
  • DML触发器,FK /检查约束,MARS
  • 或(不)存在,存在,不同,联合,外部联接
  • 并行性

我使用“ include”列作为我可能必须进行的微小更改的示例,但是现在我已经从您那里了解到这不是一个很好的示例。更相关的是,例如,添加新的可为空的列,这在常规表中是非常无中断的操作,但是对于MO表而言将非常繁重。由于我们正在使用的系统正在不断扩展(我们的功能请求与错误报告在数量上处于竞争状态),因此这可能成为我们的杀手kill。
Shaul Behr 2014年

3
@shaul好的,所以不要使用它。或者只将稳定的表放在内存中。或者考虑在不断添加列(EAV)的其他设计。实际上,我认为您只是在抱怨这项技术不适合您。我有孩子,所以我没有抱怨保时捷Cayman S对我不实用-或至少不是作为日常驾驶员。也许我可以在周末使用它(就像也许可以对部分模式使用内存中的OLTP,但并非全部使用)。您的要求不是很常见,并且与V1功能冲突,这并不是Microsoft的错。
亚伦·伯特兰

亚伦,什么是EAV?
Shaul Behr 2014年


2

无法在Sql Server Management Studio中右键单击内存优化表来调出设计器并添加新列。您也不能在表名中单击作为重命名表的方法。(在撰写本文时为SQL2014。)

相反,您可以右键单击表,然后将create命令脚本编写为新的查询窗口。可以通过添加任何新列来修改此create命令。

因此,要修改表,可以将数据存储在新表,临时表或表变量中。然后,您可以删除并使用新模式重新创建表,最后复制回实际数据。对于大多数使用情况,此3容器外壳游戏的便利性仅差一点。

但是,如果没有要解决的性能问题,则没有理由去使用“内存优化”表。

然后,您必须权衡这些限制和变通方法是否适合您的用例。您有性能问题吗?你有尝试过其他吗?这会提高您的性能10到100倍吗?使用或不使用它可能最终都会使您不费吹灰之力。


-2

您可以在操作服务器中使用内存中OLTP,而不会出现任何重大问题。我们在银行和支付公司中使用了这项技术,

通常,当工作负载过高时,我们可以使用内存优化表。通过使用内存中OLTP,您可以将性能提高到30倍!Microsoft更正了SQL Server 2016和2017中的大多数限制。与基于磁盘的表相比,内存优化表的架构完全不同。

内存优化表有两种类型。耐用桌和非耐用桌。持久表和非持久表将表数据保留在内存中。此外,持久性表将数据保留在磁盘上以用于恢复数据和架构。在大多数操作方案中,我们应该使用持久性表,因为在这里数据丢失至关重要。在某些情况下,例如ETL加载和缓存,我们可以使用非持久表。

您可以使用此电子书并学习如何使用此技术:

卡伦·德莱尼(Kalen Delaney):https ://www.red-gate.com/library/sql-server-internals-in-memory-oltp

德米特里·科罗特凯维奇(Dmitri Korotkevitch):https ://www.apress.com/gp/book/9781484227718

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.