Data Compression در SQL Server آیا همیشه باعث افزایش Performance می‌شود؟

با افزایش حجم داده‌ها در سازمان‌ها، مدیریت فضای ذخیره‌سازی و حفظ عملکرد پایگاه داده به یکی از مهم‌ترین چالش‌های مدیران SQL Server تبدیل شده است. رشد سریع اطلاعات، افزایش تعداد تراکنش‌ها و توسعه سامانه‌های تحلیلی باعث می‌شود حجم دیتابیس در مدت کوتاهی چندین برابر شود. در چنین شرایطی، تنها افزایش ظرفیت ذخیره‌سازی راهکار مناسبی نیست، زیرا علاوه بر هزینه‌های سخت‌افزاری، عملیات Backup، Restore، نگهداری و حتی اجرای Queryها نیز تحت تأثیر قرار می‌گیرند.
یکی از قابلیت‌های ارزشمند SQL Server برای مقابله با این چالش، Data Compression یا فشرده‌سازی داده‌ها است. این قابلیت بدون تغییر در منطق برنامه یا ساختار داده‌ها، حجم اطلاعات ذخیره‌شده را کاهش می‌دهد و در بسیاری از سناریوها باعث بهبود عملکرد سیستم نیز می‌شود.

Data Compression در SQL Server چیست؟

Data Compression یکی از قابلیت‌های داخلی SQL Server است که با هدف کاهش حجم فیزیکی داده‌های ذخیره‌شده روی دیسک طراحی شده است. برخلاف تصور بسیاری از کاربران، این قابلیت داده‌ها را به فایل‌های فشرده مانند ZIP یا RAR تبدیل نمی‌کند، بلکه نحوه ذخیره‌سازی اطلاعات در صفحات داده (Data Pages) را بهینه می‌کند تا بتوان داده‌های بیشتری را در هر صفحه ۸ کیلوبایتی SQL Server جای داد.

از آنجا که SQL Server تمام داده‌ها را در قالب صفحاتی با اندازه ثابت ۸ کیلوبایت ذخیره می‌کند، هرچه اطلاعات بیشتری در یک صفحه قرار بگیرد، تعداد صفحات موردنیاز برای ذخیره جدول یا ایندکس کاهش پیدا می‌کند. این موضوع مستقیماً بر میزان فضای اشغال‌شده، تعداد عملیات خواندن و نوشتن روی دیسک (Disk I/O)، مدت زمان Backup و Restore و حتی سرعت اجرای بسیاری از Queryها تأثیر می‌گذارد.

نکته

این که Data Compression یک قابلیت ذخیره‌سازی (Storage Optimization) است، نه یک قابلیت افزایش مستقیم Performance. بهبود عملکرد زمانی اتفاق می‌افتد که کاهش حجم داده‌ها باعث شود SQL Server برای پاسخ به یک Query، صفحات کمتری را از دیسک یا حافظه بخواند. در مقابل، برای باز کردن داده‌های فشرده‌شده نیاز به پردازش بیشتری توسط CPU وجود دارد. به همین دلیل، فعال‌سازی Compression همیشه به معنای افزایش سرعت نیست و نتیجه نهایی به نوع بار کاری (Workload) بستگی دارد.

به بیان ساده، SQL Server در زمان ذخیره داده‌ها تلاش می‌کند اطلاعات را با روشی هوشمندانه‌تر در صفحات قرار دهد و هنگام خواندن نیز در صورت نیاز آن‌ها را به‌صورت خودکار بازیابی کند. این فرآیند برای برنامه‌های کاربردی کاملاً شفاف است و هیچ تغییری در دستورات SELECT، INSERT، UPDATE یا DELETE ایجاد نمی‌کند. بنابراین، فعال‌سازی Data Compression معمولاً بدون نیاز به تغییر در کد نرم‌افزار یا ساختار جداول انجام می‌شود.

یکی از مزایای مهم این قابلیت، امکان اعمال آن در سطوح مختلف است. مدیر پایگاه داده می‌تواند بسته به نیاز، فشرده‌سازی را روی یک Table، یک Index، یک Partition یا حتی هر Partition با تنظیمات متفاوت اعمال کند. این انعطاف‌پذیری باعث می‌شود بتوان برای هر بخش از پایگاه داده، مناسب‌ترین نوع Compression را انتخاب کرد و تعادل بهتری میان مصرف فضای ذخیره‌سازی، توان پردازشی و عملکرد سیستم برقرار نمود.

Data Compression در چه سطوحی قابل اعمال است؟

• Table (Heap)

• Clustered Index

• Nonclustered Index

• Partition

• هر Partition به صورت مستقل

این انعطاف‌پذیری به مدیر پایگاه داده اجازه می‌دهد تنها بخش‌هایی از داده را که بیشترین سود را از Compression می‌برند فشرده کند. برای مثال، در یک جدول Partition شده می‌توان داده‌های سال جاری را بدون Compression نگهداری کرد و Partitionهای مربوط به سال‌های گذشته را با Page Compression ذخیره نمود تا ضمن کاهش مصرف Storage، سربار پردازشی روی تراکنش‌های جاری نیز افزایش پیدا نکند.

نسخه‌های پشتیبانی‌شده

Data Compression نخستین بار در SQL Server 2008 معرفی شد. تا قبل از SQL Server 2016 SP1 استفاده از این قابلیت عمدتاً به Enterprise Edition محدود بود، اما از SQL Server 2016 Service Pack 1 به بعد، Row Compression و Page Compression در نسخه Standard نیز در دسترس قرار گرفتند. به همین دلیل، امروزه تقریباً تمام سازمان‌ها بدون نیاز به Enterprise Edition می‌توانند از این قابلیت برای کاهش فضای ذخیره‌سازی و بهبود عملکرد استفاده کنند.

Data Compression چگونه عملکرد SQL Server را بهبود می‌دهد؟

برخلاف تصور بسیاری از مدیران پایگاه داده، هدف Data Compression فقط صرفه‌جویی در فضای دیسک نیست. کاهش حجم صفحات داده باعث می‌شود تعداد کمتری Page از دیسک خوانده شود، حجم داده منتقل‌شده در Buffer Pool کاهش پیدا کند و عملیات I/O سریع‌تر انجام شود. از آنجا که در بسیاری از سیستم‌های OLTP و Data Warehouse، گلوگاه اصلی عملکرد دیسک و زیرسیستم ذخیره‌سازی است، کاهش عملیات I/O می‌تواند تأثیر قابل توجهی بر سرعت اجرای Queryها داشته باشد.

البته این مزایا بدون هزینه نیست. فرآیند فشرده‌سازی و بازگشایی داده‌ها به توان پردازشی بیشتری نیاز دارد و به همین دلیل انتخاب نوع مناسب Compression باید بر اساس الگوی بار کاری، حجم داده و منابع سخت‌افزاری انجام شود.

Data Compression کاهش I/O در برابر افزایش مصرف CPU

یکی از مهم‌ترین نکاتی که هنگام استفاده از Data Compression باید در نظر گرفت، تعادل میان مصرف CPU و عملیات I/O است. SQL Server برای خواندن داده‌های فشرده‌شده ابتدا آن‌ها را Decompress می‌کند، بنابراین هر بار خواندن یا تغییر داده نیازمند پردازش بیشتری توسط پردازنده است. در مقابل، به دلیل کاهش تعداد صفحات (Page) موردنیاز، حجم عملیات خواندن از دیسک و حافظه کاهش پیدا می‌کند. به همین دلیل نمی‌توان SQL Server را صرفاً یک سیستم CPU-Oriented یا Memory-Oriented دانست. عملکرد این موتور پایگاه داده وابسته به نوع Workload است. در محیط‌هایی که محدودیت اصلی Storage و Disk I/O است، Data Compression معمولاً باعث افزایش Performance می‌شود، اما در Workloadهایی که CPU از قبل تحت بار سنگین قرار دارد، ممکن است افزایش مصرف پردازنده بخشی از این مزیت را کاهش دهد. بنابراین تصمیم‌گیری درباره فعال‌سازی Compression باید همواره بر اساس تحلیل منابع CPU، Memory و I/O انجام شود.

