{"id":2963,"date":"2012-11-08T09:00:00","date_gmt":"2012-11-08T17:00:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/dataplatforminsider\/2012\/11\/08\/breakthrough-performance-with-in-memory-technologies\/"},"modified":"2024-01-22T22:49:29","modified_gmt":"2024-01-23T06:49:29","slug":"breakthrough-performance-with-in-memory-technologies","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2012\/11\/08\/breakthrough-performance-with-in-memory-technologies\/","title":{"rendered":"Breakthrough performance with in-memory technologies"},"content":{"rendered":"
In a blog post earlier this year on \u201c<\/span>The coming database in-memory tipping point<\/span><\/a>\u201d, I mentioned that Microsoft was working on several in-memory database technologies. At the <\/span>SQL PASS conference<\/span><\/a> this week, Microsoft unveiled a new in-memory database capability, code named \u201cHekaton1<\/sup><\/span>\u201d, which is slated to be released with the next major version of SQL Server. Hekaton dramatically improves the throughput and latency of SQL Server\u2019s transaction processing (TP) capabilities. Hekaton is designed to meet the requirements of the most demanding TP applications and we have worked closely with a number of companies to prove these gains. Hekaton\u2019s technology adoption partners include financial services companies, online gaming and other companies which have extremely demanding TP requirements. What is most impressive about Hekaton is that it achieves breakthrough improvement in TP capabilities without requiring a separate data management product or a new programming model. It\u2019s still SQL Server!<\/span><\/p>\n As I mentioned in the \u201ctipping point\u201d post, much of the energy around in-memory data management systems thus far has been around columnar storage and analytical workloads. As the previous blog post mentions, Microsoft already ships this form of technology in our xVelocity analytics engine and xVelocity columnstore index. xVelocity columnstore index will be updated in SQL Server 2012 Parallel Data Warehouse (PDW v2) to support updatable clustered columnar indexes. Hekaton, in contrast, is a row-based technology squarely focused on transaction processing (TP) workloads. Note that these two approaches are not mutually exclusive. The combination of Hekaton and SQL Server\u2019s existing xVelocity columnstore index and xVelocity analytics engine, will result in a great combination. <\/span><\/p>\n The fact that Hekaton and xVelocity columnstore index are built-in to SQL Server, rather than a separate data engine, is a conscious design choice. Other vendors are either introducing separate in-memory optimized caches or building a unification layer over a set of technologies and introducing it as a completely new product. This adds complexity forcing customers to deploy and manage a completely new product or, worse yet, manage both a \u201cmemory-optimized\u201d product for the hot data and a \u201cstorage-optimized\u201d product for the application data that is not cost-effective to reside primarily in memory.<\/span><\/p>\n Hekaton is designed around four architectural principles:<\/span><\/p>\n 1) Optimize for main memory data access<\/strong><\/i>: Storage-optimized engines (such as the current OLTP engine in SQL Server today) will retain hot data in a main memory buffer pool based upon access frequency. The data access and modification capabilities, however, are built around the viewpoint that data may be paged in or paged out to disk at any point. This perspective necessitates layers of indirection in buffer pools, extra code for sophisticated storage allocation and defragmentation, and logging of every minute operation that could affect storage. With Hekaton you place tables used in the extreme TP portion of an application in memory-optimized main memory structures. The remaining application tables, such as reference data details or historical data, are left in traditional storage optimized structures. This approach lets you memory-optimize hotspots without having to manage multiple data engines.<\/span><\/p><\/blockquote>\n Hekaton\u2019s main memory structures do away with the overhead and indirection of the storage optimized view while still providing the full <\/span>ACID<\/span><\/a> properties expected of a database system. For example, durability in Hekaton is achieved by streamlined logging and checkpointing that uses only efficient sequential IO. <\/span><\/p><\/blockquote>\n 2) Accelerate business logic processing<\/em><\/strong>: Given that the free ride on CPU clock rate is over, Hekaton must be more efficient in how it utilizes each core. Today SQL Server\u2019s query processor compiles queries and stored procedures into a set of data structures which are evaluated by an interpreter in SQL Server\u2019s query processor. With Hekaton, queries and procedural logic in T-SQL stored procedures are compiled directly into machine code with aggressive optimizations applied at compilation time. This allows the stored procedure to be executed at the speed of native code. <\/span><\/p><\/blockquote>\n 3) Provide frictionless scale-up<\/strong><\/i>: It\u2019s common to find 16 to 32 logical cores even on a 2-socket server nowadays. Storage-optimized engines rely on a variety of mechanisms such as locks and latches to provide concurrency control. These mechanisms often have significant contention issues when scaling up with more cores. Hekaton implements a <\/span>highly scalable concurrency control mechanism<\/span><\/a> and uses a series of <\/span>lock-free data structures<\/span><\/a> to eliminate traditional locks and latches while guaranteeing the correct transactional semantics that ensure data consistency. <\/span><\/p><\/blockquote>\n 4) Built-in to SQL Server<\/i><\/b>: As I mentioned earlier \u2013 Hekaton is a new capability of SQL Server. This lays the foundation for a powerful customer scenario which has been proven out by our customer testing. Many existing TP systems have certain transactions or algorithms which benefit from Hekaton\u2019s extreme TP capabilities. For example, the matching algorithm in financial trading, resource assignment or scheduling in manufacturing, or matchmaking in gaming scenarios. Hekaton enables optimizing these aspects of a TP system for in-memory processing while the cooler data and processing continue to be handled by the rest of SQL Server. <\/span><\/p><\/blockquote>\n To make it easy to get started, we\u2019ve built an analysis tool that you can run so you can identify the hot tables and stored procedures in an existing transactional database application. As a first step you can migrate hot tables to Hekaton as in-memory tables. Doing this simply requires the following T-SQL statements<\/span>2<\/sup><\/span>:<\/span><\/p>\n