معماری پایگاه داده ها

معماری پایگاه داده ها به چند دسته مختلف تقسیم می شوند

· [1] سیستم های متمرکز

· [2] سیستم های مشتری/خدمتگزار

· [3] سیستم های موازی

· [4] سیستم های توزیع شده

در ادامه به شرح سیستم های مختلف می پردازیم.

1. سیستمهای متمرکز [Silb]

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

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

از مزایای این نوع معماری می توان موارد ریز را برشمرد:

· سادگی در طراحی

. سادگی در استفاده

· عدم نیاز به امکانات سخت افزاری یا نرم افزاری خاص

همچنین از معایب آن می توان به موارد زیر اشاره کرد:

· تک کاربره بودن

· مشکل بودن استفاده در سازمانهای بزرگ

با توجه به گسترش روز افزون استفاده از پایگاه داده ها و همچنین بیشتر شدن حجم اطلاعات و تعداد کاربران سیستم های متمرکز به تدریج جای خود را به معماری هایی با قابلیت های بیشتر برای استفاده گسترده تر دادند.

2. سیستم های مشتری/خدمتگزار [Silb]

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

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

· Back-end : این قسمت وظیفه بررسی و کنترل دسترسی ها، بررسی و بهینه سازی پرس و جو[5] ها و کنترل همزمانی ها و سالم بودن پایگاه داده ها را به عهده دارد.

· Front-end: شامل ابزار هایی برای نمایش و زیباسازی نتایج پرس و جو ها مثل ابزارهای تولید فرم ها و ابزار های گزارش گیری می باشد.

برای ایجاد ارتباط درست میان دو قسمت فوق نیازمند یک لایه و بستر است. این بستر میتواند از دو طریق دستورات SQL و یا API ها برقرار شود.

ر مقایسه این نوع معماری با معماری متمرکز با استفاده از Mainframe ها می توان به مزایای زیر اشاره کرد:

· افزایش میزان کاربری سیستم با توجه به هزینه

· راحت تر شدن گسترش دادن و توزیع کردن منابع

· تولید واسط های کاربر بهتر

· راحت تر شدن نگهداری سیستم

در این نوع معماری، سرورها از لحاظ عملکردی به دو بخش مجزا تقسیم می شود:

· سرورهای داده ای: این نوع سرور ها بیشتر در سیستم های شی گرا مورد استفاده قرار می گیرند

· سرور های تراکنشی: این نوع سرور ها بیشتر در سیستم های رابطه ای مورد استفاده قرار می گیرند

در ادامه به شرح این دو بخش می پردازیم.

در سرورهای تراکنشی که به آنها سرورهای پرس و جو هم گفته می شود روش کار بدین صورت است که درخواست های کاریران به این سیستم ها ارسال می شود و نتیجه در این سرور ها تولید و به کاربر ارسال می شود. درخواست های کاربران به صورت دستورات RPC و دستورات SQL ارسال می شود.برای ارسال و دریافت نیاز به نرم افزار هایی هست مانند ODBC و JDBC که وظیفه ارتباط با سرور و ارسال پرس و جوها و دریافت نتایج را به عهده دارد.

برای پیاده سازی سرورهای تراکنشی از تعدادی پردازه که حافظه مشترک دارند استفاده می شود که معمولا برای بهبود پردازه ها هر کدام از آنها Multithread مورد استفاده قرار می گیرند.

تعدادی از پردازه هایی که حتما یک سرور تراکنشی باید داشته باشد در زیر می بینیم:

· پردازه های سرور: این پردازه ها وظیفه دریافت پرس و جو ها و تولید پاسخ ها را به عهده دارد

· پردازه مدیریت همزمانی: وظیفه مدیریت همزمانی درخواست ها را عهده دار است این امکان یا با استفاده از سمافورهای سیستم عامل و یا با استفاده از روش های مثل Test and Set فراهم آورده می شود.