SQL Server داده‌ها را چگونه فشرده می‌کند؟

برای درک صحیح Data Compression ابتدا باید بدانیم SQL Server داده‌ها را چگونه ذخیره می‌کند. تمام اطلاعات جداول و ایندکس‌ها در صفحاتی (Page) با اندازه ثابت ۸ کیلوبایت ذخیره می‌شوند. هر صفحه می‌تواند شامل چندین ردیف (Row) باشد و هرچه تعداد ردیف‌های بیشتری در یک صفحه قرار گیرد، تعداد صفحات موردنیاز برای ذخیره اطلاعات کاهش پیدا می‌کند.

در حالت عادی، SQL Server برای هر ردیف علاوه بر داده‌های اصلی، اطلاعاتی مانند Record Header، Null Bitmap، Fixed-Length Columns و Variable-Length Columns را نیز ذخیره می‌کند. همچنین بسیاری از انواع داده، فضای بیشتری از مقدار واقعی خود اشغال می‌کنند. برای مثال، اگر یک ستون از نوع BIGINT تنها مقدار 5 را نگهداری کند، باز هم ۸ بایت فضا به آن اختصاص داده می‌شود.

Data Compression دقیقاً در همین نقطه وارد عمل می‌شود. این قابلیت بدون تغییر در محتوای داده‌ها، روش ذخیره‌سازی آن‌ها را بهینه می‌کند تا فضای کمتری اشغال شود. در نتیجه، تعداد بیشتری از ردیف‌ها در هر صفحه جای می‌گیرند و SQL Server برای خواندن همان حجم اطلاعات، به صفحات کمتری مراجعه خواهد کرد.

کاهش تعداد صفحات، مزایای متعددی به همراه دارد:

• کاهش حجم فایل‌های Data
• کاهش عملیات خواندن و نوشتن روی دیسک (Disk I/O)
• افزایش تعداد صفحات قابل نگهداری در Buffer Pool
• کاهش زمان Backup و Restore
• بهبود عملکرد بسیاری از Queryهای مبتنی بر Read

البته این مزایا بدون هزینه نیستند. هر زمان که SQL Server داده‌ای را از صفحات فشرده‌شده می‌خواند یا در آن‌ها تغییر ایجاد می‌کند، باید عملیات Compression یا Decompression را نیز انجام دهد. این عملیات باعث افزایش مصرف CPU می‌شود. به همین دلیل، مهم‌ترین پرسش یک DBA این نیست که «Compression چقدر فضا ذخیره می‌کند؟» بلکه این است که «آیا کاهش I/O ارزش افزایش مصرف CPU را دارد؟»

پاسخ این سؤال به نوع Workload بستگی دارد. در سیستم‌های تحلیلی (OLAP و Data Warehouse) که حجم عملیات خواندن بسیار بیشتر از نوشتن است، Data Compression معمولاً یکی از مؤثرترین روش‌های افزایش Performance محسوب می‌شود. اما در برخی سیستم‌های پرتراکنش (OLTP) با تعداد زیاد عملیات INSERT، UPDATE و DELETE، افزایش سربار پردازشی ممکن است بخشی از مزایای حاصل از کاهش I/O را خنثی کند.

به همین دلیل، SQL Server دو روش متفاوت برای فشرده‌سازی داده‌ها ارائه کرده است: Row Compression و Page Compression. هرکدام از این روش‌ها مکانیزم، میزان صرفه‌جویی و سربار پردازشی متفاوتی دارند که در ادامه آن‌ها را به‌صورت دقیق بررسی خواهیم کرد.

نقش Buffer Pool در افزایش کارایی Data Compression

کاهش اندازه صفحات داده تنها باعث کوچک‌تر شدن فایل‌های دیتابیس نمی‌شود. از آنجا که SQL Server داده‌ها را پس از خواندن در Buffer Pool نگهداری می‌کند، کوچک‌تر شدن صفحات یا افزایش تعداد رکوردهای قابل ذخیره در هر Page باعث می‌شود اطلاعات بیشتری در همان میزان حافظه Cache شوند. در نتیجه احتمال خواندن مجدد داده‌ها از حافظه به جای دیسک افزایش یافته و میزان Physical Read کاهش پیدا می‌کند. به همین دلیل در بسیاری از Workloadهای مبتنی بر خواندن اطلاعات، Data Compression علاوه بر کاهش فضای ذخیره‌سازی، موجب استفاده بهینه‌تر از حافظه نیز می‌شود.

افزایش Page Density

یکی از اثرات کمتر شناخته‌شده Data Compression افزایش Page Density است. با کوچک‌تر شدن هر ردیف، تعداد بیشتری رکورد در هر صفحه ۸ کیلوبایتی قرار می‌گیرد. افزایش تراکم صفحات باعث می‌شود تعداد Pageهای موردنیاز برای اجرای Query کاهش یابد و SQL Server بتواند داده‌های بیشتری را در Buffer Pool نگهداری کند. در بسیاری از Workloadهای مبتنی بر خواندن اطلاعات، همین موضوع نقش مهمی در کاهش Physical Read و افزایش کارایی Cache ایفا می‌کند.

Row Compression چیست و چگونه کار می‌کند؟

Row Compression اولین سطح فشرده‌سازی در SQL Server است و همان‌طور که از نام آن مشخص است، در سطح هر ردیف (Row) عمل می‌کند. هدف این روش کاهش فضای اشغال‌شده توسط هر رکورد است، بدون آنکه ساختار منطقی جدول یا نوع داده‌ها تغییر کند.

در حالت عادی، بسیاری از انواع داده در SQL Server همواره با اندازه ثابتی ذخیره می‌شوند حتی اگر مقدار واقعی آن‌ها بسیار کوچک‌تر باشد. برای مثال، ستون از نوع BIGINT همیشه ۸ بایت فضا اشغال می‌کند، حتی اگر مقدار آن تنها 1 یا 100 باشد. Row Compression این رفتار را تغییر می‌دهد و مقادیر عددی را متناسب با مقدار واقعی آن‌ها ذخیره می‌کند.

به‌عنوان نمونه:

نوع داده	مقدار	بدون Compression	با Row Compression
BIGINT	5	8 Bytes	1 Byte
INT	100	4 Bytes	1 Byte
SMALLINT	250	2 Bytes	2 Bytes

علاوه بر داده‌های عددی، Row Compression فضای ذخیره‌سازی ستون‌های با طول متغیر مانند VARCHAR و NVARCHAR را نیز بهینه می‌کند و بخشی از سربار مربوط به متادیتای داخلی هر ردیف را کاهش می‌دهد. نتیجه این تغییرات آن است که تعداد بیشتری از رکوردها در هر صفحه ۸ کیلوبایتی قرار می‌گیرند و SQL Server برای خواندن همان حجم اطلاعات به صفحات کمتری مراجعه می‌کند.

یکی از ویژگی‌های مهم Row Compression این است که سربار پردازشی (CPU Overhead) آن نسبتاً کم است. به همین دلیل، در بسیاری از سیستم‌های OLTP که عملیات INSERT، UPDATE و DELETE به‌صورت مداوم انجام می‌شوند، این روش انتخاب مناسب‌تری نسبت به Page Compression محسوب می‌شود.

با این حال، میزان صرفه‌جویی در فضای ذخیره‌سازی معمولاً محدودتر است. در بسیاری از پایگاه‌های داده، Row Compression بین ۱۰ تا ۳۰ درصد کاهش حجم ایجاد می‌کند، اگرچه این مقدار کاملاً به نوع داده‌ها و ساختار جدول بستگی دارد.

Row Compression چه زمانی انتخاب بهتری است؟

