Memory-Optimized Tables

پس از بحث فشرده‌سازی، فصل به In-Memory OLTP می‌رسد. جدول حافظه‌محور برای کاهش I/O و همچنین کاهش سربار CPU و Lock/Latch طراحی شده است. این ساختار برای همه workloadها مناسب نیست؛ افزایش مصرف حافظه، محدودیت‌های ویژگی و الگوی دسترسی باید پیش از مهاجرت ارزیابی شود. پارتیشن‌های Heap جدید نیز در برخی Bulk Insertهای دارای TABLOCK می‌توانند فشرده شوند.

Durability و پیش‌نیاز Filegroup

Memory-Optimized Table می‌تواند SCHEMA_AND_DATA باشد تا هم Schema و هم داده دوام داشته باشد، یا SCHEMA_ONLY باشد که پس از Restart فقط ساختار باقی می‌ماند. پیش از ساخت جدول باید Memory-Optimized Filegroup و Container متناظر ایجاد شود. انتخاب SCHEMA_ONLY برای داده موقت می‌تواند ثبت Log و I/O را کاهش دهد، اما از دست رفتن داده پس از Restart باید قابل قبول باشد.

ایجاد جدول حافظه‌محور

جدول‌های Memory-Optimized با CREATE TABLE ساخته می‌شوند و باید دست‌کم یک Index داشته باشند. Hash Index برای جست‌وجوی برابری مناسب است و تعداد Bucketها هنگام طراحی اهمیت دارد؛ Nonclustered Index ساختار Range-friendly‌تری دارد.

CREATE TABLE dbo.OrdersMem
(
  OrderNumber int IDENTITY(1,1) NOT NULL
      PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000000),
  OrderDate date NOT NULL,
  CustomerID int NOT NULL,
  ProductID int NOT NULL,
  Quantity int NOT NULL,
  NetAmount money NOT NULL,
  TaxAmount money NOT NULL,
  InvoiceAddressID int NOT NULL,
  DeliveryAddressID int NOT NULL,
  DeliveryDate date NULL
)
WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);

داده آزمایشی با CTE و مقادیر تصادفی به OrdersMem درج می‌شود. در Memory-Optimized Table تخصیص داده و مدیریت نسخه‌های رکورد با سازوکار In-Memory OLTP انجام می‌شود و ساختار صفحه‌ای سنتی Buffer Pool در مسیر اصلی دسترسی وجود ندارد.

Performance Profile

برای مقایسه، کتاب یک جدول Disk-Based با Schema مشابه می‌سازد و داده مشابه در آن قرار می‌دهد. Benchmarkها روی یک VM مشخص اجرا شده‌اند و اعداد مطلق به سخت‌افزار وابسته‌اند؛ هدف مشاهده تفاوت الگوی I/O و CPU است، نه ارائه یک نسبت ثابت برای همه سیستم‌ها.

آزمایش SELECT * پس از پاک‌کردن Plan Cache و Clean Bufferها اجرا می‌شود تا اثر خواندن فیزیکی روی جدول Disk-Based روشن‌تر شود. Memory-Optimized Table از ساختارهای حافظه‌ای خودش استفاده می‌کند و رفتار آن با DBCC DROPCLEANBUFFERS مانند Rowstore سنتی نیست.

SET STATISTICS TIME ON;
DBCC FREEPROCCACHE;
DBCC DROPCLEANBUFFERS;
SELECT * FROM dbo.OrdersMem;
SELECT * FROM dbo.OrdersDisc;

آزمایش COUNT(*) نیز برای هر دو ساختار اجرا می‌شود. نتایج نمونه کتاب مزیت چشمگیر Memory-Optimized را در برخی اسکن‌ها نشان می‌دهد، اما نویسنده تأکید می‌کند نتیجه به سیستم و workload وابسته است و باید روی محیط واقعی خودتان Benchmark کنید.

آزمایش SUM با فیلتر روی کلید، اهمیت طراحی Index را نشان می‌دهد. اگر Query با Hash/Nonclustered Index مناسب همسو باشد، جدول حافظه‌محور می‌تواند بسیار سریع باشد؛ در غیر این صورت یک جدول Disk-Based با ایندکس مناسب ممکن است رقابت نزدیک یا حتی عملکرد بهتری داشته باشد. نتیجه اصلی این است که In-Memory جای طراحی Index را نمی‌گیرد.

Table Memory Optimization Advisor

SSMS ابزاری برای بررسی امکان مهاجرت جدول Disk-Based به Memory-Optimized ارائه می‌دهد. Advisor ناسازگاری ویژگی‌ها و انواع داده را گزارش می‌کند، نوع Durability را می‌پرسد و برای Primary Key/Index پیشنهادهایی ارائه می‌کند. پیش از اجرای مهاجرت، هشدارها باید برطرف شوند و تأثیر روی عملیات‌هایی مانند TRUNCATE TABLE و Constraintهای پشتیبانی‌نشده بررسی شود.

Natively Compiled Objects

In-Memory OLTP می‌تواند Table و Stored Procedure را به کد Native تبدیل کند. در نسخه‌های جدید دامنه قابلیت‌های پشتیبانی‌شده افزایش یافته، اما هنوز باید محدودیت‌های Syntax و عملیات سازگار بررسی شوند. Native Compilation بخش‌هایی از سربار Interpreter/Query Execution سنتی را کاهش می‌دهد.

DLLهای Native برای جدول‌ها

SQL Server برای Objectهای Natively Compiled فایل‌های DLL تولید و مدیریت می‌کند. Metadata سیستم اجازه می‌دهد ارتباط DLL و جدول Memory-Optimized مشاهده شود. این فایل‌ها بخشی از پیاده‌سازی داخلی‌اند و SQL Server چرخه عمر آن‌ها را کنترل می‌کند؛ حذف دستی آن‌ها صحیح نیست.

Natively Compiled Stored Procedure

CREATE PROCEDURE UpdateOrdersMem
    @OrderNumber int,
    @DeliveryDate date
WITH NATIVE_COMPILATION, SCHEMABINDING
AS
BEGIN ATOMIC
WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'us_english')
    UPDATE dbo.OrdersMem
    SET DeliveryDate = @DeliveryDate
    WHERE OrderNumber = @OrderNumber;
END;

Stored Procedure Native باید SCHEMABINDING و بلوک ATOMIC داشته باشد و سطح Isolation/Language در تعریف مشخص شود. Metadata مشابهی برای مشاهده DLLهای Procedureهای Native وجود دارد.

جمع‌بندی

پارتیشن‌بندی، Compression و In-Memory OLTP هرکدام مسئله متفاوتی را حل می‌کنند: Sliding Window و مدیریت حجم، کاهش I/O و Footprint، و کاهش Latency/Locking. انتخاب صحیح نیازمند شناخت workload، اندازه‌گیری و آزمون است. Memory-Optimized Table در سناریو مناسب می‌تواند کارایی بسیار بالایی ایجاد کند، اما بدون Index مناسب یا با محدودیت‌های ناسازگار، گزینه خودکار و همیشگی نیست.