· پردازه نگارنده پایگاه داده: که وظیفه نوشتن نتایج پرس و جو ها را بر روی دیسک به عهده دارد

· پردازه نوشتن logها: این پردازه اطلاعات نوشته شده روی بافر برای ذخیره به حافظه های پایدار می نویسد.

· پردازه check point: این پردازه مسؤلیت چک کردن پردازشها در مراحل مشخص انجام می دهد

پردازه Monitor Process: وظیفه این پردازه کنترل عملکرد دیگر پردازه ها و در صورت لزوم Recover کردن آن پردازه می باشد.

نوع دیگر سرور ها سرور های دیتا هستند که بیشتر در سیستم های شی گرا استفاده می شود. این سرورها معمولا در شبکه های Lan مورد استفاده قرار می گیرد.

روش کار به این صورت است که داده ها به Client ها برای پردازش منتقل می شود و داده های پردازش شده به سرور برای ذخیره سازی برگردانده می شوند. این سیستم ها بیشتر برای معماری شی گرا استفاده می شوند.

3. معماری موازی [RAMA]

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

ایده اصلی در معماری موازی استفاده از پردازش های موازی در مراحل مختلف تا آنجا که امکان دارد برای بهبود کارایی سیستم است.

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

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

نوع سوم معماری، معماری بدون عنصر مشترک بین پردازنده هاست. هر پردازنده در این روش حافظه و دیسک سخت خود را دارند و هیچ حافظه ای را به اشتراک نمی گذارند. تمامی ارتباطات میان پردازنده ها از طریق شبکه بین آنها ایجاد می شود.

نوع چهارم استفاده از معماری چمد سطی است که درواقع ترکیبی از حالت های فوق است که بخش بخش به هم از طریق روش بدون اشتراک گذاشتن منابع به هم متصل شده اند ولی درون هر بخش پردازنده ها با هم منابع را به اشتراک می گذارند.

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

مشکل ایجاد شده امروزه مورد تحقیق و بررسی بسیاری از علاقمندان قرار دارد و گروه های متعدد روش هایی را برای چگونگی حل این مشکل ارایه داده و می دهند. برای نمومه یکی از روش ها استفاده از مفاهیم “شبکه های عصبی” در حل این مشکل است. [iii]

3.1 اجرای پرس و جو ها در معماری موازی

برای اجرا پرس و جو ها ابتدا باید درخواست پرس و جو ها به درختواره عملیاتی تبدیل شود. در این درختواره می توان با حرکت از پایین به بالا دستوراتی که ورودی های آنها مشخص شده است را به صورت موازی اجرا کنیم. در این روش دستوراتی در درختواره وجود خواهند داشت که هنوز ورودی آنها مشخص نشده است در نتیجه این دستورات تا آماده شدن ورودی های آن اجرا نخواهد شد.

از طرفی از روش پردازش موازی می توان در مرحله دیگر یعنی آماده شدن اطلاعات و اجرای آنها می توان ورودی ها را بخش بندی کرد و با آماده شدن هر بخش عملیات آن اجرا شود و در واقع از روش Pipelining استفاده کرد.

در بخش بندی داده ها روش هایی مانند Round- robin, استفاده از روش Hash و همینطور روش Range partitioning استفاده کرد. روش RR بیشتر برای مواردی که کل داده ها مورد پردازش قرار می گیرند بیشتر استفاده می شود. دو روش دیگر برای مواقعی که تنها بخش های خاصی از داده ها مورد پردازش قرار می گیرند استفاده می شوند.

3.2 عملگرهای تک عملوندی در معماری موازی

در این بخش به چگونگی اجرای عملگرهای تک عملوندی در معماری موازی بدون به اشتراک گذاشتن منابع را مورد بررسی قرار می دهیم.

مرتب سازی:

برای مرتب سازی روش اول بدین گونه است که هر پردازنده داده هایی که در دیسک سخت مریوط به خود را مرتب کنند و در نهایت نتایج را با هم ادغام کنیم.

