پارادوکس سرعت و حجم؛ جادویی در کار نیست!

فرض کنید یک فایل دیتای خام با حجم 10 گیگابایت و ده‌ها میلیون ردیف اطلاعات فروش در اختیار دارید. این داده‌ها را وارد Power BI می‌کنید. در کمال تعجب، فایل خروجی شما (فایل pbix.) به چیزی حدود 1 گیگابایت (یا شاید کمتر) کاهش پیدا می‌کند.

اما قسمت عجیب‌تر ماجرا اینجاست: وقتی در داشبورد خود روی یک نمودار کلیک می‌کنید تا فروش یک محصول خاص را در سه سال گذشته بررسی کنید، نتیجه در کسری از ثانیه روی یک لپ‌تاپ معمولی با رم 8 یا 16 گیگابایت فیلتر می‌شود!

چگونه چنین چیزی ممکن است؟

اگر سابقه کار با پایگاه‌های داده رابطه‌ای کلاسیک مثل SQL Server را داشته باشید، می‌دانید که اسکن کردن 50 میلیون ردیف برای پیدا کردن یک جمع ساده ، نیازمند درگیری شدید هارد دیسک ، مصرف بالای منابع و صرف زمان است. در دنیای سنتی دیتابیس‌ها، سرعت و حجم دشمنان خونی یکدیگرند. هرچه حجم بالاتر برود، سرعت افت می‌کند؛ مگر اینکه سرورهای گران‌قیمت و سخت‌افزارهای هیولایی وارد میدان شوند.

اما Power BI قواعد این بازی را تغییر داده است. در قلب این نرم‌افزار، موتوری می‌تپد که به جای تکیه بر «زورِ بازوی سخت‌افزار»، بر «نبوغِ معماری نرم‌افزار» تکیه دارد.

معرفی می‌کنم: موتور تحلیلی VertiPaq

VertiPaq که در اسناد فنی مایکروسافت با نام xVelocity هم شناخته می‌شود ، یک موتور پایگاه داده از نوع In-Memory و Columnar (ستونی) است. این موتور جادو نمی‌کند، بلکه معماری ذخیره‌سازی و خواندن داده‌ها را از پایه بازنویسی کرده است. برای اینکه بفهمیم این موتور چگونه دیتای ما را مچاله می‌کند و با سرعت نور به سوالات DAX پاسخ می‌دهد، باید ابتدا طرز فکرمان را درباره نحوه ذخیره داده‌ها تغییر دهیم و از زاویه‌ای جدید به جداول نگاه کنیم. زاویه‌ای که در آن، «ردیف‌ها» دیگر پادشاهی نمی‌کنند!

مرگی برای پادشاهی ردیف‌ها؛ تولد امپراتوری ستون‌ها

برای درک شاهکار VertiPaq، ابتدا باید با بزرگترین نقطه ضعف پایگاه داده های سنتی (مثل SQL Server در حالت عادی، Oracle یا MySQL) در کارهای تحلیلی آشنا شویم.

پایگاه‌های داده سنتی، «ردیف-محور» (Row-store) هستند. یعنی اطلاعات را ردیف به ردیف روی هارد دیسک ذخیره می‌کنند. این معماری برای سیستم‌های عملیاتی (OLTP) بی‌نظیر است؛ مثلاً وقتی می‌خواهید یک فاکتور جدید ثبت کنید یا آدرس یک مشتری را تغییر دهید، سیستم به سرعت یک ردیف را پیدا کرده و آن را آپدیت می‌کند. اما در هوش تجاری (BI) ما معمولاً کاری با یک ردیف خاص نداریم! ما سوالاتی از این قبیل می‌پرسیم:

مجموع فروش (Sales Amount) در سال گذشته چقدر بوده است؟

در یک پایگاه داده ردیف-محور، برای پاسخ به این سوال ساده، موتور پایگاه داده مجبور است تمام ردیف‌ها را از روی دیسک بخواند. یعنی حتی ستون‌های نامربوطی مثل نام مشتری، آدرس، شماره تلفن و کد پستی هم خوانده می‌شوند تا سیستم بتواند به ستون “مبلغ فروش” برسد. این یعنی هدر رفتن وحشتناکِ منابع سیستم (I/O) و زمان!

رویکرد VertiPaq: ستون‌ها وارد می‌شوند!

اینجا همان جایی است که VertiPaq ورق را برمی‌گرداند. VertiPaq یک پایگاه داده ستون-محور (Columnar) است. وقتی شما یک جدول را وارد Power BI می‌کنید، VertiPaq جدول شما را «تکه تکه» می‌کند. او هر ستون را به صورت یک ساختار داده‌ای کاملاً مستقل و جداگانه ذخیره می‌کند.