• جدول حجم بالایی از عملیات تراکنشی دارد.
• مصرف CPU باید در سطح پایینی باقی بماند.
• هدف اصلی، کاهش Disk I/O بدون افزایش قابل توجه سربار پردازشی است.
• داده‌ها الگوهای تکراری زیادی ندارند و Page Compression مزیت چشمگیری ایجاد نمی‌کند.

در مقابل، اگر داده‌ها دارای مقادیر تکراری فراوان باشند، SQL Server می‌تواند با استفاده از Page Compression صرفه‌جویی بسیار بیشتری در فضای ذخیره‌سازی ایجاد کند روشی که علاوه بر فشرده‌سازی هر ردیف، شباهت‌های موجود بین تمام ردیف‌های یک صفحه را نیز شناسایی و حذف می‌کند.

Page Compression چیست و چرا از Row Compression قدرتمندتر است؟

Page Compression پیشرفته‌ترین روش فشرده‌سازی داده در SQL Server است. این روش ابتدا تمام مزایای Row Compression را اعمال می‌کند و سپس به دنبال الگوها و مقادیر تکراری در کل صفحه داده (Data Page) می‌گردد تا آن‌ها را تنها یک بار ذخیره کند. به همین دلیل، میزان صرفه‌جویی در فضای ذخیره‌سازی معمولاً بسیار بیشتر از Row Compression است.

برخلاف Row Compression که هر ردیف را به‌صورت مستقل بهینه می‌کند، Page Compression تمام اطلاعات موجود در یک صفحه ۸ کیلوبایتی را به‌عنوان یک مجموعه بررسی می‌کند. اگر چندین ردیف دارای مقادیر یا پیشوندهای مشترک باشند، SQL Server آن‌ها را شناسایی کرده و از ذخیره‌سازی تکراری جلوگیری می‌کند.

مرحله اول: Row Compression

در اولین مرحله، تمام ردیف‌های صفحه دقیقاً مانند Row Compression فشرده می‌شوند. بنابراین تمام مزایای این روش به‌صورت خودکار در Page Compression نیز وجود دارد.

مرحله دوم: Prefix Compression

پس از فشرده‌سازی ردیف‌ها، SQL Server ستون‌های هر صفحه را بررسی می‌کند تا پیشوندهای (Prefix) مشترک را پیدا کند.

فرض کنید یک جدول شامل مقادیر زیر باشد:

Microsoft SQL Server
Microsoft Azure
Microsoft Fabric
Microsoft Power BI

در این حالت عبارت Microsoft تنها یک بار در صفحه ذخیره می‌شود و سایر رکوردها فقط به آن ارجاع می‌دهند. این کار باعث کاهش قابل توجه فضای اشغال‌شده می‌شود.

مرحله سوم: Dictionary Compression

در مرحله آخر، SQL Server تمام مقادیر تکراری موجود در صفحه را شناسایی می‌کند و آن‌ها را در یک Dictionary داخلی ذخیره می‌کند. سپس به جای تکرار هر مقدار در ردیف‌های مختلف، تنها یک شناسه (Reference) در هر ردیف قرار می‌گیرد.

این روش به‌ویژه در جداولی که مقادیر مشابه زیادی دارند، مانند نام استان‌ها، شهرها، وضعیت سفارش، کد کالا یا دسته‌بندی محصولات، می‌تواند صرفه‌جویی بسیار چشمگیری ایجاد کند.

Row Compression یا Page Compression کدام گزینه برای SQL Server مناسب‌تر است؟

یکی از مهم‌ترین تصمیم‌هایی که مدیران پایگاه داده هنگام استفاده از Data Compression با آن روبه‌رو می‌شوند، انتخاب میان Row Compression و Page Compression است. اگرچه هر دو روش با هدف کاهش فضای ذخیره‌سازی طراحی شده‌اند، اما مکانیزم عملکرد، میزان صرفه‌جویی در فضا، سربار پردازشی و تأثیر آن‌ها بر Workload کاملاً متفاوت است.

Row Compression تنها ساختار ذخیره‌سازی هر ردیف را بهینه می‌کند. در این روش، SQL Server فضای بلااستفاده انواع داده با طول ثابت را حذف کرده و داده‌ها را به شکل فشرده‌تری در هر ردیف ذخیره می‌کند. از آنجا که عملیات فشرده‌سازی و بازگشایی داده‌ها سبک‌تر است، سربار CPU نسبتاً کمی ایجاد می‌شود و این روش معمولاً برای سیستم‌های OLTP که حجم بالایی از عملیات INSERT، UPDATE و DELETE دارند، انتخاب مناسب‌تری محسوب می‌شود.

در مقابل، Page Compression علاوه بر تمام قابلیت‌های Row Compression، داده‌های تکراری موجود در سطح هر صفحه ۸ کیلوبایتی را نیز شناسایی می‌کند. SQL Server با استفاده از تکنیک‌های Prefix Compression و Dictionary Compression، مقادیر مشابه را تنها یک بار ذخیره کرده و سایر ردیف‌ها را به آن ارجاع می‌دهد. به همین دلیل، میزان صرفه‌جویی در فضای ذخیره‌سازی معمولاً به‌مراتب بیشتر از Row Compression است، اما در ازای آن مصرف CPU نیز افزایش پیدا می‌کند.

در محیط‌های تحلیلی مانند Data Warehouse، سیستم‌های گزارش‌گیری و جداول آرشیوی که حجم عملیات خواندن بسیار بیشتر از نوشتن است، Page Compression معمولاً انتخاب بهتری است زیرا کاهش تعداد صفحات باعث کاهش Disk I/O، استفاده مؤثرتر از Buffer Pool و افزایش سرعت بسیاری از Queryهای تحلیلی می‌شود. اما در سیستم‌های پرتراکنش که پردازنده و زمان پاسخ‌گویی اهمیت بیشتری دارند، Row Compression اغلب تعادل مناسب‌تری میان Performance و مصرف منابع ایجاد می‌کند.

جدول زیر تفاوت‌های اصلی این دو روش را نشان می‌دهد.

ویژگی	Row Compression	Page Compression
سطح فشرده‌سازی	هر ردیف به‌صورت مستقل	کل صفحه داده
میزان کاهش حجم	متوسط	زیاد
مصرف CPU	کم	بیشتر
کاهش Disk I/O	خوب	بسیار خوب
مناسب برای OLTP	بسیار مناسب	در برخی سناریوها
مناسب برای Data Warehouse	مناسب	بهترین گزینه
مناسب برای داده‌های تکراری	محدود	بسیار مؤثر
عملکرد در عملیات UPDATE	بهتر	ممکن است کندتر باشد

با این حال، هیچ‌یک از این دو روش را نمی‌توان بهترین گزینه برای همه پایگاه‌های داده دانست. تصمیم نهایی باید بر اساس تحلیل Workload، میزان تغییرات داده‌ها، الگوی دسترسی کاربران، ظرفیت CPU، وضعیت Storage و نتایج Benchmark واقعی اتخاذ شود. در بسیاری از پروژه‌های سازمانی، ترکیبی از هر دو روش مورد استفاده قرار می‌گیرد به‌عنوان مثال، جداول پرتراکنش با Row Compression و جداول آرشیوی یا گزارش‌گیری با Page Compression فشرده می‌شوند تا بهترین تعادل میان Performance، مصرف CPU و فضای ذخیره‌سازی ایجاد شود.

مزایا، محدودیت‌ها و بهترین کاربردهای Page Compression

در بسیاری از پروژه‌ها، Page Compression می‌تواند حجم جداول را ۳۰ تا ۷۰ درصد کاهش دهد و در برخی سناریوهای خاص این مقدار حتی بیشتر نیز خواهد بود. البته این میزان کاملاً به نوع داده‌ها، الگوی تکرار اطلاعات و ساختار جدول بستگی دارد.

