بهبود کارایی در BI ها به روش های مختلف قابل انجام است. در ادامه به تعدادی از این روش ها اشاره شده است.
· Dimension
1. Dimension های اضافی باعث افزایش حجم Cube و کاهش سرعت پرس وجوها میشود.
2. مانند مورد فوق، Attributeهای اضافی نیز باعث افزایش حجم Cube و کاهش سرعت پرس وجوها میشود
3. انتخاب کلید مناسب برای Dimension: مثلا اگر دو کلید، یکی String و دیگری Integer بتوانند کاندید کلید جدول باشند، کلیدی که از نوع Integer است مناسب تر است. نوع Integer، ضمن اشغال فضای کمتر، زمان کمتری برای فراخوانی نیاز دارد. سریعترین زمان در پردازش جدول Fact زمانی اتفاق میافتد که جدول Fact از طریق یک کلید از نوع Integer به Dimension مرتبط باشد.
4. اجتناب از کلیدهای ترکیبی
5. به طور پیش فرض Analysis Service برای هریک از Attribute ها یک Index تولید میکند. برای کاهش استفاده از منابع و کوتاه کردن زمان Processing، برای ویژگی به ندرت از آن استفاده میشود مقدار AttributeHierarchyOptimizedSate را NotOptimized کنید (بجای FullyOptimized). این تکنیک برای Attribute هایی که صرفا به عنوان Member مورد استفاده قرار می گیرند نیز صادق است. مثلا ممکن است که این Attribute فقط برای تعیین ترتیب نمایش مورد استفاده قرار بگیرد (مانند تاریخ تولد) بنابراین تولید Index برای آن خاصیتی ندارد.
6. Analysis Services به شکل داخلی تمامی Attribute های قابل نمایش (Browsable) را به هم مرتبط می نماید. کاهش تعداد اینگونه Attribute ها به دلیل استفاده بهتر از حافظه برروی کارایی در هنگام محاسبه و پرسوجو موثر است. پس در این شرایط مقدار ویژگی AttributeHierarchyEnabled را غیرفعال نمایید؛ با کاهش اندازه و پیچیدگی در ارتباط عناصر بهبود سرعت پرسوجوها را مشاهده خواهید کرد.
7. تعیین ارتباط سلسلهمراتبی طبیعی (Natural Hierarchy) میان Attribute های یک Dimension تاثیر بسیاری در کوتاه کردن زمان Process و افزایش سرعت پرسوجوها دارد. مثال: کدپستی – شهر – استان – کشور میباشد. (استفاده از مکانیزمهای caching در هنگام استفاده از ایندکس مشترک باعث افزایش سرعت پاسخ دهی گزارش ها می شود)
· Cube
8. هنگام استفاده از Referenced relationship انتخاب وضعیت Materialize باعث می شود که جدول reference dimension و Intermediate dimension به شکل یک Dimension دیده شده و نیازی به Join در هنگام اجرای پرسوجو نباشد.
9. استفاده از ارتباط many-to-many در واقع مانند آن است که دو جدول FACT با یکدیگر Join شدهباشند. براساس guide line باید از ارتباط many-to-many زمانی که intermediate measure group بیش از یک میلیون رکورد دارند اجتناب کرد.
· Partitioning در Cube
o اول: در زمان اجرای Query صرفا Partition یا Partition های توسط Analysis Services مورد استفاده قرار می گیرند که حاوی اطلاعات باشند (به شرط وجود فیلد مبنای Partitioning در محدودکننده های جستجو و البته باید Storage Type برای Cube، MOLAP باشد)
o دوم: در استفاده از Partitioning با بهرهگیری از توانایی پردازش parallel و استفاده همزمان حافظه سرور، علاوه بر افزایش سرعت در پردازش و پرسوجوها درمجموع؛ این امکان فراهم است تا صرفا Partition هایی که تغییر یافته اند را مورد پردازش قرار داد که این افزایش سرعت در پردازش (و کاهش ترافیک شبکه به شرط آنکه سرورهای OLAP و OLTP از هم جداباشند) را به دنبال دارد.
o سوم: این امکان وجود دارد که Storage Type های متفاوتی برای Partition های مختلف درنظر بگیریم. به طور مثال در یک سیستم فروش، برای ماه اخیر (که فعال است) بهتر است Partition از نوع ROLAP باشد و برای ماه های گذشته (بدون تغییر و با حجم زیاد) از نوع MOLAP استفاده شود. توجه: در نوع ROLAP انجام محاسبات در لحظه انجام میشود. (باید نوع ROLAP را بررسی بیشتری کنم )
o استفاده از Aggregation ها باعث افزایش سرعت پاسخگویی Query ها می شود. اما درصورتیکه بجا استفاده نشود باعث افزایش زمان مورد نیاز برای پردازش و افزایش حجم اطلاعات می شود. برای افزایش کارایی (ضمن جلوگیری از مسائلی که خود Aggregation ذاتا به همراه دارد) می توان برروی داده های جدید یا آنهایی که بیشترین مراجعه به آنها می شود (که شما آنها را در یک Partition قرارداده اید) Aggregation های زیادی گذاشت و برای اطلاعاتی که به ندرت به آنها مراجعه می شود Aggregation ی درنظر نگرفت.