حالا دوباره همان سوال را می‌پرسیم: مجموع فروش چقدر است؟

موتور VertiPaq ، فقط و فقط ستون Sales Amount را می‌خواند! او کاری با ستون‌های تاریخ، نام محصول یا آدرس ندارد. اگر جدول شما 100 ستون داشته باشد و کوئری DAX شما فقط به 2 ستون نیاز داشته باشد، 98 ستون دیگر اصلاً لمس هم نمی‌شوند.

پرواز بر فراز سیلیکون؛ جادوی پردازش In-Memory

ذخیره‌سازی ستونی به تنهایی یک انقلاب بود، اما برای رسیدن به سرعت میلی‌ثانیه‌ای کافی نیست. بزرگترین دشمن سرعت در دنیای پایگاه‌های داده چیست؟ قطعا هارد دیسک!

حتی اگر از سریع‌ترین درایوهای NVMe هم استفاده کنید، خواندن اطلاعات از روی دیسک فیزیکی، در مقیاس پردازشگرها (CPU)، شبیه به پیاده‌روی در یک اتوبان است. دیتابیس‌های سنتی برای هر کوئری باید به دیسک مراجعه کنند، دیتا را بخوانند و به پردازنده بیاورند. این رفت و برگشت (Disk I/O) گلوگاه اصلی است.

موتور VertiPaq یک دیتابیس درون‌حافظه‌ای (In-Memory) است. وقتی شما داشبورد Power BI خود را باز می‌کنید VertiPaq تمام ساختار ستونی جدول‌های شما را از روی دیسک برمی‌دارد و مستقیماً داخل حافظه رم بارگذاری می‌کند. حافظه رم هزاران بار سریع‌تر از هارد دیسک است. وقتی کاربر در داشبورد روی یک نمودار کلیک می‌کند تا فیلتری اعمال کند، CPU نیازی ندارد منتظر هارد دیسک بماند. تمام داده‌ها پیشاپیش در سریع‌ترین حافظه ممکن آماده پردازش هستند. ترکیب معماری ستونی (خواندن فقط ستون‌های مورد نیاز) و پردازش In-Memory (خواندن از روی رم با سرعت نور)، همان دلیلی است که فیلتر کردن ده‌ها میلیون ردیف در یک چشم بر هم زدن انجام می‌شود.

اما یک مشکل بزرگ وجود دارد!

اینجا همان نقطه‌ای است که پارادوکس اصلی ما (سوال بخش اول) خودش را نشان می‌دهد. حافظه RAM بسیار سریع است، اما دو محدودیت بزرگ دارد:

1. گران است.

2. ظرفیت محدودی دارد. (لپ‌تاپ‌های معمولی معمولاً 8 یا 16 گیگابایت رم دارند).

اگر قرار باشد یک دیتابیس 10 گیگابایتی (یا بزرگتر) مستقیماً وارد RAM شود، حافظه سیستم به سرعت پر میشود پس VertiPaq چگونه می‌تواند دیتابیس‌های غول‌پیکر را در حافظه محدود رم جا دهد؟ پاسخ این سوال، قلب تپنده و شاهکار مهندسی VertiPaq است: فشرده‌سازی بی‌رحمانه!

هنر مچاله کردن داده‌ها؛ جادوی فشرده‌سازی در VertiPaq

اینجاست که VertiPaq روی دیگر سکه خود را نشان می‌دهد: فشرده‌سازی هوشمند (Smart Compression)

ما درباره فشرده‌سازی معمولی (مثل فایل‌های ZIP) صحبت نمی‌کنیم. فایل ZIP برای خوانده شدن باید ابتدا از حالت فشرده خارج (Extract) شود که این کار به شدت زمان‌بر است. VertiPaq دیتا را طوری فشرده می‌کند که بتواند در همان حالت فشرده روی آن پردازش و جستجو انجام دهد! اما موتور VertiPaq چطور دیتاهای ۱۰ گیگابایتی را به ۱ گیگابایت تبدیل می‌کند؟ او برای این کار به یک مفهوم کلیدی و سه الگوریتم طلایی تکیه می‌کند.

۱. کدگذاری مقادیر (Value Encoding)

این روش معمولاً برای ستون‌های عددی استفاده می‌شود و شبیه به یک ترفند ریاضی ساده اما کاربردی است. فرض کنید یک ستون دارید که قیمت محصولات را ذخیره کرده و قیمت‌ها بین 1,000,000 تا 1,000,500 تومان هستند.