کاهش تعداد صفحات موردنیاز برای ذخیره اطلاعات، مزایای متعددی به همراه دارد. SQL Server برای اجرای Queryها صفحات کمتری را از دیسک می‌خواند، داده‌های بیشتری را در Buffer Pool نگهداری می‌کند، حجم عملیات Disk I/O کاهش می‌یابد و در نتیجه بسیاری از Queryهای مبتنی بر خواندن اطلاعات با سرعت بیشتری اجرا می‌شوند. همچنین به دلیل کوچک‌تر شدن فایل‌های دیتابیس، زمان Backup و Restore و حجم فایل‌های Backup نیز معمولاً کاهش پیدا می‌کند.

با وجود این مزایا، Page Compression بدون هزینه نیست. SQL Server هنگام خواندن یا تغییر داده‌های فشرده‌شده باید عملیات Decompression را انجام دهد و در زمان درج یا به‌روزرسانی اطلاعات نیز ممکن است ساختار صفحه را دوباره سازمان‌دهی کند. بنابراین نسبت به Row Compression مصرف CPU بیشتری دارد و در جداولی که حجم بالایی از عملیات INSERT، UPDATE و DELETE دارند، همیشه بهترین انتخاب محسوب نمی‌شود.

به همین دلیل، Page Compression بیشترین کارایی را در Workloadهای Read-Heavy دارد یعنی محیط‌هایی که داده‌ها بیشتر خوانده می‌شوند تا تغییر کنند. نمونه‌های رایج عبارت‌اند از:

• Data Warehouse
• Data Mart
• سیستم‌های گزارش‌گیری (Reporting)
• جداول آرشیوی و Historical
• پایگاه‌های داده BI
• جداول دارای مقادیر تکراری فراوان

در مقابل، اگر جدول به‌طور مداوم در حال تغییر باشد یا پردازنده سرور از قبل تحت بار سنگین قرار داشته باشد، استفاده از Row Compression معمولاً انتخاب متعادل‌تر و کم‌ریسک‌تری خواهد بود. به همین دلیل، بسیاری از DBAهای حرفه‌ای در محیط‌های عملیاتی، جداول پرتراکنش را با Row Compression و جداول گزارش‌گیری یا آرشیوی را با Page Compression نگهداری می‌کنند تا بهترین تعادل میان Performance، مصرف CPU، Disk I/O و فضای ذخیره‌سازی برقرار شود.

Data Compression همیشه باعث افزایش Performance نمی‌شود

یکی از اشتباهات رایج این است که تصور شود فعال‌سازی Compression همیشه باعث افزایش سرعت SQL Server خواهد شد. در عمل، اگر حجم عملیات خواندن پایین باشد یا بیشتر بار سیستم مربوط به عملیات INSERT، UPDATE و DELETE باشد، افزایش مصرف CPU می‌تواند بخشی از مزایای کاهش I/O را خنثی کند. به همین دلیل، ارزیابی شاخص‌هایی مانند CPU Utilization، Logical Reads، Physical Reads، Page Life Expectancy و مدت زمان اجرای Queryها قبل و بعد از اعمال Compression اهمیت زیادی دارد.

چگونه قبل از اعمال Compression میزان صرفه‌جویی را تخمین بزنیم؟

SQL Server رویه سیستمی sp_estimate_data_compression_savings را برای تخمین میزان صرفه‌جویی در فضای ذخیره‌سازی ارائه کرده است. این رویه بدون اعمال واقعی Compression، نمونه‌ای از صفحات داده را تحلیل کرده و حجم تقریبی جدول یا ایندکس پس از اعمال Row Compression یا Page Compression را محاسبه می‌کند. استفاده از این ابزار قبل از اعمال Compression در محیط Production به DBA کمک می‌کند تصمیم خود را بر اساس داده‌های واقعی اتخاذ کند، نه حدس و گمان.

EXEC sp_estimate_data_compression_savings
    @schema_name='dbo',
    @object_name='Sales',
    @index_id=1,
    @partition_number=NULL,
    @data_compression='PAGE';

نحوه فعال‌سازی Data Compression در SQL Server

فعال‌سازی Row Compression

ALTER TABLE dbo.Sales
REBUILD PARTITION = ALL
WITH
(
    DATA_COMPRESSION = ROW
);

فعال‌سازی Page Compression

ALTER TABLE dbo.Sales
REBUILD PARTITION = ALL
WITH
(
    DATA_COMPRESSION = PAGE
);

حذف Compression

ALTER TABLE dbo.Sales
REBUILD PARTITION = ALL
WITH
(
    DATA_COMPRESSION = NONE
);

فعال‌سازی Compression روی Index

در بسیاری از محیط‌های عملیاتی، به‌جای بازسازی کل جدول، تنها ایندکس‌ها فشرده می‌شوند. SQL Server این امکان را فراهم کرده است که Compression مستقیماً هنگام Rebuild ایندکس اعمال شود.

ALTER INDEX ALL
ON dbo.Sales
REBUILD
WITH
(
    DATA_COMPRESSION = PAGE
);

همین روش برای Row Compression نیز قابل استفاده است.

استفاده از ONLINE REBUILD در محیط Production

در SQL Server Enterprise Edition می‌توان هنگام اعمال Compression از قابلیت ONLINE = ON استفاده کرد تا عملیات Rebuild با حداقل اختلال برای کاربران انجام شود.

ALTER INDEX ALL
ON dbo.Sales
REBUILD
WITH
(
    DATA_COMPRESSION = PAGE,
    ONLINE = ON
);

بررسی وضعیت پس از اعمال Compression

پس از فعال‌سازی Compression بهتر است علاوه بر وضعیت فشرده‌سازی، شاخص‌های عملکردی نیز بررسی شوند.

بررسی میزان استفاده از ایندکس‌ها

SELECT *
FROM sys.dm_db_index_usage_stats;

بررسی عملیات انجام‌شده روی ایندکس‌ها

SELECT *
FROM sys.dm_db_index_operational_stats
(
    DB_ID(),
    NULL,
    NULL,
    NULL
);

این DMVها به DBA کمک می‌کنند تأثیر واقعی Compression بر میزان خواندن، نوشتن و عملیات داخلی SQL Server را ارزیابی کند.

Compression و Fragmentation

از آنجا که اعمال Data Compression معمولاً از طریق REBUILD انجام می‌شود، Fragmentation ایندکس نیز در همان زمان از بین می‌رود. البته با ادامه فعالیت سیستم و انجام عملیات INSERT، UPDATE و DELETE، Fragmentation به‌مرور زمان دوباره ایجاد خواهد شد. بنابراین Compression جایگزین عملیات نگهداری دوره‌ای ایندکس‌ها نیست و همچنان باید برنامه منظم Index Maintenance اجرا شود.

مقایسه Data Compression با Backup Compression و Columnstore Compression

یکی از اشتباهات رایج میان مدیران پایگاه داده، یکسان در نظر گرفتن انواع مختلف فشرده‌سازی در SQL Server است. در حالی که Microsoft چند مکانیزم کاملاً متفاوت برای کاهش حجم داده ارائه کرده که هرکدام هدف، زمان اجرا و تأثیر متفاوتی بر عملکرد سیستم دارند.

شناخت تفاوت این فناوری‌ها باعث می‌شود در طراحی زیرساخت و انتخاب استراتژی بهینه‌سازی، تصمیم دقیق‌تری بگیرید.

نوع فشرده‌سازی	هدف	زمان اعمال	تأثیر بر Query	مناسب برای
Row Compression	کاهش حجم ذخیره‌سازی ردیف‌ها	هنگام ذخیره داده	معمولاً مثبت	سیستم‌های OLTP
Page Compression	کاهش بیشتر حجم صفحات داده	هنگام ذخیره داده	مثبت در خواندن، افزایش CPU	Data Warehouse و جداول بزرگ
Backup Compression	کاهش حجم فایل Backup	هنگام تهیه Backup	هیچ تأثیری بر اجرای Query ندارد	همه پایگاه‌های داده
Columnstore Compression	فشرده‌سازی ستونی و پردازش تحلیلی	هنگام ایجاد Columnstore Index	بسیار سریع برای Queryهای تحلیلی	BI و Data Warehouse