اما روش کاملتر اینست که در ابتدا داده ها را با توجه به توان هر پردازنده بین پردازنده ها توزیع عادلانه کنیم و در نهایت نتایج را با هم ادغام کنیم. مزیت این روش نسبت به روش اول توزیع درست داده ها و استفاده درست و عادلانه از پردازنده هاست.

-عمل Join

برای عمل Join بین دو رابطه هم از همان روش فوق یعنی تقسیم داده ها و توزیع آنها بین پردازنده ها استفاده می شود. در این روش دو نوع بخش بندی محتمل است. روش اول تقسیم بندی بدون توجه به عامل Join است که در این حالت تمامی داده ها بدون هیچ پیش فرضی تقسیم می شوند. روش دوم استفاده از عامل ارتباط است که در این حالت داده ها را با توجه به عامل ارتباط و با توجه به تعداد پردازنده ها تقسیم می کنیم. پس از تقسیم بین پردازنده ها عمل Join در هرکدام انجام می شود و نتیجه نهایی از اجتماع این نتایج بدست می آید. در هر کدام از پردازنده ها برای عمل Join از روش Hash Join که قبلا توضیح داده شده است استفاده می شود.

یک روش برای بهبود عمل Hash Join اینست که داده ها را به بخش های متعدد تقسیم کنیم و عمل Join هر بخش را به صورت موازی اجرا کنیم

عملگرهای دیگر نظیر عملگرهای گروهی مانند Sum نیز امروزه بحث های مهمی را در این زمینه ایجاد کرده اند و گروه های مختلفی بر روی چگونگی اعمال این عملگرها کار می کنند. یکی از روش های اعمال پردازش موازی اعمال روش بخش بندی و توزیع داده ها مانند روش های فوق است که برای عملگرهای گروهی نیاز به تغییرات و طراحی روش جدید است[iv].

4. معماری پایگاه داده توزیع شده [RAMA]

در این معماری، داده ها در محلهای مختلفی نگهداری می شود. دو خاصیت مهم این نوع از پایگاه داده ها :

1. استقلال داده های توزیع شده[6]: کاربران باید بتوانند بدون اطلاع از محل ذخیره داده ها، از پایگاه داده ها پرس و جو کنند.

2. عدم تفاوت تراکنشهای توزیع شده[7]: کاربران باید بتوانند دقیقاً مشابه روشی که در مورد تراکنشهای محلی(local) عمل می کردند، تراکنشهایی بنویسند که به داده ها در محلهای مختلف دسترسی داشته باشد و آنها را بروز کند.

اگرچه این دو خاصیت مطلوب هستند ولی در عمل در بعضی موارد عملی کردن آنها مهم نیست و حتی وقتی که داده ها در سراسر جهان توزیع شده اند این دو خاصیت مطلوب هم نیستند.

انواع پایگاه داده های توزیع شده:

اگر داده ها توزیع شده باشند و تمام DBMSها از یک نوع بودند، یک سیستم پایگاه داده های توزیع شده همگن داریم. اگر داده ها در محلهای مختلف باشند ولی نوع DBMSها مختلف باشند در این حالت یک سیستم پایگاه داده های توزیع شده ناهمگن داریم. کلید ایجاد سیستم های ناهمگن داشتن استانداردهای مقبول برای پروتکلهای گذرگاهها می باشد.

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

1. سیستمهای مشتری/خدمتگزار: در این معماری وظایف مشتری و خدمتگزار کاملاً از هم جداست و در هر لحظه یک یا چند پردازه مشتری و یک یا چند پردازه خدمتگزار در سیستم موجود است و پردازه های مشتری می توانند به هر یک از پردازه های خدمتگزار پرس و جو بفرستند. این معماری به دلیل سادگی نسبی پیاده سازی و متمرکز بودن خدمتگزار خیلی رایج است. در این سیستم کاربر می تواند با استفاده از واسط کاربر گرافیکی در سیستم مشتری کار کند و نیازی به کار کردن با واسطهای کاربر نامأنوس در سیستم خدمتگزار نیست.