VertiPaq به جای اینکه این اعداد بزرگ را ذخیره کند، کمترین مقدار (یعنی 1,000,000) را پیدا کرده و از تمام ردیف‌ها کم می‌کند. حالا اعدادی که ذخیره می‌شوند بین 0 تا 500 هستند! ذخیره کردن عدد 500 به بیت‌های بسیار کمتری در رم نیاز دارد تا عدد 1,000,500 در زمان کوئری گرفتن، موتور به سرعت آن عدد پایه را به نتیجه اضافه می‌کند.

۲. کدگذاری دیکشنری (Dictionary/Hash Encoding)

این پرکاربردترین روش فشرده‌سازی در VertiPaq است، مخصوصاً برای متن‌ها. فرض کنید جدولی با ۱۰ میلیون ردیف دارید و نام شهرها در آن تکرار شده است. واژه “تهران” ممکن است ۳ میلیون بار تکرار شده باشد. ذخیره کردن کلمه “تهران” در حافظه، فضای زیادی می‌گیرد.

VertiPaq چه می‌کند؟ یک جدول جداگانه (دیکشنری) می‌سازد:

• تهران = 0

• شیراز = 1

• تبریز = 2

سپس در جدول اصلی ده میلیون ردیفی، به جای کلمات، فقط اعداد را ذخیره می‌کند. پردازنده عاشق اعداد صحیح (Integer) است و این کار حجم دیتا را به شکل خیره‌کننده‌ای کاهش می‌دهد.

۳. کدگذاری طول اجرای متوالی (Run-Length Encoding یا RLE)

این روش تیر خلاص فشرده‌سازی است! فرض کنید بعد از Dictionary Encoding، دیتای شما در یک ستون به این شکل درآمده است:

0,0,0,0,0,1,1,1,2,2,2,2

(یعنی ۵ تا صفر، ۳ تا یک، ۴ تا دو).

VertiPaq به جای ذخیره کردن تک‌تک این اعداد، آن‌ها را به این شکل ذخیره می‌کند:

• 5 تا 0

• 3 تا 1

• 2 تا 4

یعنی ۱۲ ردیف دیتا، تنها در ۳ ردیف خلاصه شد! البته این روش زمانی بهترین نتیجه را می‌دهد که داده ها مرتب شده باشند. هنگام بارگذاری ، موتور VertiPaq به صورت خودکار داده‌ها را ارزیابی کرده و بهترین ستون را برای مرتب‌سازی انتخاب می‌کند تا RLE بیشترین تأثیر را داشته باشد.

ترکیب الگوریتم ها برای سرعت بیشتر در حالت های مختلف:

وقتی داده های خام شما وارد Power BI می‌شود، VertiPaq مثل یک ارزیاب هوشمند، هر ستون را بررسی می‌کند و ترکیب بهینه‌ای از این سه الگوریتم را روی آن پیاده می‌کند. نتیجه؟ دیتای ۱۰ گیگابایتی شما به شکلی هوشمندانه مچاله شده و به ۱ گیگابایت (یا حتی کمتر) تبدیل می‌شود و حالا به راحتی در حافظه رم سیستم شما جای می‌گیرد.

از تئوری تا عمل؛ چگونه قاتل VertiPaq نباشیم؟

حالا که می‌دانیم VertiPaq چگونه با استفاده از رم و فشرده‌سازی ستونی جادو می‌کند، وقت آن است که به عنوان یک توسعه‌دهنده، وظیفه خود را انجام دهیم. بسیاری از کاربران Power BI بدون اینکه بدانند، با طراحی اشتباه، قاتل جان VertiPaq می‌شوند!

اگر می‌خواهید داشبورد شما در میلی‌ثانیه لود شود، این قوانین طلایی را رعایت کنید:

۱. ستون‌های بلااستفاده را بی‌رحمانه حذف کنید

در دیتابیس‌های رابطه‌ای سنتی (SQL)، اضافه کردن چند ستون اضافه تاثیر چندانی روی سرعت خواندن کوئری‌های خاص ندارد. اما در VertiPaq، هر ستون فضایی از رم را اشغال می‌کند. اگر به ستونی در داشبورد نیاز ندارید، آن را از Power Query یا منبع حذف کنید.

۲. مراقب کاردینالیتی باشید

همان‌طور که دیدیم، فشرده‌سازی VertiPaq تشنه مقادیر تکراری است. ستون‌هایی که مقادیر یکتا و منحصر‌به‌فرد زیادی دارند ، فشرده نمی‌شوند و رم سیستم را می‌بلعند.

