آشنایی با تکنولوژی In-Memory OLTP

مقدمه تکنولوژی In-Memory OLTP

In-Memory OLTPکه با نام Hekaton یا In-Memory Optimization هم معرفی می‌شود. آخرین تکنولوژی پردازش حافظه‌ای مایکروسافت است. همانطور که از نام In-Memory OLTP پیداست این تکنولوژی برای استفاده در سیستم‌های تراکنش برخط یا OLTP به وجود آمده است. In-Memory OLTP کاملا با موتور SQL Server تجمیع شده است، به عبارت دیگر می‌تواند همانند سایر کامپوننت‌های SQL Server Database Engine به کار گرفته شود.
این تکنولوژی در SQL Server 2014 با دو ویژگی اصلی جداول Memory-Optimized و پروسیجرهای Natively-Compile معرفی شد که در ادامه به بررسی بیشتر این ویژگی‌ها می‌پردازیم.

جداول Memory-Optimized

جداول Memory-Optimized جداولی هستند که دیتای خود را در حافظه ذخیره می‌کنند. این ویژگی با حذف Lock و Latch منجر به افزایش عملکرد و کارایی این نوع جداول شده است. دیتا در این نوع جداول از حافظه خوانده می‌شوند و در حافظه نوشته می‌شوند، یعنی کاملا در حافظه مقیم هستند. همچنین می‌توان از این جداول در کنار جداول Disk-Based استفاده کرد.

پروسیجر Natively-Compile

پروسیجر Natively-Compile پروسیجری است که تنها می‎تواند به ساختارهای Memory-Optimized مانند جداول Memory-Optimized دسترسی داشته باشد. این نوع از پروسیجرها به کد ماشین کامپایل می‌شوند و در حافظه بارگذاری می‌شوند تا در فرآیند حافظه‌ای SQL Server مورد استفاده قرار گیرند. به همین دلیل بسیار سریعتر و کاراتر از پروسیجرهای معمولی هستند. همچنین این پروسیجرها دستورات محدودی از TSQL را پشتیبانی می‌کنند.
برای استفاده از ویژگی‌های Memory-Optimized باید یک FileGroup از نوع MEMORY_OPTIMIZED_DATA برای دیتابیس ایجاد کنیم.

USE master
GO
CREATE DATABASE InMemoryDbDemo ON PRIMARY
( NAME = N'InMemoryDbDemo', FILENAME = N'D:\Databases\InMemoryDbDemo.mdf',SIZE = 4096KB , FILEGROWTH = 1024KB )
LOG ON
(NAME = N'InMemoryDbDemo_log',FILENAME = N'D:\Databases\InMemoryDbDemo_log.ldf'
,SIZE = 2048KB , FILEGROWTH = 10%)
GO
ALTER DATABASE InMemoryDbDemo ADD FILEGROUP InMemoryDbDemo_FG CONTAINS MEMORY_OPTIMIZED_DATA
ALTER DATABASE InMemoryDbDemo ADD FILE (name='InMemoryDbDemoDF', filename='D:\Databases\InMemoryDbDemo')
TO FILEGROUP InMemoryDbDemo_FG
ALTER DATABASE InMemoryDbDemo SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON
GO

ساخت جداول Memory-Optimized با دو حالت durable و non-durable قابل تعریف است. حالت پیش‌فرض Durable است به این معنی که اگر سرور Carsh کند یا Failover شود، دیتای جدول از فایل لاگ قابل بازیابی است. و اگر به صورت Non-Durable تعریف شود در صورت اختلال در سرور دیتای این جداول قابل بازیابی نیست.
انتخاب تعریف جداول Memory-Optimized به صورتDurable و Non-Durable وابسته به نیازمندی‌های کسب و کار است. به طور مثال اگر بخواهید جداول Memory-Optimized را به عنوان بخشی از پردازش موقت انبار داده استفاده کنید که دیتای آن بارها با میلیون‌ها رکورد حذف و اضافه می‌شود و نتایج پردازش آن به جداول دیگر انتقال می‌یابد تعریف جدول Memory-Optimized به صورت Non-Durable گزینه مناسبی است.

USE InMemoryDbDemo
GO
CREATE TABLE dbo.Product
(
ID INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000),
Code VARCHAR(10) NOT NULL,
Description VARCHAR(200) NOT NULL,
Price FLOAT NOT NULL
)WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY);
GO

ویژگی “SCHEMA_ONLY” به این معنی است که تنها اسکیمای جدول در صورت اختلال سرور قابل بازیابی است. اگر بخواهیم جدول را به صورت Durable تعریف کنیم. باید از “SCHEMA_AND_DATA” استفاده کنیم.

USE InMemoryDbDemo
GO
CREATE TABLE dbo.Product
(
ID INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000),
Code VARCHAR(10) NOT NULL,
Description VARCHAR(200) NOT NULL,
Price FLOAT NOT NULL
)WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);
GO

همانطور که در تعریف جداول Memory-Optimized مشاهده کردید. ایندکس باید به صورت Non-Clustered تعریف شود. در واقع در جداول Memory-Optimized امکان تعریف ایندکس به صورت Clustered وجود ندارد. در تعریف ایندکس لازم است که مقدار BUCKET_COUNT تعیین شود. مقدار پیشنهادی برای BUCKET_COUNT بین ۱.۵ تا ۲ برابر تعداد مقادیر یکتای ستون ایندکس است.
پروسیجرهای Natively-compiled می‌توانند جداول Memory-Optimized را با استفاده از دستورات T-SQL مانند Subquery ها، توابع عددی و … به کار گیرند. بر اساس مثال قبلی پروسیجر زیر ستون Price در جدول Product را بروزرسانی می‌کند.

USE InMemoryDbDemo
GO
CREATE PROC dbo.sp_ProductUpdate
WITH NATIVE_COMPILATION,
SCHEMABINDING,
EXECUTE AS OWNER
AS
BEGIN ATOMIC WITH ( TRANSACTION ISOLATION LEVEL = SNAPSHOT,
LANGUAGE = N'us_english' )
UPDATE dbo.Product
SET Price = Price - ( Price * 0.10 );
END;

در تعریف پروسیجرهای Natively-compiled باید موارد زیر را در نظر بگیرید

• عبارت WITH NATIVE_COMPILATIONباید استفاده شود
• عبارت SCHMABINDING لازم است زیرا اسکیمای جداولی که در آن مورد استفاده قرار می‌گیرد مشخص می‌شود.
• عبارت BEGIN_ATOMIC مورد استفاده قرار می‌گیرد یعنی همه دستورات درون پروسیجر اجرا می‌شوند یا هیچکدام از آن‌ها اجرا نمی‌شود.

محدودیت‌های تکنولوژی In-Memory OLTP

تکنولوژی In-Memory OLTP در زمان ارایه در نسخه SQL Server 2014 محدودیت‌های زیادی به همراه داشت. برخی از این محدودیت‌ها به شرح زیر است.

• عدم امکان تعریف ایندکس بر روی ستون‌های nullable
• عدم امکان استفاده از دستورات OUTER JOIN UNION, UNION ALL, DISTINCT,
• حداکثر استفاده از حافظه RAM تا 256GB
• عدم امکان تغییر (ALTER) جداول Memory-Optimized بعد از ایجاد جدول

بسیاری از این محدودیت‌ها در نسخهSQL Server 2016 به بعد برداشته شده‌اند. به طور مثال حداکثر فضای استفاده از RAM در این جداول 2TB شده است یا امکان تغییر جدول بعد از ایجاد آن فراهم شده است.