2. سیستم تشریک مساعی خدمتگزار [8]: سیستم مشتری/خدمتگزار به یک پرس و جو اجازه پوشش چند خدمتگزار را نمی دهد زیرا در این صورت مشتری باید پرس و جو را به بخشهای مختلف تقسیم کرده تا در خدمتگزارهای مختلف اجرا شوند و جوابها را با هم ترکیب کند که این کار اصل جدا بودن وظایف مشتری از خدمتگزار را زیر سوال می برد. در سیستم تشریک مساعی مجموعه ای از خدمتگزارها داریم که هر کدام توانایی اجرای تراکنش روی داده های محلی را دارند و با همکاری یکدیگر تراکنشهایی که شامل چند خدمتگزار می شود را اجرا می کنند.

3. سیستمهای میان افزار [9]: محیطی را در نظر بگیرید که در آن تمام خدمتگزاران قابلیت پشتیبانی از پرس و جوهایی که از چند خدمتگزار استفاده می کنند را ندارند، سیستمهای میان افزار برای این محیط از پایگاه داده های توزیع شده طراحی شده است. ایده اصلی در این روش وجود فقط یک خدمتگزار با قابلیت مدیریت تراکنشهای توزیع شده است و سایر خدمتگزاران فقط پرس و جوهای محلی را پاسخ می هند. می توان این خدمتگزار خاص را یک لایه نرم افزاری در نظر گرفت که به آن میان افزار می گویند. این نرم افزار داده ای درا نگهداری نمی کند.

تکرار [10]

تکرار به این معنی است که ما کپی های متعددی از یک رابطه و یا یک قطعه از یک رابطه را ذخیره کنیم. به طور مثال اگر R1 و R2 و R3 ،قطعه های رابطه R باشند، ما ممکن است یک کپی از R1 داشته باشیم ولی مثلاً R2 در دو سایت موجود است و R3 در تمامی سایت ها.

مزایای این روش عبارتند از :

1- افزایش دسترس پذیری داده : اگر یک سایت که شامل یک کپی از یک رابطه است خراب شود ما همان داده را می توانیم در سایت دیگری پیدا کنیم همچنین اگر یک کپی محلی از رابطه هایی که در سایت های دیگر هستند را داشته باشیم کمتر در معرض تهدید از بین رفتن کانال ارتباطی خواهیم بود. Replication دارای دو نوع مختلف همگام[4] و غیر همگام [5] می باشد، تفاوت این دو نوع در روش به روز رسانی کپی های یک رابطه است در زمانی که یک رابطه تغییر می کند.

2- پرس و جو ها با سرعت بیشتری قابل اجرا هستند زیرا یک کپی محلی از داده های ذخیره شده درپایگاه داده موجود است.

3- انجام وظایف بصورت موازی: در موردی كه بیشتر دسترسی های به رابطه r برای خواندن از رابطه r می باشد، چندین سایت می توانند پرس و جو را به صورت موازی پردازش كنند، نسخه های بیشترr شانس اینكه داده مورد نیاز در سایتی كه تراكنش در حال اجراست، یافته شود را بالا می برد از این رو تکرار داده انتقال داده بین سایتها را حداقل می كند.

4- افزایش سربار بروز کردن: سیستم بایستی مطمئن شود كه تمام نسخه های رابطه r سازگار هستند. بنابراین هرگاه r، بروز شود این بروز رسانی بایستی در تمامی سایتهایی كه حاوی نسخه ها هستند منتشر شود. در نتیجه overhead زیاد می شود.

اگر رابطه r ، نسخه برداری شده باشد، یك كپی از رابطه r در دو یا بیش از دو سایت ذخیره می شود. در بیشتر موارد، با تکرار داده کامل روبرو هستیم، به این منظور كه هر نسخه بر روی تمامی سایتها ذخیره می شود. كنترل update های همزمان توسط چندین تراكنش روی داده های نسخه برداری شده مشكلتر از سیستمهای متمركز است. ما می توانیم مدیریت نسخه های رابطه r را با انتخاب یكی از آنها به عنوان كپی اصلی r ساده كنیم.