بسیاری تصور می‌کنند فعال کردن Backup Compression باعث کوچک شدن حجم دیتابیس می‌شود، در حالی که این قابلیت فقط فایل Backup را فشرده می‌کند و اندازه فایل‌های MDF و NDF هیچ تغییری نمی‌کند.

از سوی دیگر، Row Compression و Page Compression مستقیماً روی نحوه ذخیره‌سازی داده‌ها در صفحات دیتابیس اثر می‌گذارند. در نتیجه، علاوه بر کاهش فضای ذخیره‌سازی، می‌توانند تعداد Page Readها را کاهش داده و عملکرد بسیاری از Queryها را نیز بهبود دهند.

در مقابل، Columnstore Compression فلسفه متفاوتی دارد. این فناوری داده‌ها را به‌صورت ستونی ذخیره می‌کند و از الگوریتم‌های فشرده‌سازی بسیار پیشرفته‌تری استفاده می‌کند که برای پردازش‌های تحلیلی، اسکن میلیون‌ها ردیف و اجرای Aggregateها طراحی شده‌اند. به همین دلیل، Columnstore جایگزین Row یا Page Compression نیست، بلکه راهکاری متفاوت برای سناریوهای تحلیلی محسوب می‌شود.

به همین دلیل، انتخاب نوع Compression باید بر اساس نوع Workload انجام شود. در محیط‌های OLTP معمولاً Row Compression انتخاب محافظه‌کارانه‌تر و کم‌ریسک‌تری است، در حالی که Page Compression برای جداول بزرگ و کم‌تغییر می‌تواند صرفه‌جویی قابل‌توجهی در فضای ذخیره‌سازی و عملیات I/O ایجاد کند. برای محیط‌های تحلیلی نیز استفاده از Columnstore Index معمولاً بهترین گزینه است، زیرا علاوه بر فشرده‌سازی بسیار بالا، سرعت اجرای Queryهای تحلیلی را نیز به شکل چشمگیری افزایش می‌دهد.

مقایسه Data Compression با Backup Compression و Columnstore Compression

یکی از اشتباهات رایج میان مدیران پایگاه داده، یکسان در نظر گرفتن انواع مختلف فشرده‌سازی در SQL Server است. در حالی که Microsoft چند مکانیزم کاملاً متفاوت برای کاهش حجم داده ارائه کرده که هرکدام هدف، زمان اجرا و تأثیر متفاوتی بر عملکرد سیستم دارند.

شناخت تفاوت این فناوری‌ها باعث می‌شود در طراحی زیرساخت و انتخاب استراتژی بهینه‌سازی، تصمیم دقیق‌تری بگیرید.

نوع فشرده‌سازی	هدف	زمان اعمال	تأثیر بر Query	مناسب برای
Row Compression	کاهش حجم ذخیره‌سازی ردیف‌ها	هنگام ذخیره داده	معمولاً مثبت	سیستم‌های OLTP
Page Compression	کاهش بیشتر حجم صفحات داده	هنگام ذخیره داده	مثبت در خواندن، افزایش CPU	Data Warehouse و جداول بزرگ
Backup Compression	کاهش حجم فایل Backup	هنگام تهیه Backup	هیچ تأثیری بر اجرای Query ندارد	همه پایگاه‌های داده
Columnstore Compression	فشرده‌سازی ستونی و پردازش تحلیلی	هنگام ایجاد Columnstore Index	بسیار سریع برای Queryهای تحلیلی	BI و Data Warehouse

بسیاری تصور می‌کنند فعال کردن Backup Compression باعث کوچک شدن حجم دیتابیس می‌شود، در حالی که این قابلیت فقط فایل Backup را فشرده می‌کند و اندازه فایل‌های MDF و NDF هیچ تغییری نمی‌کند.

از سوی دیگر، Row Compression و Page Compression مستقیماً روی نحوه ذخیره‌سازی داده‌ها در صفحات دیتابیس اثر می‌گذارند. در نتیجه، علاوه بر کاهش فضای ذخیره‌سازی، می‌توانند تعداد Page Readها را کاهش داده و عملکرد بسیاری از Queryها را نیز بهبود دهند.

در مقابل، Columnstore Compression فلسفه متفاوتی دارد. این فناوری داده‌ها را به‌صورت ستونی ذخیره می‌کند و از الگوریتم‌های فشرده‌سازی بسیار پیشرفته‌تری استفاده می‌کند که برای پردازش‌های تحلیلی، اسکن میلیون‌ها ردیف و اجرای Aggregateها طراحی شده‌اند. به همین دلیل، Columnstore جایگزین Row یا Page Compression نیست، بلکه راهکاری متفاوت برای سناریوهای تحلیلی محسوب می‌شود.

به همین دلیل، انتخاب نوع Compression باید بر اساس نوع Workload انجام شود. در محیط‌های OLTP معمولاً Row Compression انتخاب محافظه‌کارانه‌تر و کم‌ریسک‌تری است، در حالی که Page Compression برای جداول بزرگ و کم‌تغییر می‌تواند صرفه‌جویی قابل‌توجهی در فضای ذخیره‌سازی و عملیات I/O ایجاد کند. برای محیط‌های تحلیلی نیز استفاده از Columnstore Index معمولاً بهترین گزینه است، زیرا علاوه بر فشرده‌سازی بسیار بالا، سرعت اجرای Queryهای تحلیلی را نیز به شکل چشمگیری افزایش می‌دهد.

آیا می‌توان Compression را در سطح Index اعمال کرد؟

بله. یکی از قابلیت‌های مهم SQL Server این است که Data Compression فقط محدود به جدول نیست.

می‌توان Compression را روی موارد زیر اعمال کرد:

• Heap
• Clustered Index
• Nonclustered Index
• هر Partition به صورت جداگانه

این قابلیت در پایگاه‌های داده بزرگ اهمیت زیادی دارد زیرا ممکن است تنها بخش کوچکی از داده‌ها نیاز به Compression داشته باشند.

برای مثال می‌توان Partitionهای مربوط به سال‌های گذشته را با Page Compression ذخیره کرد و Partition جاری را بدون Compression یا با Row Compression نگه داشت. این روش تعادل بسیار مناسبی میان Performance و صرفه‌جویی در فضا ایجاد می‌کند.

بهترین روش پیاده‌سازی Data Compression در محیط Production

۱- ابتدا با sp_estimate_data_compression_savings میزان صرفه‌جویی را تخمین بزنید.

۲- روی محیط Test یا Staging Benchmark اجرا کنید.

۳- CPU، Logical Read و Physical Read را اندازه‌گیری کنید.

۴- ابتدا جداول Read Only یا Archive را فشرده کنید.

۵- سپس به سراغ جداول Reporting بروید.

۶- جداول پرتراکنش OLTP را فقط پس از انجام تست عملی فشرده کنید.

۷- بعد از اعمال Compression، Query Store و Performance Monitor را بررسی کنید.

اعمال Compression روی جداول و ایندکس‌های بزرگ معمولاً نیازمند عملیات REBUILD است و می‌تواند باعث تولید حجم قابل‌توجهی از Transaction Log شود. در محیط‌های دارای Log Shipping، Always On Availability Groups یا Replication، پیش از اجرای Compression باید فضای کافی برای فایل Log و زیرساخت انتقال Log در نظر گرفته شود.

تأثیر Compression بر Transaction Log

اعمال Data Compression معمولاً از طریق عملیات REBUILD انجام می‌شود. در جداول بزرگ، این عملیات ممکن است حجم بسیار زیادی از Transaction Log تولید کند. در محیط‌هایی که از Log Shipping، Always On Availability Groups یا Replication استفاده می‌شود، قبل از اجرای Compression باید موارد زیر بررسی شوند:

• فضای فایل Transaction Log
• تنظیمات Autogrowth
• برنامه Backup از Transaction Log
• پهنای باند انتقال Log
• ظرفیت دیسک مقصد Log Shipping

نادیده گرفتن این موارد ممکن است باعث رشد ناگهانی فایل Log یا افزایش زمان همگام‌سازی Replicaها شود.

مشاهده وضعیت Data Compression در SQL Server

SELECT
    OBJECT_NAME(p.object_id) AS TableName,
    i.name AS IndexName,
    p.partition_number,
    p.data_compression_desc
FROM sys.partitions p
JOIN sys.indexes i
ON p.object_id = i.object_id
AND p.index_id = i.index_id
WHERE p.data_compression <> 0;

نکته مهم برای محیط Production

اعمال Data Compression روی جداول چندصد گیگابایتی یا چندترابایتی باید در پنجره‌های نگهداری (Maintenance Window) انجام شود. در بسیاری از محیط‌های عملیاتی، اجرای REBUILD ممکن است ساعت‌ها زمان ببرد و حجم زیادی از Transaction Log تولید کند. بنابراین پیش از شروع عملیات، ظرفیت Storage، فضای فایل Log، وضعیت Replicaها و برنامه Backup باید به‌دقت بررسی شوند.

مقایسه Data Compression با Backup Compression و Columnstore Compression

یکی از اشتباهات رایج میان مدیران پایگاه داده، یکسان در نظر گرفتن انواع مختلف فشرده‌سازی در SQL Server است. در حالی که Microsoft چند مکانیزم کاملاً متفاوت برای کاهش حجم داده ارائه کرده که هرکدام هدف، زمان اجرا و تأثیر متفاوتی بر عملکرد سیستم دارند.

شناخت تفاوت این فناوری‌ها باعث می‌شود در طراحی زیرساخت و انتخاب استراتژی بهینه‌سازی، تصمیم دقیق‌تری بگیرید.

نوع فشرده‌سازی	هدف	زمان اعمال	تأثیر بر Query	مناسب برای
Row Compression	کاهش حجم ذخیره‌سازی ردیف‌ها	هنگام ذخیره داده	معمولاً مثبت	سیستم‌های OLTP
Page Compression	کاهش بیشتر حجم صفحات داده	هنگام ذخیره داده	مثبت در خواندن، افزایش CPU	Data Warehouse و جداول بزرگ
Backup Compression	کاهش حجم فایل Backup	هنگام تهیه Backup	هیچ تأثیری بر اجرای Query ندارد	همه پایگاه‌های داده
Columnstore Compression	فشرده‌سازی ستونی و پردازش تحلیلی	هنگام ایجاد Columnstore Index	بسیار سریع برای Queryهای تحلیلی	BI و Data Warehouse

بسیاری تصور می‌کنند فعال کردن Backup Compression باعث کوچک شدن حجم دیتابیس می‌شود، در حالی که این قابلیت فقط فایل Backup را فشرده می‌کند و اندازه فایل‌های MDF و NDF هیچ تغییری نمی‌کند.

از سوی دیگر، Row Compression و Page Compression مستقیماً روی نحوه ذخیره‌سازی داده‌ها در صفحات دیتابیس اثر می‌گذارند. در نتیجه، علاوه بر کاهش فضای ذخیره‌سازی، می‌توانند تعداد Page Readها را کاهش داده و عملکرد بسیاری از Queryها را نیز بهبود دهند.

در مقابل، Columnstore Compression فلسفه متفاوتی دارد. این فناوری داده‌ها را به‌صورت ستونی ذخیره می‌کند و از الگوریتم‌های فشرده‌سازی بسیار پیشرفته‌تری استفاده می‌کند که برای پردازش‌های تحلیلی، اسکن میلیون‌ها ردیف و اجرای Aggregateها طراحی شده‌اند. به همین دلیل، Columnstore جایگزین Row یا Page Compression نیست، بلکه راهکاری متفاوت برای سناریوهای تحلیلی محسوب می‌شود.

به همین دلیل، انتخاب نوع Compression باید بر اساس نوع Workload انجام شود. در محیط‌های OLTP معمولاً Row Compression انتخاب محافظه‌کارانه‌تر و کم‌ریسک‌تری است، در حالی که Page Compression برای جداول بزرگ و کم‌تغییر می‌تواند صرفه‌جویی قابل‌توجهی در فضای ذخیره‌سازی و عملیات I/O ایجاد کند. برای محیط‌های تحلیلی نیز استفاده از Columnstore Index معمولاً بهترین گزینه است، زیرا علاوه بر فشرده‌سازی بسیار بالا، سرعت اجرای Queryهای تحلیلی را نیز به شکل چشمگیری افزایش می‌دهد.

آیا می‌توان Compression را در سطح Index اعمال کرد؟

بله. یکی از قابلیت‌های مهم SQL Server این است که Data Compression فقط محدود به جدول نیست.

می‌توان Compression را روی موارد زیر اعمال کرد:

• Heap
• Clustered Index
• Nonclustered Index
• هر Partition به صورت جداگانه

این قابلیت در پایگاه‌های داده بزرگ اهمیت زیادی دارد زیرا ممکن است تنها بخش کوچکی از داده‌ها نیاز به Compression داشته باشند.

برای مثال می‌توان Partitionهای مربوط به سال‌های گذشته را با Page Compression ذخیره کرد و Partition جاری را بدون Compression یا با Row Compression نگه داشت. این روش تعادل بسیار مناسبی میان Performance و صرفه‌جویی در فضا ایجاد می‌کند.

بهترین روش پیاده‌سازی Data Compression در محیط Production

۱- ابتدا با sp_estimate_data_compression_savings میزان صرفه‌جویی را تخمین بزنید.

۲- روی محیط Test یا Staging Benchmark اجرا کنید.

۳- CPU، Logical Read و Physical Read را اندازه‌گیری کنید.

۴- ابتدا جداول Read Only یا Archive را فشرده کنید.

۵- سپس به سراغ جداول Reporting بروید.

۶- جداول پرتراکنش OLTP را فقط پس از انجام تست عملی فشرده کنید.

۷- بعد از اعمال Compression، Query Store و Performance Monitor را بررسی کنید.

اعمال Compression روی جداول و ایندکس‌های بزرگ معمولاً نیازمند عملیات Rebuild است و می‌تواند باعث تولید حجم قابل‌توجهی از Transaction Log شود. در محیط‌های دارای Log Shipping، Always On Availability Groups یا Replication، پیش از اجرای Compression باید فضای کافی برای فایل Log و زیرساخت انتقال Log در نظر گرفته شود.

تأثیر Compression بر Transaction Log

اعمال Data Compression معمولاً از طریق عملیات REBUILD انجام می‌شود. در جداول بزرگ، این عملیات ممکن است حجم بسیار زیادی از Transaction Log تولید کند. در محیط‌هایی که از Log Shipping، Always On Availability Groups یا Replication استفاده می‌شود، قبل از اجرای Compression باید موارد زیر بررسی شوند:

• فضای فایل Transaction Log
• تنظیمات Autogrowth
• برنامه Backup از Transaction Log
• پهنای باند انتقال Log
• ظرفیت دیسک مقصد Log Shipping

نادیده گرفتن این موارد ممکن است باعث رشد ناگهانی فایل Log یا افزایش زمان همگام‌سازی Replicaها شود.

مشاهده وضعیت Data Compression در SQL Server

SELECT
    OBJECT_NAME(p.object_id) AS TableName,
    i.name AS IndexName,
    p.partition_number,
    p.data_compression_desc
FROM sys.partitions p
JOIN sys.indexes i
    ON p.object_id = i.object_id
   AND p.index_id = i.index_id
WHERE p.data_compression <> 0;

چه زمانی Page Compression بهترین انتخاب است؟

