توصیه‌هایی برای استفاده از DirectQuery

این بخش راهنمایی‌های کلی در مورد نحوه استفاده موفق از DirectQuery با در نظر گرفتن تأثیرات آن را ارائه می‌دهد.

عملکرد منبع داده‌ی زیرین

بررسی کنید که ویژوال‌های ساده در کمتر از پنج ثانیه تازه‌سازی شوند تا یک تجربه تعاملی مناسب فراهم شود.  اگر ویژوال‌ها بیش از 30 ثانیه برای تازه‌سازی زمان نیاز دارند، احتمالاً مشکلات بیشتری پس از انتشار گزارش ایجاد خواهد شد و راه‌حل قابل اجرا نخواهد بود.

اگر پرس‌وجوها کند هستند، باید بررسی کنید که چه نوع پرس‌وجوها به منبع داده ارسال شده و علت کندی عملکرد چیست.

 استانداردهای عمومی پایگاه داده عبارتند از:

•  برای بهبود عملکرد، روابط را بر پایه ستون‌های عدد صحیح (Integer columns) قرار دهید، نه بر اساس اتصال ستون‌هایی با انواع داده دیگر.
• ایجاد ایندکس‌های مناسب – معمولاً این کار شامل استفاده از ایندکس‌های ستونی (Column store indexes) در منابعی است که از آن‌ها پشتیبانی می‌کنند، مانند SQL Server.
• به‌روزرسانی آمارهای ضروری (Statistics) در منبع داده.

طراحی مدل در DirectQuery

هنگام تعریف مدل داده در Power BI، توصیه‌های زیر را دنبال کنید:

• از پرس‌وجوهای پیچیده در Power Query Editor اجتناب کنید.
• Power Query Editor یک پرس‌وجوی پیچیده را به یک SQL Query واحد ترجمه می‌کند.
• این پرس‌وجوی واحد در زیرانتخاب (Subselect) هر پرس‌وجویی که به آن جدول ارسال می‌شود، ظاهر می‌شود.
• اگر این پرس‌وجو پیچیده باشد، ممکن است عملکرد تمام پرس‌وجوهای ارسال‌شده را تحت تأثیر قرار دهد.
• برای دریافت پرس‌وجوی SQL واقعی برای مجموعه‌ای از مراحل، روی آخرین مرحله در زیر Applied Steps راست‌کلیک کرده و View Native Query را انتخاب کنید.
• مقادیر اندازه‌گیری (Measures) را ساده نگه دارید. 
• در ابتدا، محدود کردن Measures به تجمیع‌های ساده توصیه می‌شود.
• اگر عملکرد Measures رضایت‌بخش بود، می‌توانید Measures پیچیده‌تر تعریف کنید اما به عملکرد آن‌ها توجه داشته باشید.
• از ایجاد روابط بر روی ستون‌های محاسبه‌شده اجتناب کنید. 
• در پایگاه‌های داده‌ای که نیاز به پیوند چندین ستون دارند، Power BI اجازه تعریف روابط بر اساس چندین ستون به‌عنوان کلید اصلی یا کلید خارجی را نمی‌دهد. 
• راه‌حل متداول، ادغام ستون‌ها با استفاده از یک ستون محاسبه‌شده (Calculated Column) است.  اما در DirectQuery این روش باعث اجرای اتصال بر روی یک عبارت می‌شود و معمولاً استفاده از ایندکس‌ها را غیرممکن کرده و عملکرد را کاهش می‌دهد. 

راه‌حل جایگزین: مادی‌سازی (Materialize) چندین ستون به یک ستون در منبع داده‌ی اصلی.

• از ایجاد روابط بر روی ستون‌های “uniqueidentifier” اجتناب کنید.
•  Power BI به‌طور بومی از نوع داده uniqueidentifier پشتیبانی نمی‌کند.
• تعریف یک رابطه بین ستون‌های uniqueidentifier باعث ایجاد پرس‌وجو با اتصال شامل Cast می‌شود.
• این رویکرد معمولاً باعث کاهش عملکرد می‌شود.

راه‌حل جایگزین: مادی‌سازی ستون‌ها با یک نوع جایگزین در منبع داده‌ی اصلی.