شفافیت Transparency :

كاربر یك پایگاه داده توزیعی نباید نیاز به دانستن این داشته باشد كه داده ها به صورت فیزیكی در كجا واقع شده اند یا اینكه در یك سایت محلی خاص داده ها چگونه دستیابی می شوند. به این خاصیت data transparency گفته می شود و می تواند چند فرم داشته باشد:

· Fragmentation Transparency: كاربر نیازی به دانستن اینكه یك رابطه چگونه بخش بندی شده است ندارد.

· Replication Transparency: كاربر هر شی داده را منطقا یكتا می بیند. سیستم توزیعی ممكن است یك شی را تکرار كند تا کارایی یا در دسترس بودن داده ها را افزایش دهد. كاربر نگران این موضوع نیست كه كدام اشیاء داده ای تکرار شده اند یا در كجا این نسخه ها قرارگرفته اند.

· Location Transparency: كاربران نیاز به دانستن مكان فیزیكی داده ها ندارند. پایگاه داده توزیعی بایستی قادر به یافتن هر داده ای توسط اعمال شناسه داده در تراكنش كاربر باشد.

Data item ها مثل رابطه ها، بخشها، و نسخه ها بایستی نامهای یكتا داشته باشند. اعمال این خاصیت در پایگاه داده های متمركز آسان است. در یك پایگاه داده توزیعی ما باید مراقب باشیم كه دو سایت از یك نام مشابه برای data item های مجزا استفاده نكنند. یك راه برای این مشكل این است كه تمامی نامها در یك name server مركزی ذخیره شوند. name server كمك می كند تا مطمئن شویم كه یك نام مشابه برای data item های مختلف استفاده نمی شود. ما همچنین می توانیم از name server برای پیداكردن یك data item، طبق نام Item استفاده كنیم.

این راه حل دو مشكل بزرگ دارد:

1- name server می تواند گلوگاه كارایی سیستم ما شود اگر محل data item طبق نامهایشان پیدا شود.

2- اگر name server،مشکلی پیدا کند سیستم از كار می افتد.

رویکردهای دیگر كه بیشتر استفاده می شوند این است كه هر سایت به هر نام كه تولید می كند id خودش را به صورت پیشوند اضافه كند. از این جهت هیج كنترل مركزی نیاز نیست .اما این روش location transparency را نقض می كند .(برخی پایگاه داده ها آدرس اینترنتی خود را به عنوان id سایت استفاده می كنند.)

برای غلبه بر این مشكل سیستم پایگاه داده می تواند مجموعه از نامهای مستعار[11] برای data item ها ایجاد كند.كاربر می تواند به data item توسط نامهای ساده كه توسط سیستم به نامهای كامل ترجمه می شوند مراجعه كند. نگاشت[12] نامهای مستعار به نامهای واقعی می تواند در هر سایت ذخیره شود.با نامهای مستعار كاربر می تواند از محل فیزیكی data item،ناآگاه بماند . همچنین چنانچه مدیر پایگاه داده ها تصمیم به انتقال data item از سایتی به سایت دیگر رفت كاربر دچار مشكل نشود.

مدیریت کاتالوگ توزیع شده[13]:

نام گذاری اشیاء[14] :

در صورتی که یک رابطه قطعه بندی و تکرار می شود ما باید قادر باشیم هر کپی از یک قطعه را به صورت یکتا مشخص کنیم. یک راه حل اینست که یک global unique ID توسط یک name server تولید شود.

مشکلی که این راه حل دارد اینست که اشیاء محل باید بتوانند بدون در نظر گرفتن اسامی سراسری نام گذاری شوند. راه حلی کلی اینست که هر نام چندین فیلد داشته باشد. یک فیلد نام محلی که هر سایت مسئول نام گذاری آن است و یک فیلد Birth Site که سایتی که رابطه را تولید کرده و اطلاعات تمامی Fragment ها و کپی های رابطه را دارد، را مشخص می کند.