Page Compression پیشرفته‌ترین روش فشرده‌سازی داده در SQL Server است و علاوه بر تمام قابلیت‌های Row Compression، با استفاده از تکنیک‌های Prefix Compression و Dictionary Compression داده‌های تکراری موجود در هر صفحه ۸ کیلوبایتی را نیز شناسایی و تنها یک بار ذخیره می‌کند. به همین دلیل، میزان صرفه‌جویی در فضای ذخیره‌سازی معمولاً به‌مراتب بیشتر از Row Compression است و در بسیاری از پروژه‌ها بین ۳۰ تا ۷۰ درصد کاهش حجم ایجاد می‌کند. البته این میزان کاملاً به نوع داده‌ها، الگوی تکرار اطلاعات و ساختار جدول بستگی دارد.

کاهش تعداد صفحات موردنیاز برای ذخیره اطلاعات، مزایای متعددی به همراه دارد. SQL Server برای اجرای Queryها صفحات کمتری را از دیسک می‌خواند، داده‌های بیشتری را در Buffer Pool نگهداری می‌کند، حجم عملیات Disk I/O کاهش می‌یابد و در نتیجه بسیاری از Queryهای مبتنی بر خواندن اطلاعات با سرعت بیشتری اجرا می‌شوند. همچنین به دلیل کوچک‌تر شدن فایل‌های دیتابیس، زمان Backup و Restore و حجم فایل‌های Backup نیز معمولاً کاهش پیدا می‌کند.

با وجود این مزایا، Page Compression بدون هزینه نیست. SQL Server هنگام خواندن یا تغییر داده‌های فشرده‌شده باید عملیات Decompression را انجام دهد و در زمان درج یا به‌روزرسانی اطلاعات نیز ممکن است ساختار صفحه را دوباره سازمان‌دهی کند. بنابراین نسبت به Row Compression مصرف CPU بیشتری دارد و در جداولی که حجم بالایی از عملیات INSERT، UPDATE و DELETE دارند، همیشه بهترین انتخاب محسوب نمی‌شود.

به همین دلیل، Page Compression بیشترین کارایی را در Workloadهای Read-Heavy دارد یعنی محیط‌هایی که داده‌ها بیشتر خوانده می‌شوند تا تغییر کنند. نمونه‌های رایج عبارت‌اند از:

• Data Warehouse
• Data Mart
• سیستم‌های گزارش‌گیری (Reporting)
• جداول آرشیوی و Historical
• پایگاه‌های داده BI
• جداول دارای مقادیر تکراری فراوان

در مقابل، اگر جدول به‌طور مداوم در حال تغییر باشد یا پردازنده سرور از قبل تحت بار سنگین قرار داشته باشد، استفاده از Row Compression معمولاً انتخاب متعادل‌تر و کم‌ریسک‌تری خواهد بود. به همین دلیل، بسیاری از DBAهای حرفه‌ای در محیط‌های عملیاتی، جداول پرتراکنش را با Row Compression و جداول گزارش‌گیری یا آرشیوی را با Page Compression نگهداری می‌کنند تا بهترین تعادل میان Performance، مصرف CPU، Disk I/O و فضای ذخیره‌سازی برقرار شود.

مقایسه کاربرد Row Compression و Page Compression

سناریو	Row Compression	Page Compression
OLTP پرتراکنش	⭐⭐⭐⭐⭐	⭐⭐
Data Warehouse	⭐⭐⭐	⭐⭐⭐⭐⭐
Reporting Database	⭐⭐⭐	⭐⭐⭐⭐⭐
Archive Data	⭐⭐	⭐⭐⭐⭐⭐
CPU محدود	⭐⭐⭐⭐⭐	⭐⭐
Storage محدود	⭐⭐⭐	⭐⭐⭐⭐⭐
داده‌های تکراری	⭐⭐	⭐⭐⭐⭐⭐
نرخ بالای UPDATE	⭐⭐⭐⭐⭐	⭐⭐
محیط‌های Read-Heavy	⭐⭐⭐	⭐⭐⭐⭐⭐

در نهایت، هیچ‌یک از این دو روش را نمی‌توان بهترین گزینه برای همه پایگاه‌های داده دانست. انتخاب صحیح باید بر اساس تحلیل Workload، میزان عملیات خواندن و نوشتن، الگوی دسترسی کاربران، ظرفیت CPU، وضعیت Storage و نتایج Benchmark انجام شود. هدف یک DBA حرفه‌ای، اعمال Compression روی همه جداول نیست بلکه انتخاب مناسب‌ترین نوع فشرده‌سازی برای هر بخش از پایگاه داده است تا بیشترین بازده با کمترین سربار پردازشی حاصل شود.

نکته مهم برای محیط Production

اعمال Data Compression روی جداول چندصد گیگابایتی یا چندترابایتی باید در پنجره‌های نگهداری (Maintenance Window) انجام شود. در بسیاری از محیط‌های عملیاتی، اجرای REBUILD ممکن است ساعت‌ها زمان ببرد و حجم زیادی از Transaction Log تولید کند. بنابراین پیش از شروع عملیات، ظرفیت Storage، فضای فایل Log، وضعیت Replicaها و برنامه Backup باید به‌دقت بررسی شوند.

نتیجه‌گیری

Data Compression در SQL Server تنها یک قابلیت برای کاهش حجم فایل‌های دیتابیس نیست، بلکه ابزاری استراتژیک برای بهینه‌سازی عملکرد، کاهش هزینه‌های زیرساخت و افزایش بهره‌وری منابع محسوب می‌شود. با کاهش تعداد Pageهایی که از دیسک خوانده و در Buffer Pool نگهداری می‌شوند، بسیاری از Workloadها به‌ویژه در محیط‌های تحلیلی و دیتابیس‌های حجیم، بهبود محسوسی در زمان اجرای Queryها تجربه می‌کنند.

با این حال، انتخاب نوع فشرده‌سازی نباید صرفاً بر اساس میزان صرفه‌جویی در فضای ذخیره‌سازی انجام شود. هر Workload رفتار متفاوتی دارد و عواملی مانند میزان عملیات خواندن و نوشتن، تعداد به‌روزرسانی‌ها، الگوی دسترسی کاربران، ظرفیت CPU و حتی نوع Storage می‌توانند بر نتیجه نهایی تأثیر بگذارند. در برخی سناریوها، کاهش I/O به‌مراتب ارزشمندتر از افزایش اندک مصرف CPU است، اما در سیستم‌های OLTP با نرخ بالای تراکنش ممکن است این توازن متفاوت باشد.

یکی از اشتباهات رایج در بسیاری از سازمان‌ها، فعال کردن Data Compression روی تمام جداول و ایندکس‌ها بدون تحلیل قبلی است. بهترین رویکرد این است که ابتدا با ابزارهایی مانند sp_estimate_data_compression_savings میزان صرفه‌جویی تخمین زده شود، سپس روی محیط آزمایشی Benchmark انجام گیرد و در نهایت با بررسی شاخص‌هایی مانند CPU، Logical Reads، Physical Reads، مدت اجرای Queryها و حجم فایل‌های دیتابیس درباره اعمال Compression تصمیم‌گیری شود.

همچنین باید توجه داشت که Data Compression بخشی از یک استراتژی جامع Performance Tuning است، نه جایگزینی برای طراحی صحیح دیتابیس. اگر ایندکس‌ها نامناسب باشند، Queryها SARGable نباشند، Statistics قدیمی باشند یا مدل داده بهینه طراحی نشده باشد، فعال کردن Compression به‌تنهایی نمی‌تواند مشکلات عملکرد را برطرف کند. بیشترین اثربخشی زمانی حاصل می‌شود که این قابلیت در کنار Index Optimization، نگهداری منظم Statistics، طراحی مناسب Filegroupها، مدیریت صحیح Storage و مانیتورینگ مستمر عملکرد مورد استفاده قرار گیرد.