• قاتل شماره یک: ستون‌های شناسه (مثل GUID، Transaction ID، شماره فاکتور) اگر در روابط استفاده نمی‌شوند، فوراً آن‌ها را پاک کنید.

• قاتل شماره دو: اعشار بیش از حد! اگر ستون قیمت شما تا 4 رقم اعشار دارد (مثل 125.432)، کاردینالیتی آن به شدت بالاست. اگر نیازی به این دقت ندارید، آن را به دو رقم اعشار یا عدد صحیح گرد کنید تا فشرده‌سازی به طرز چشمگیری بهبود یابد.

۳. تاریخ و زمان را از هم جدا کنید

یک ستون Date/Time در یک جدول که هر ثانیه ثبت می‌شود، در یک سال می‌تواند 365×86400 (بیش از 31 میلیون) مقدار یکتا داشته باشد! فشرده‌سازی این ستون عملاً صفر است.

راه‌حل: این ستون را به دو ستون مجزا تبدیل کنید: یک ستون «تاریخ» (که در سال فقط 365 مقدار یکتا دارد) و یک ستون «زمان» (که در روز نهایتاً86400 مقدار یکتا دارد). با این ترفند ساده، حجم اشغالی در رم به شدت سقوط می‌کند.

// DateTime استخراج تاریخ از ستون 
OrderDate_Only = INT(Sales[OrderDateTime]) 

// DateTime استخراج زمان از ستون 
OrderTime_Only = Sales[OrderDateTime] - INT(Sales[OrderDateTime])

۴. از ابزارهای حرفه‌ای (VertiPaq Analyzer) استفاده کنید

چطور بفهمیم کدام ستون‌ها مقصر کندی و اشغال رم هستند؟ حرفه‌ای‌ها حدس نمی‌زنند، بلکه از ابزار DAX Studio و قابلیت VertiPaq Analyzer استفاده می‌کنند. این ابزار مدل شما را اسکن می‌کند و به شما دقیقاً می‌گوید هر جدول و هر ستون چقدر از حافظه رم را اشغال کرده و درصد فشرده‌سازی چقدر است. با این ابزار می‌توانید مستقیم به سراغ چاق‌ترین ستون‌ها بروید!

جمع‌بندی؛ راز شعبده‌بازی VertiPaq

بیایید به همان ابتدای مقاله برگردیم: «چگونه یک فایل دیتای 10 گیگابایتی با ده‌ها میلیون ردیف، به یک فایل 1 گیگابایتی تبدیل می‌شود و فیلتر کردن آن تنها چند میلی‌ثانیه زمان می‌برد؟»

حالا دیگر شما جواب این معما را به صورت مهندسی و دقیق می‌دانید. هیچ جادویی در کار نیست؛ پشت این سرعت خیره‌کننده، سه ستون قدرتمند معماری شده است:

1. معماری ستونی (Columnar Architecture): به جای خواندن کل ردیف‌ها و اتلاف منابع، VertiPaq تنها ستون‌هایی را می‌خواند که کاربر در داشبورد به آن‌ها نیاز دارد.

2. پردازش درون‌حافظه‌ای (In-Memory Processing): خداحافظی با هارد دیسک‌های کند و انتقال تمام داده‌ها به سریع‌ترین حافظه سیستم یعنی رم ، تا هیچ پردازنده‌ای معطل نماند.

3. فشرده‌سازی بی‌رحمانه (Extreme Compression): استفاده هوشمندانه از الگوریتم‌های Value Encoding، Dictionary Encoding و RLE برای مچاله کردن داده‌ها بر اساس «کاردینالیتی»، تا کوه‌های عظیم دیتا در فضای محدود رم جا شوند.

Power BI تنها یک ابزار برای کشیدن نمودارهای زیبا نیست؛ زیر پوسته این نرم‌افزار، یکی از پیشرفته‌ترین موتورهای پایگاه داده تحلیلی جهان در حال تپیدن است. توسعه‌دهندگانی که نحوه کار VertiPaq را درک می‌کنند، دیگر فقط «داشبوردساز» نیستند؛ آن‌ها مهندسانی هستند که می‌توانند از تک‌تک بایت‌های حافظه و هرتزهای پردازنده، بالاترین عملکرد را استخراج کنند. طراحی درست مدل داده و درک نحوه فشرده‌سازی، مرز بین یک داشبورد کند و غیرقابل استفاده، و یک داشبورد سریع، روان و حرفه‌ای است.