توسط این دو فیلد یک رابطه به صورت یکتا نام گذاری می شود که ما به آن global relation name می گوئیم. برای مشخص کردن یک replica ما از ترکیب global relation name و replica ID استفاده می کنیم و به آن global replica name می گوئیم.

ساختار کاتالوگ[15]:

کاتالوگ می تواند بر روی یک سایت مرکزی باشد ولی درصورتی که آن سایت خراب شود کاتالوگ سیستم از بین می رود روش دیگر اینست که در هر سایت یک کپی از کاتالوگ سیستم نگهداری شود. ولی اشکال این روش هم اینست که هر تغییر در کاتالوگ سیستم باید به تمامی سایت های دیگر broadcast شود.

روش دیگر اینست که در هر سایت یک کاتالوگ محلی که شامل اطلاعات کپی داده ها در آن سایت می باشد، موجود باشد همچنین کاتالوگ در سایت مادر (birth site) مسئول اینست که محل تکرار های آن رابطه را ذخیره کند هنگامی که یک نسخه جدید تولید می شود و یا یک نسخه از یک سایت به سایت دیگری منتقل می شود اطلاعات سایت مادر باید به روز رسانده شود. هنگامی که یک رابطه تولید می شود اطلاعات کاتالوگ سایت مادر بررسی می شود.

استقلال داده توزیع شده[16]:

استقلال داده توزیع شده به این معناست کاربران بدون اینکه اطلاعی از تکرار ها و قطعه های یک رابطه باشند قادر به نوشتن پرس و جو های خود باشند. بازسازی رابطه ها وظیفه DBMS می باشد. به عبارت دیگر کاربران هنگام اجرای یک پرس و جو نباید نام کامل اشیاء داده ای را مشخص کنند.

در کاتالوگ سیستم نام محلی هر رابطه ترکیبی از نام کاربر و نام تعریف شده توسط کاربر برای آن رابطه است. هنگامی که کاربر query خود نام یک رابطه را می آورد، DBMS نام کاربر را به این نام اضافه می کند تا نام محلی رابطه را بدست آورد و سپس site-id کاربر را به آن اضافه می کند تا global relation name را بسازد. با جستجو براساس global name درون سایت مادر DBMS می تواند محل تکرار های آن رابطه را پیدا کند.

تراکنش های توزیع شده[17] :

هنگامی که یک تراکنش در یک سایت ثبت می شود، مدیر تراکنش ها در آن سایت، آن تراکنش را به چند زیر تراکنش تقسیم می کند به طوری که هر زیر تراکنش در سایت خاصی اجرا می شود.

بازیابی توزیع شده[18]:

مقوله بازیابی در معماری های توزیع شده پیچیده تر از معماری های متمرکز است زیرا :

1- 2 نوع Failure می توانیم داشته باشیم یکی از Failure کانال های ارتباطی و Failure سایت های دیگری که زیر تراکنش ها در آنها در حال اجرا می باشند.

2- یا تراکنش تمامی سایتها باید Commit شود و یا هیچ کدام از آنهاکه این مسئله توسط Commit Protocol تضمین می شود.

پروتوکلهای اجرای معمولی و ثبت[19] :

در حین اجرا اعمال زیر تراکنش ها در آن سایت ثبت می شود. و نهایتاً Commit protocol بررسی می کند که آیا تمامی زیر تراکنش های آن تراکنش Commit شده اند یا خیر.

به مدیر تراکنش های سایتی که تراکنش به آن تعلق داد Coordinator می گویند و به مدیر تراکنش های سایتهایی که در آنها زیر تراکنش ها اجرا می شوند Subordinator می گویند هنگامی که کاربر تصمیم می گیرد که تراکنش را Commit بکند دستور Commit به Coordinator تراکنش فرستاده می شود و پروتکل two phase commit به صورت زیر اجرا می شود.

