https://virgool.io/feed/@m_53501364 دانشجوی همیشگی دنیای بزرگ داده ها fa 2026-06-16 01:20:08 https://files.virgool.io/upload/users/4859238/avatar/F2uZZ7.jpg?height=120&width=120 https://virgool.io/@m_53501364 https://virgool.io/@m_53501364/%D8%AF%D9%88%D8%B1%D8%A7%D9%87%DB%8C-%D8%AF%D8%B1-power-bi-%D8%AF%D8%A7%D8%AF%D9%87-%D9%87%D8%A7-%D8%B1%D8%A7-%D9%88%D8%A7%D8%B1%D8%AF-%DA%A9%D9%86%DB%8C%D9%85-%DB%8C%D8%A7-%D9%85%D8%B3%D8%AA%D9%82%DB%8C%D9%85-%D9%85%D8%AA%D8%B5%D9%84-%D8%B4%D9%88%DB%8C%D9%85-pslbnwfiszdf در مقاله قبلی با موتور شگفت‌انگیز VertiPaq آشنا شدیم و دیدیم که چگونه با معماری ستونی و فشرده‌سازی بی‌نظیرش، قوانین بازی را در دنیای داده‌ها تغییر می‌دهد. اما یک سوال مهم پیش می آید : آیا Power BI همیشه داده‌ها را به درون رم (RAM) کامپیوتر شما می‌کشد؟ پاسخ کوتاه این است: خیر!تصور کنید با یک دیتابیس عظیم روبرو هستید که ده‌ها ترابایت حجم دارد و هر ثانیه هزاران رکورد جدید به آن اضافه می‌شود. در این حالت، وارد کردن تمام این داده‌ها به Power BI نه منطقی است و نه امکان‌پذیر. اینجاست که Power BI قابلیت انعطاف‌پذیری خود را نشان می‌دهد و مفهومی به نام حالت‌های ذخیره‌سازی (Storage Modes) را به میان می‌آورد.بیایید نگاهی به این ۴ حالت ذخیره‌سازی بیندازیم تا ببینیم Power BI چگونه با منابع داده مختلف رفتار می‌کند.Import Mode و دوران پادشاهی بلامنازع Vertipaqاین همان حالتی است که در مقاله قبل مفصل درباره‌اش صحبت کردیم. در این حالت، شما کل داده‌ها را از منبع اصلی می‌خوانید، فشرده می‌کنید و درون خود فایل داشبورد (همان فایل با پسوند pbix.) ذخیره می‌کنید.چه اتفاقی می‌افتد؟ارتباط داده‌ها با منبع اصلی قطع شده و تمام آن‌ها وارد حافظه (RAM) سیستم شما می‌شوند. حالا موتور VertiPaq کنترل کامل را در دست دارد.سرعت بی‌رحمانه بالا است چون داده‌ها روی رم هستند، پیچیده‌ترین فرمول‌های تحلیلی (DAX) در کسری از ثانیه محاسبه می‌شوند. در این حالت هیچ محدودیتی برای تغییر شکل داده‌ها و مدل‌سازی ندارید.اما دوست منهیچ ناهار مجانی ای وجود ندارد ....شما محدود به میزان رم سیستم خود و محدودیت‌های فضای ابری Power BI هستید. همچنین داده‌های شما ایستا (Static) هستند؛ یعنی برای دیدن داده‌های جدید باید حتماً فرآیند به‌روزرسانی را اجرا کنید.پرس‌وجوی مستقیم (DirectQuery): مشاهده داده‌ها از پشت پنجرهحالا فرض کنید یک دیتابیس 50 ترابایتی جلوی شماست که دائماً در حال تغییر است. در این شرایط، DirectQuery وارد میدان می‌شود. در این حالت، Power BI داده‌های اصلی را درون فایل خود ذخیره نمی‌کند. فایل گزارش شما بیشتر شامل مدل، روابط و طراحی بصری نمودارها است، نه خود داده‌ها.چه اتفاقی می‌افتد؟Power BI در این حالت مانند یک مترجم عمل می‌کند. وقتی کاربر با گزارش تعامل دارد (مثلاً روی یک نمودار کلیک می‌کند)، Power BI آن تعامل را به یک کوئری مناسب (مثلاً SQL) تبدیل کرده و به سرور داده ارسال می‌کند. سرور پردازش را انجام می‌دهد و فقط نتیجه نهایی برای نمایش به Power BI برمی‌گردد.پس بسیار مناسب برای داده‌های بسیار بزرگ. از آنجا که داده‌ها مستقیماً از منبع خوانده می‌شوند، اطلاعات معمولاً به‌روزتر از حالت Import هستند و نیاز به فرآیند بروزرسانی دوره‌ای وجود ندارد.اما یک سؤال مهم پیش می‌آید: اگر گلوگاه سیستم، خودِ سرور داده یا کوئری‌های بهینه‌نشده باشد چه؟در چنین شرایطی، دیگر نمی‌توان با اطمینان گفت «DirectQuery برای داده‌های بزرگ بسیار مناسب است». اگر دیتابیس کند باشد، ایندکس‌ها درست طراحی نشده باشند یا کوئری‌ها سنگین و غیربهینه باشند، هر کلیک کاربر در داشبورد می‌تواند به یک انتظار طولانی تبدیل شود. در واقع در این حالت، داشبورد شما فقط آینه‌ای از همان کندی در سمت دیتابیس خواهد بود.اتصال زنده (Live Connection): اتصال به یک مدل آمادهر بسیاری از سازمان‌های بزرگ، تیم داده از قبل یک مدل تحلیلی استاندارد ساخته است. آن‌ها داده‌ها را پاک‌سازی کرده‌اند، روابط بین جداول را تعریف کرده‌اند و محاسبات تحلیلی را در یک سرور بوسیلهSQL Server Analysis Services (SSAS) آماده کرده‌اند.چه اتفاقی می‌افتد؟در این حالت شما به جای ساختن یک مدل جدید، فقط گزارش خود را به آن مدل آماده متصل می‌کنید. در نتیجه، Power BI بیشتر نقش یک ابزار طراحی گزارش را ایفا می‌کند.از مزایای آن میتوان به ایجاد یک منبع حقیقت واحد (Single Source of Truth) در سازمان اشاره کرد . همه گزارش‌ها به یک مدل مشترک متصل می‌شوند و بنابراین احتمال اختلاف در اعداد و محاسبات بین گزارش‌های مختلف بسیار کمتر می‌شود.اگر در طراحی داشبورد یاد یک معیار یا جدول مهم برای کسب و کار افتادیم چه می شود ؟؟امکان تغییر مدل داده در داخل فایل گزارش بسیار محدود است. معمولاً نمی‌توانید جدول جدیدی اضافه کنید یا روابط بین جداول را تغییر دهید؛ این تغییرات باید در همان مدل مرکزی انجام شوند.مدل‌های ترکیبی (Composite Models) و حالت Dualتا چند سال پیش، شما عملاً باید بین Import و DirectQuery یکی را انتخاب می‌کردید. اما با معرفی Composite Models این محدودیت از بین رفت.در این حالت می‌توانید در یک مدل واحد، ترکیبی از جداول Import و DirectQuery داشته باشید. برای مثال:جداول تاریخی بزرگ را به صورت Import نگه دارید تا تحلیل‌ها سریع انجام شوند.در کنار آن، یک جدول عملیاتی را به صورت DirectQuery نگه دارید تا داده‌های جدید تقریباً به‌صورت لحظه‌ای قابل مشاهده باشند.قابلیتی به نام Dual Mode نیز وجود دارد که معمولاً برای جداول Dimension استفاده می‌شود. در این حالت، Power BI بسته به نوع کوئری تصمیم می‌گیرد که داده‌ها را از مدل درون حافظه بخواند یا مستقیماً به منبع DirectQuery مراجعه کند تا بهترین عملکرد ممکن به دست آید.در نهایت، انتخاب بین این حالت‌ها به یک سؤال ساده برمی‌گردد: داده‌های شما چقدر بزرگ هستند و چقدر باید به‌روز باشند؟اگر سرعت تحلیل برای شما مهم‌تر است، Import معمولاً بهترین انتخاب است ولی اگر حجم داده بسیار بزرگ است یا داده‌ها دائماً تغییر می‌کنند، DirectQuery یا مدل‌های ترکیبی می‌توانند گزینه مناسب‌تری باشند. محمدرضا ظاهری محمدرضا ظاهری Tue, 12 May 2026 01:10:32 +0330 https://virgool.io/@m_53501364/%D9%BE%D8%A7%D8%B1%D8%A7%D8%AF%D9%88%DA%A9%D8%B3-%D8%B3%D8%B1%D8%B9%D8%AA-%D9%88-%D8%AD%D8%AC%D9%85-%D8%AC%D8%A7%D8%AF%D9%88%DB%8C%DB%8C-%D8%AF%D8%B1-%DA%A9%D8%A7%D8%B1-%D9%86%DB%8C%D8%B3%D8%AA-jw6wx3xxqakr-jw6wx3xxqakr فرض کنید یک فایل دیتای خام با حجم 10 گیگابایت و ده‌ها میلیون ردیف اطلاعات فروش در اختیار دارید. این داده‌ها را وارد Power BI می‌کنید. در کمال تعجب، فایل خروجی شما (فایل pbix.) به چیزی حدود 1 گیگابایت (یا شاید کمتر) کاهش پیدا می‌کند.اما قسمت عجیب‌تر ماجرا اینجاست: وقتی در داشبورد خود روی یک نمودار کلیک می‌کنید تا فروش یک محصول خاص را در سه سال گذشته بررسی کنید، نتیجه در کسری از ثانیه روی یک لپ‌تاپ معمولی با رم 8 یا 16 گیگابایت فیلتر می‌شود!چگونه چنین چیزی ممکن است؟اگر سابقه کار با پایگاه‌های داده رابطه‌ای کلاسیک مثل SQL Server را داشته باشید، می‌دانید که اسکن کردن 50 میلیون ردیف برای پیدا کردن یک جمع ساده ، نیازمند درگیری شدید هارد دیسک ، مصرف بالای منابع و صرف زمان است. در دنیای سنتی دیتابیس‌ها، سرعت و حجم دشمنان خونی یکدیگرند. هرچه حجم بالاتر برود، سرعت افت می‌کند؛ مگر اینکه سرورهای گران‌قیمت و سخت‌افزارهای هیولایی وارد میدان شوند.اما Power BI قواعد این بازی را تغییر داده است. در قلب این نرم‌افزار، موتوری می‌تپد که به جای تکیه بر «زورِ بازوی سخت‌افزار»، بر «نبوغِ معماری نرم‌افزار» تکیه دارد.معرفی می‌کنم: موتور تحلیلی VertiPaqVertiPaq که در اسناد فنی مایکروسافت با نام 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 بسیار سریع است، اما دو محدودیت بزرگ دارد:گران است.ظرفیت محدودی دارد. (لپ‌تاپ‌های معمولی معمولاً 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 تا 03 تا 12 تا 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 گیگابایتی تبدیل می‌شود و فیلتر کردن آن تنها چند میلی‌ثانیه زمان می‌برد؟»حالا دیگر شما جواب این معما را به صورت مهندسی و دقیق می‌دانید. هیچ جادویی در کار نیست؛ پشت این سرعت خیره‌کننده، سه ستون قدرتمند معماری شده است:معماری ستونی (Columnar Architecture): به جای خواندن کل ردیف‌ها و اتلاف منابع، VertiPaq تنها ستون‌هایی را می‌خواند که کاربر در داشبورد به آن‌ها نیاز دارد.پردازش درون‌حافظه‌ای (In-Memory Processing): خداحافظی با هارد دیسک‌های کند و انتقال تمام داده‌ها به سریع‌ترین حافظه سیستم یعنی رم ، تا هیچ پردازنده‌ای معطل نماند.فشرده‌سازی بی‌رحمانه (Extreme Compression): استفاده هوشمندانه از الگوریتم‌های Value Encoding، Dictionary Encoding و RLE برای مچاله کردن داده‌ها بر اساس «کاردینالیتی»، تا کوه‌های عظیم دیتا در فضای محدود رم جا شوند.Power BI تنها یک ابزار برای کشیدن نمودارهای زیبا نیست؛ زیر پوسته این نرم‌افزار، یکی از پیشرفته‌ترین موتورهای پایگاه داده تحلیلی جهان در حال تپیدن است. توسعه‌دهندگانی که نحوه کار VertiPaq را درک می‌کنند، دیگر فقط «داشبوردساز» نیستند؛ آن‌ها مهندسانی هستند که می‌توانند از تک‌تک بایت‌های حافظه و هرتزهای پردازنده، بالاترین عملکرد را استخراج کنند. طراحی درست مدل داده و درک نحوه فشرده‌سازی، مرز بین یک داشبورد کند و غیرقابل استفاده، و یک داشبورد سریع، روان و حرفه‌ای است. محمدرضا ظاهری محمدرضا ظاهری Tue, 05 May 2026 22:30:53 +0330