• ستون “to” در روابط را مخفی کنید.
• این ستون معمولاً کلید اصلی در جدول مقصد است.
• اگر مخفی شود، در لیست فیلدها نمایش داده نمی‌شود و نمی‌توان از آن در ویژوال‌ها استفاده کرد.
• اغلب ستون‌هایی که روابط بر اساس آن‌ها تعریف می‌شوند، در واقع ستون‌های سیستمی هستند، مانند کلیدهای جایگزین (Surrogate Keys) در انبار داده.
• بهترین روش همچنان مخفی کردن این ستون‌ها است.

اگر ستون دارای ارزش معنایی باشد، یک ستون محاسبه‌شده معرفی کنید که مقدار آن برابر با کلید اصلی باشد، مثلاً:

ProductKey_PK (Destination of a relationship, hidden)

ProductKey (= [ProductKey_PK], visible)

ProductName …

بررسی ستون‌های محاسبه‌شده و تغییرات نوع داده

هنگام استفاده از DirectQuery در مدل‌های ترکیبی (Composite Models)، می‌توانید جداول محاسبه‌شده (Calculated Tables) را استفاده کنید.  این قابلیت‌ها لزوماً مضر نیستند، اما باعث می‌شوند که پرس‌وجوها شامل عبارات به جای ارجاع ساده به ستون‌ها باشند.  این امر می‌تواند منجر به عدم استفاده از ایندکس‌ها در پرس‌وجوها شود و باعث کاهش عملکرد گردد.

اجتناب از فیلترگذاری متقابل دوطرفه

از فیلترگذاری متقابل دوطرفه (Bidirectional Cross Filtering) در روابط پرهیز کنید.  استفاده از Bidirectional Cross Filtering ممکن است باعث ایجاد پرس‌وجوهایی شود که عملکرد مطلوبی ندارند.

تنظیم Assume Referential Integrity

از گزینه “Assume Referential Integrity” برای بهبود عملکرد پرس‌وجوها استفاده کنید.  این تنظیم در روابط به پرس‌وجوها امکان می‌دهد که از INNER JOIN به‌جای OUTER JOIN استفاده کنند.  این روش معمولاً عملکرد پرس‌وجوها را بهبود می‌بخشد، اما اثربخشی آن به ویژگی‌های خاص منبع داده بستگی دارد.

اجتناب از فیلترگذاری تاریخ نسبی در Power Query Editor

از فیلترگذاری تاریخ نسبی (Relative Date Filtering) در Power Query Editor استفاده نکنید.  در Power Query Editor امکان تعریف فیلترگذاری تاریخ نسبی وجود دارد، مثلاً می‌توانید ردیف‌هایی را که تاریخ آن‌ها در ۱۴ روز گذشته است فیلتر کنید.  این روش ممکن است باعث ایجاد پرس‌وجوهایی شود که عملکرد خوبی ندارند.

حداکثر تعداد اتصالات

شما می‌توانید حداکثر تعداد اتصالاتی را که DirectQuery برای هر منبع داده‌ی اصلی باز می‌کند، تنظیم کنید، که تعداد پرس‌وجوهای همزمان ارسال شده به هر منبع داده را کنترل می‌کند.

DirectQuery به طور پیش‌فرض حداکثر 10 اتصال همزمان را باز می‌کند. برای تغییر حداکثر تعداد برای فایل فعلی در Power BI Desktop، به File > Options and Settings > Options بروید و DirectQuery را در بخش Current File در پنل سمت چپ انتخاب کنید.

این تنظیم فقط زمانی فعال می‌شود که حداقل یک منبع DirectQuery در گزارش فعلی وجود داشته باشد. این مقدار برای همه منابع DirectQuery و هر منبع DirectQuery جدیدی که به آن گزارش اضافه شده است، اعمال می‌شود.

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

هنگامی که گزارشی را در سرویس Power BI منتشر می‌کنید، حداکثر تعداد پرس‌وجوهای همزمان به محدودیت‌های ثابت تعیین شده در محیط هدف که گزارش در آن منتشر می‌شود نیز بستگی دارد. Power BI، Power BI Premium و Power BI Report Server محدودیت‌های متفاوتی را اعمال می‌کنند.

محدودیت‌های اتصال

جدول زیر محدودیت‌های بالای اتصالات فعال در هر منبع داده را برای هر محیط Power BI فهرست می‌کند. این محدودیت‌ها برای منابع داده ابری و منابع داده داخلی مانند SQL Server، Oracle و Teradata اعمال می‌شود.