1- Coordinator یک پیغام Prepare به تمامی Subordinate ها می فرستد.

2- هنگامی که Subordinate پیغام prepare را دریافت می کند تصمیم می گیرد که آیا تراکنش را abort کند و یا commit کند. سپس در prepare log خود وضعیت را ثبت می کند و یک پیغام بله و یا خیر به Coordinator می فرستد.

3- اگر Coordinator از تمامی Subordinate ها پیغام بله را دریافت کند یک Commit را در فایل log ثبت می کند و پیغام Commit را به تمامی Subordinate ها می فرستد. ولی در صورتی که حتی از یک Subordinate پیغام خیر دریافت کند و یا اینکه اصلاً پیغامی دریافت نکند پیغام abort را به تمامی Subordinate ها می فرستد. و آن را نیز log می کند.

4- هنگامی که یک Subordinate پیغام abort را دریافت می کند abort را در فایل log ثبت می کند و یک پیغام ack به coordinator می فرستد و زیر تراکنش خود را abort می کند. در صورتی که Subordinator پیغام commit دریافت کند نیز آن را log می کند و یک ack به coordinator می فرستد و زیر تراکنش را commit می کند.

5- هنگامی که coordinator از تمامی Subordinator ها پیغام ack را دریافت می کند برای تراکنش end را در فایل log ثبت می کند.

دلیل اینکه به این پروتکل two phase commit می گویند اینست که دو دسته پیغام رد و بدل می شود یک دسته پیغام های نظرسنجی [20] و دسته دوم پیغام های termination.

شروع دوباره بعد از Failure :

هنگامی که یک سایت پس از یک crash دوباره احیا می شود، فرآیند Recovery را فراخوانی می کند. فرآیند recovery و فایل log را می خواند و تمامی تراکنش هایی که هنگام Failure درحال اجرای commit protocol بودند را پردازش می کند.

· اگر برای تراکنش T مایک رکود Commit داریم T را Redo می کنیم و اگر رکورد abort باشد آن را undo می کنیم. در صورتی که این سایت coordinator باشد و از روی رکوردهای log می توان فهمید باید به تمامی Subordinate ها پیغام Commit و یا abort بفرستیم و بقیه کادر همانند قبل ادامه دهیم.

· اگر مایک رکورد Log برای تراکنش T داریم ولی رکورد Commit و abort نداریم آنگاه متوجه می شدیم که این سایت Subordinate است، از رکورد coordinator را شناسائی می کنیم و با آن ارتباط برقرار می کنیم تا وضعیت تراکنش T را بیابیم. هنگامی که coordinator وضعیت تراکنش را پاسخ داد (commit abort) همانند مورد قبل عمل می کنیم.

اگر هیچ گونه log برای تراکنش T نداشته باشیم، مسلماً T برای commit نظر خواهی نکرده است در نتیجه ما می توانیم T را به سادگی abort کنیم. در این حالت ما نمی توانیم مشخص کنیم که سایت Coordinator بوده است یا Subordinate.

اگر سایت Coordinator ، fail شود، Subordinate ها نمی توانند تصمیم بگیرند که آیا زیر تراکش را Commit یا abort بکنند، در این موقعیت T بلاک شده است.

البته subordinate ها در این مرحله می توانند با یکدیگر ارتباط برقرار کنند تا از وضعیت یکدیگر مطلع بشوند و در صورتی که یکی از آنها abort کرده است بقیه نیز abort کنند.

معماری پایگاه داده ها

مطالب مشابه :

پایگاه داده های توزیع شده

مقاله پایگاه داده های سیستم های توزیع شده

مقاله پایگاه داده های سیستم های توزیع شده

معماری پایگاه داده ها

پیاده سازی پايگاه داده توزيع شده توسط Microsoft SQL Server

مقاله پایگاه داده های سیستم های توزیع شده