Microsoft SQL Server 14 man: 'Nothing stops a Hekaton transaction'
In-memory tables and native code stored procedures on the way
TechEd Microsoft’s SQL Server 14 will include a new memory optimisation feature code-named Hekaton, with the potential for huge performance gains – provided your data fits in RAM.
Hekaton is not a separate product, but will be part of enterprise editions of SQL Server 14, for which no availability date has been announced. The latest update of Microsoft's database manager was presented as part of the 2012 R2 wave of server products, which includes Windows Server 2012 R2 and System Center 2012 R2.
The way Hekaton works is that you declare a table as memory-optimised, following which SQL Server will load the entire table into memory. In addition, stored procedures can be compiled to native DLLs for fast access.
Resultant speed increases can be stunning. At a press preview last month, SQL Server program manager Kevin Farlee gave a demo using a 2-socket, 16-core server with 256GB RAM and 2 SSDs alongside hard drives. Carrying out intensive transactions simulating 80 users, the demo yielded 2,400 transactions per second. Enabling memory-optimised tables increased this to 17,000. Compiling stored procedures to native code upped performance further: to 65,000 transactions per second.
SQL Server Hekaton’s remarkable performance boost
Since both SQL Server and Windows cache data in memory, why does Hekaton provide such a performance boost?
“The reason that Hekaton is that we use memory structures that are much more efficient,” said Farlee.
Hekaton: How it works
Most of today’s database managers are built on the assumption that data lives on a disk, with little bits of data at a time loaded into memory for manipulation. “There’s a whole lot of infrastructure involved in paging those subsets of data in and out," Farlee explained. "There’s software to manage what’s in memory, and where on disk this piece of memory relates to, and in Hekaton we don’t need any of it. We don’t use pages. When you look up an index it’s just a memory pointer to your data, as opposed to traversing a B-tree."
Transactions in Hekaton are designed so that they always complete, says the SQL Server man. “When you amend a row in Hekaton, you create a new version in memory. When no transactions need to reference the old version, we reclaim the memory. Nothing can stop a Hekaton transaction,” Farlee said.
If the transaction fails to commit, the changes are never written to disk. When a transaction does commit, it gets logged in the transaction log and a background process copies it back to the set of sequential files that persist Hekaton data. These files are only read at database start-up, when they get copied into memory.
An analysis tool called AMAR (Analyse Migrate and Report) will assist database administrators in working out which tables will benefit from memory optimisation.
The obvious limitation of Hekaton is that the data has to fit in RAM. “If the data becomes too large, we stop inserting rows,” Farlee said. There is no failover back to disk-based tables.
There are also some code compatibility issues with compiling stored procedures, which means existing code is likely to need modification, though Microsoft is aiming to reduce or eliminate this eventually. Microsoft also showed improved high availability features in SQL Server 14. There is support for high availability groups using Server 2012 Cluster Shared Volumes, and the maximum number of secondary databases – for failover and read-only performance boost – is doubled: from four to eight. The team have also made tweaks to how online indexes are rebuilt which will reduce the need to take a database offline for maintenance.
Azure integration means that you will be able to backup SQL Server databases to Windows Azure blob storage using PowerShell or smart agents. You can also maintain a standby replica in Azure of your on-premise database. ®
Sponsored: Are DLP and DTP still an issue?