در نهایت، Data Compression زمانی بیشترین ارزش را ایجاد می‌کند که بر اساس تحلیل دقیق Workload، شناخت رفتار داده‌ها و ارزیابی هزینه و فایده پیاده‌سازی شود. سازمان‌هایی که این قابلیت را به‌صورت هدفمند و مبتنی بر داده به کار می‌گیرند، علاوه بر کاهش مصرف فضای ذخیره‌سازی، می‌توانند عملکرد پایدارتر، هزینه عملیاتی کمتر و مقیاس‌پذیری بالاتری را در محیط SQL Server تجربه کنند.

سوالات متداول (FAQ)

Data Compression در SQL Server چیست؟

Data Compression قابلیتی در SQL Server است که با کاهش حجم فیزیکی داده‌های ذخیره‌شده، مصرف فضای دیسک را کاهش داده و در بسیاری از سناریوها باعث کاهش I/O و بهبود عملکرد Queryها می‌شود. این قابلیت بدون تغییر در منطق برنامه یا داده‌های اصلی عمل می‌کند.

تفاوت Row Compression و Page Compression چیست؟

Row Compression تنها ساختار ذخیره‌سازی هر ردیف را بهینه می‌کند و سربار اضافی داده‌ها را کاهش می‌دهد. اما Page Compression علاوه بر Row Compression، از تکنیک‌های Prefix Compression و Dictionary Compression برای حذف داده‌های تکراری در سطح Page استفاده می‌کند و معمولاً نسبت فشرده‌سازی بالاتری ارائه می‌دهد.

آیا Data Compression باعث افزایش سرعت SQL Server می‌شود؟

در بسیاری از Workloadهایی که محدودیت اصلی آن‌ها I/O است، بله. کاهش تعداد Pageهای خوانده‌شده از دیسک می‌تواند زمان اجرای Queryها را کاهش دهد. با این حال، به دلیل نیاز به Compression و Decompression، مصرف CPU افزایش می‌یابد و نتیجه نهایی به نوع بار کاری بستگی دارد.

آیا Data Compression برای دیتابیس‌های OLTP مناسب است؟

در بسیاری از سیستم‌های OLTP، استفاده از Row Compression انتخاب مناسب‌تری است زیرا سربار CPU کمتری نسبت به Page Compression دارد. برای جداولی که به‌روزرسانی بسیار زیادی دارند، قبل از فعال‌سازی باید تست عملکرد انجام شود.

Page Compression برای چه محیط‌هایی مناسب‌تر است؟

این نوع Compression معمولاً بهترین گزینه برای Data Warehouse، سیستم‌های گزارش‌گیری، جداول آرشیوی و داده‌هایی است که نرخ خواندن بسیار بیشتر از نوشتن دارند و مقادیر تکراری زیادی در آن‌ها وجود دارد.

چگونه قبل از اعمال Compression میزان صرفه‌جویی را بررسی کنیم؟

SQL Server رویه سیستمی sp_estimate_data_compression_savings را ارائه می‌دهد که بدون اعمال واقعی Compression، میزان تقریبی کاهش حجم داده‌ها را محاسبه می‌کند و به DBA کمک می‌کند قبل از تغییر، تصمیم آگاهانه‌تری بگیرد.

آیا می‌توان فقط یک Index را فشرده کرد؟

بله. Data Compression را می‌توان در سطح Table، Index، Partition و حتی هر Partition به‌صورت مستقل اعمال کرد. این انعطاف‌پذیری باعث می‌شود بتوان برای بخش‌های مختلف یک جدول، سیاست‌های متفاوتی در نظر گرفت.

آیا Data Compression جایگزین Archive یا Backup است؟

خیر. هدف Data Compression کاهش حجم داده‌های ذخیره‌شده و بهبود عملکرد است، نه آرشیو کردن اطلاعات یا کاهش حجم فایل‌های Backup. البته به دلیل کوچک‌تر شدن دیتابیس، معمولاً حجم Backup نیز کاهش پیدا می‌کند.

آیا اعمال Data Compression باعث بازسازی جدول یا ایندکس می‌شود؟

بله. در اغلب موارد، اعمال یا حذف Data Compression از طریق عملیات REBUILD انجام می‌شود. این فرآیند ممکن است زمان‌بر باشد، حجم قابل‌توجهی Transaction Log تولید کند و بسته به نسخه SQL Server و Edition، در صورت استفاده نکردن از ONLINE REBUILD باعث قفل شدن موقت جدول یا ایندکس شود.

دیدگاه توسعه فناوری اطلاعات لاندا

در تجربه پروژه‌های SQL Server، معمولاً مشاهده می‌کنیم که بسیاری از سازمان‌ها Data Compression را تنها به‌عنوان راهکاری برای آزادسازی فضای ذخیره‌سازی در نظر می‌گیرند، در حالی که ارزش واقعی آن در بهینه‌سازی معماری دیتابیس و کاهش هزینه‌های عملیاتی نهفته است.

رویکرد توسعه فناوری اطلاعات لاندا پیش از فعال‌سازی Compression، بر تحلیل دقیق Workload، بررسی الگوی دسترسی به داده‌ها، ارزیابی شاخص‌های عملکردی و انجام تست‌های Benchmark استوار است. در بسیاری از پروژه‌ها، ترکیب صحیح Compression با طراحی استاندارد Indexها، بهینه‌سازی Queryها، نگهداری Statistics و مدیریت Filegroupها، تأثیر بسیار بیشتری نسبت به فعال‌سازی ساده این قابلیت داشته است.

اگر قصد دارید عملکرد SQL Server خود را بهبود دهید، مصرف Storage را کاهش دهید یا مناسب‌ترین استراتژی Compression را برای محیط OLTP، Data Warehouse یا سامانه‌های تحلیلی انتخاب کنید، کارشناسان لاندا آماده‌اند تا با تحلیل تخصصی زیرساخت و Workload سازمان شما، بهترین راهکار را طراحی و پیاده‌سازی کنند.

آخرین بروزرسانی

تا تیر ۱۴۰۵، قابلیت Data Compression همچنان یکی از مؤثرترین روش‌های کاهش مصرف Storage در SQL Server محسوب می‌شود و در نسخه‌های SQL Server 2022 و همچنین Azure SQL Database بدون تغییر اساسی در معماری، بهبودهایی در زمینه بهینه‌سازی Query Optimizer، مدیریت حافظه و پردازش موازی باعث شده‌اند بسیاری از Workloadهای فشرده‌شده عملکرد پایدارتری نسبت به نسخه‌های قدیمی‌تر داشته باشند.

همچنین با گسترش استفاده از NVMe Storage، Persistent Memory و زیرساخت‌های ابری، اگرچه هزینه Storage نسبت به گذشته کاهش یافته است، اما Data Compression همچنان نقش مهمی در کاهش Disk I/O، افزایش نرخ استفاده از Buffer Pool، کوتاه‌تر شدن زمان Backup و Restore و کاهش هزینه‌های زیرساخت، به‌ویژه در دیتابیس‌های چند ترابایتی، ایفا می‌کند.

در پروژه‌های جدید نیز مایکروسافت همچنان توصیه می‌کند پیش از فعال‌سازی Compression، میزان صرفه‌جویی با استفاده از sp_estimate_data_compression_savings ارزیابی شود و تصمیم نهایی بر اساس Benchmark واقعی محیط تولید گرفته شود، نه صرفاً بر اساس اندازه جدول یا فضای ذخیره‌سازی موجود.

نکته: اگر از SQL Server 2022 یا Azure SQL استفاده می‌کنید، ترکیب Data Compression با قابلیت‌هایی مانند Columnstore Index، Query Store و Intelligent Query Processing معمولاً نتایج بهتری نسبت به استفاده مستقل از هر یک از این قابلیت‌ها ایجاد می‌کند، مشروط بر اینکه طراحی ایندکس‌ها و الگوی Workload به‌درستی تحلیل شده باشد.