لینک پرداخت و دانلود *پایین مطلب*
فرمت فایل:Word (قابل ویرایش و آماده پرینت)
تعداد صفحه31
فهرست مطالب
مقدمه 1
معماری query optimizing 5
معماری کلی 5
عملکرد ماژول 6
تمرکز روی توضیحات 8 فضای جبری 8
Planner 13
الگوریتم های برنامه نویسی داینامیک 13
الگوریتم های تصادفی 18
سایر استراتژیهای جستجو 19
تخمین زننده اندازه توزیع 21
هیستوگرام 22
سایر تکنیک ها 24
محیط های غیر متمرکز 24
پایگاه داده های موازی 24
پایگاه داده ای توزیع شده 25
خلاصه 26
منابع و مأخذ 27
- مقدمه
ما از query optimizing برای حل مسائل زیادی استفاده می کنیم. زمانی که یک query مطرح می شود، سیستم مدیریت بانک اطلاعاتی (DBMS ) می تواند از روش های مختلفی برای پردازش آن query و رسیدن به جواب استفاده کند. همه آن روش ها در نهایت یک نتیجه را تولید می کنند ولی از نظر هزینه های انجام شده مانند کل زمان مورد نیاز برای اجرا متفاوت اند. چه روشی حداقل زمان را برای اجرا نیاز دارد؟
در یک DBMS ، بهینه سازی query بسیار ضروری می باشد. هزینه انجام دو selection مختلف می تواند بسیار متفاوت باشد. برای مثال به شمای بانک اطلاعاتی زیر که ممکن است در طی این بخش از آن استفاده شود توجه نمایید :
emp (name,age,sal,dno)
dept (dno,dname,floor,budget,mgr,ano )
acnt ( ano,type,balance,bno )
bank ( bno,bname,address )
به Query ساده زیر توجه کنید :
Select name, floor
From emp, dept
Where emp.dno=dept.dno and sal>100k
ویژگیهای زیر را برای محتوا، ساختار و محیط هنگام اجرا در نظر بگیرید :
شرح پارامتر
مقدار پارامتر
تعداد صفحات emp
20000
تعداد tuple های emp
- 000
تعداد tuple های emp که sal>100K
10
تعداد صفحات dept
10
تعداد tuple های dept
100
نشانه های emp
کلاستر B + درخت روی emp.sal
( عمق سه سطحی )
نشانه های dept
کلاستر hashing روی dept.dno
) میانگین طول باکت 1.2 صفحه )
تعداد صفحات بافر
3
هزینه دسترسی به یک صفحه دیسک
ms 20
به سه روش متفاوت زیر توجه کنید :
P1 :
از طریق B + - tree تمام tuple های emp را که شرط emp.sal را ارضا می کنند پیدا می کنیم. برای هر کدام، از hashing index برای یافتن tuple های مناسب dept استفاده می کنیم. ( حلقه های تو در تو، استفاده از index روی هر دو رابطه)
P2 :
برای هر صفحه از dept، کل رابطه emp اسکن می شود. اگر مقدار dno یک tuple از emp با مقدار tuple روی یک صفحه dept برابر باشد و شرط انتخاب روی emp.sal را ارضا نماید، زوج tuple emp – dept در نتیجه ظاهر می شود. ( حلقه های تودرتو در سطح صفحه، بدون استفاده از index )
P3 :
به ازای هر dept tuple ، کل رابطه emp اسکن شده و تمام زوج های emp – dept tuple ذخیره می شوند. سپس، این مجموعه از زوج ها اسکن می شوند و ، به ازای هر کدام، بررسی می شود آیا هر دو dno یک مقدار دارند و آیا شرط روی emp.sal را ارضا می کنند یا خیر. (ساخت عرضی tuple ها، با اسکن ثانویه برای تست پیوند و اتصال)
محاسبه هزینه مورد انتظار I/O این سه طرح نشان می دهد که چه تفاوت بزرگی از نظر کارایی میان این سه روش وجود دارد در صورتی که هر سه یک نتیجه را تولید می کنند. P1 32/0 ثانبه، p2 کمی بیشتر از یک ساعت و p3 بیشتر از یک روز کامل نیاز دارد. Query optimizer تمام انتخاب های ممکن را بررسی می کند، به همین دلیل انتخاب p1 برای پردازش query نباید خیلی سخت باشد.
مسیری که یک query از DBMS تا رسیدن به جواب طی می کند در شکل 1 نشان داده شده است. ماژولهای سیستمی که از طریق آن حرکت می کند عملکردهای زیر را دارد :
- Query parser اعتبار query را بررسی می کند و سپس آن را به یک شکل داخلی ترجمه می کند، معمولاً به صورت یک عبارت calculus یا چیزی معادل آن.
- Query optimizer همه عبارات جبری را که معادل query داده شده است تست کرده و یکی را که به نظر می رسد ارزانتر باشد انتخاب می کند.
- Code generator یا مفسر، طرح تولید شده به وسیله optimizer را به فراخوانی پردازشگر query تبدیل می کند.
- پردازشگر query به صورت واقعی query را اجرا می کند.
پرس و جو ها از طریق کاربران فعال و یا برنامه هایی که به زبان های همه منظوره ای که پرس و جوها را به صورت مخفی درون خود دارند ( مانند c یا c++ ، فرترن یا PL-1 ) ، نوشته شده اند و برای DBMS ارسال می شوند. یک پرس و جوی فعال در مسیری که در شکل 1 نشان داده شده است حرکت می کند. به عبارت دیگر، یک پرس و جوی مخفی در زمانیکه برنامه ای که در آن مخفی است کامپایل می شود ( زمان کامپایل ) بین سه مرحله اول تنها یکبار عبور می کند.
بنابراین، مستقل از تعدا
مقاله در مورد معماری query optimizing
