معماریهای مختلف پایگاه داده ها

Database Architectures

مهدی سرمدی

اشکان ناصری

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

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

·          سیستم های متمرکز[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]

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

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

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 کنند.

منبع : مجله شبكه
شماره پنجاه ويكم

معاري سرويس گرا (SOA) روشي جديد و در حال تكامل براي ساخت برنامه هاي توزيع شده با Distributed Applicationاست. سرويس ها اجزاي توزيع شده با رابط هاي تعريف شده و مشخص هستند كه پيغام هاي XMIL را پردازش وتبادل مي كنند. با رويكرد سرويس گرا مي توان راه حل هاي را ارائه داد كه به مرز دامنه هاي سازمان، شركت يا دپارتمان محدود نيستند. با استفاده از SOA مي توان در شركتي كه داراي سيستم ها و برنامه هاي كاربردي مختلف روي پلتفرم هاي متفاوت است، يك راه حل يك پارچه سازي با استقلال زياد(loosly coupled) ساخت كه جريان يكنواخت و ناهماهنگ كار را تضمين كند.
هر كس كه از سايت هاي تجارت الكترونيكي به صورت آنلاين خريد كرده باشد، با مفهوم سرويس ها آشنا است. وقتي كه سفارش تا ن را داديد، بايد اطلاعات كارت اعتباري تان را ارايه كنيد كه به طور معمول توسط يك فراهم كننده سرويس ثانويه، تاييد و شارژ مي شود. وقتي كه سفارش پذيرفته شد، شركت سفارش گيرنده با يك شركت فراهم كننده سرويس حمل ونقل فراهم مي كند و در نهايت كالاي شما تحويلتان مي شود. نياز به معماري سرويس گرا از جنبه اي ديگر نيز به نحوه بارزي در برنامه هاي كاربرديeCommerce مشهود است. اگر مثلا جزء(componet) مربوط به پرداخت با كارت اعتباري offline و يا غير فعال باشد،‌قرار نيست كه فرايند فروش متوقف شود. بلكه سفارش ها بايستي پذيرفته شوند وعمليات پرداخت به وقت ديگري موكول شود.
مثل ساير معماري هاي توزيع شده،‌ SOA ساخت برنامه هاي كاربردي با استفاده اجزايي كه در domainهاي جدا از هم را قرار دارند را ممكن مي سازد . SOA از سرويس هاي وب به عنوان نقاط ورود برنامه كاربردي استفاده مي كند كه از لحاظ مفهومي معادل همان اجزاي proxy و stub در سيستم هاي توزيع شده سنتي مبتني بر اجزاء هستند . با اين تفاوت كه در اين جا ارتباط بين سرويس وب و استفاده كننده خيلي آزاداترانه ومستقل تر (loosely coupled) است .به علاوه SOA به خاطر در بر داشتن فاكتورهايي كه اهميت حياتي در تجارت دارند ، نيز منحصر به فرد است . فاكتورهايي نظير: قابليت اطمينان سرويس،‌ جامعيت پيام ، يكساني تراكنش و امنيت پيام . در امور تجاري واقعي نمي توان روي سرويس هايي كه يك درخواست را فقط به خاطر اين كه بتوانند بفهمند،‌ پردازش مي كنند حساب كرد . در امور تجاري به قطعيت و اطمينان بيشتري نياز است. واضح است كه سيستم هاي مختلف ممكن است بعضي اوقات غير فعال باشند و يا پاسخگويي آن ها در دفعات مختلف متفاوت باشد . با وجود اين هيچكدام از اين موارد نبايد براي كنار گذاشتن ياعدم پاسخ به يك درخواست باشند.
علاوه بر آن نبايد دليلي براي كنار گذاشتن يا عدم پاسخ به يك درخواست باشند واضح است كه سيستم هاي مختلف ممكن است بعضي اوقات غير فعال باشند و يا پاسخگويي آن ها در دفعات مختلف ، متفاوت باشد. با وجود اين ،‌هيچ كدام ازاين موارد نبايد دليلي براي كنار گذاشتن يا عدم پاسخ به يك درخواست باشند. علاوه بر آن نبايد هيچ ابهامي در نحوه فراخواني يك سرويس وجود داشه باشد. اگر سيستمي توانايي هاي خود را در قالب سرويسي روي وب ارائه كند. در آن صورت نحوه فراخواني آن سرويس بايد به طور واضح مستند سازي و اعلام شود . بسياري از مسائل دسترس پذيري و مقياس پذيري برنامه هاي كاربردي امروزي در SOA حل شده است كه احتمال نقض آن در هر مر حله اي از جريان كار بسيار زياد است.در SOA فرض بر اين است كه خطا وجود دارد و مي تواند بيفتد ، بنابراين استراتژي هايي براي مثال اگر يك سرويس نتواند يك پيغام را در مرحله اول بپذيرد . اين معماري طوري طراحي شده است كه مجددا پيام را بفرستد . واگر يك سرويس به طور كامل قابل دسترس نباشد، (كه هرگز نبايد در يك سيستم SOA پايدار انفاق بيفتد ) آن وقت معماري طوري طراحي شده است كه روي دادن خطاهايي كه ممنجر به قطع كامل در خواست سرويس مي شود،‌امكان پذير نباشد. SOA قابليت اطمينان را افزايش مي دهد، چون خطاهاي موقت در بخشي از جريان كار نمي توانند كل فرايند تجاري را از كار بياندازند .
به بيان كلي،‌ SOA فرايندي تكامل يافته را ارائه مي نمايد و ازاين نظر مي تواند ان را بلوغ سريس هاي وب و تكنولوژي هاي يكپارچه سازي به حساب آورد . در SOA به اين امر توجه شده است كه سيستم هاي با اهميت حياتي كه بر مبناي تكنولوژي هاي توزيع شده ساخته مي شوند. بايد تضمين هاي خاصي را تامين نمايند . در اين گونه سيستم ها بايد اين اطمينان وجود داشته باشد كه در خواست هاي سرويس به طور صحيح مسير دهي و هدايت مي شوند، در زمان مناسب به آن ها پاسخ داده مي شود، و اين سرويس ها به طور واضح و دقيق سياست هاي ارتباطي و رابط هاي خود را اعلام مي كنند.

سرويس ها چيستند ؟
بسياري از ما آنقدر با تكنولوژي هاي سرويس هاي وب آشنا هستيم كه اغلب در باره اين كه خود سرويس ها واقعا چه هستند، فكر نمي كنيم. در ادامه سه تعريف مي آوريم كه در كنار يكديگر ماهيت يك سرويس راشرح مي دهند:
1-سرويس ها اجزاء مستقلي هستند كه پيغام هاي XML با ساختار مشخص و خوش تعريف(Well-defined) را پردازش مي كنند.
2-سرويس ها داراي رابط هاي خوش تعريف هستند كه به وسيله يك سند مبتني بر XML كه سند Web Service Description Language (WSDL) خوانده مي شود، به اين سند گاهي قرارداد WSDL نيز گفته مي شود. محتويات اين سند،‌عمليات (متدهايي) كه توسط سرويس ارائه مي شود را شرح مي دهد. از جمله اطلاعات مربوط به انواع داده، اطلاعات نحوه اتصال به سرويس، جهت يافتن و ارتباط با عمليات سرويس وب.
3-سرويس ها داراي نقاط انتهايي(Endpoint) هستند كه استفاده كنندگان از و ساير سرويس ها مي توانند بر اساس آدرس سرويس (معمولا URL ) به آن ها متصل شوند. اين همان چيزي است كه ارتباط(جفت شدن) آزادانه خوانده مي شود.

مشخصه هاي سرويس هاي وب و WS-IBasic Profile
برنامه هاي كاربردي SOA نياز به پشتيباني و امكانات زير ساختي زيادي دارند. از جمله امكانات ارسال و دريافت مختلفي ، زير ساخت امنيتي و پشتيباني براي پيام رساني مطمئن. شركت هاي مختلفي، از جمله IBM و مايكروسافت،‌براي ارائه مشخصه هاي استانداردي كه دامنه گسترده تكنولوژي هاي زير ساخت SOA را پوشش دهد، با يكديگر همكاري مي كنند.
متاسفانه مشخصه هاي سرويس هاي وب در محيطي ارايه مي شوند و توسعه مي يابند كه شركت هاي دخيل در آن بيشتر رقيب هستند تا شريك. رقابت هاي ميان شركت ها باعث مي شود كه نتواند بر سر استانداردهاي صحيح و مناسب به توافق برسند. اغلب،‌گروههاي مختلف شركت ها، براي موارد يكسان ، استاندارهاي متفاوتي را دنبال مي كنند . سازمان هاي غير انتفاعي مثل OASIS گرد همايي هايي براي همكاري در ارايه و توسعه استانداردها و مشخصه هاي سرويس هاي وب برگزار مي كنند.( براي اطلاعات بيشتر درباره OASIS به http://www. Oasisopen.org مراجعه كنيد.)

معرفي WS-IBasic Profile
سازمان(WS-I)Web Services Interoperability يك هدف اصلي دارد و آن را ارائه مشخصه هاي استانداردي است كه سرويس هاي وب بتوانند با استفاده از آن روي پلتفرم هاي مختلف با هم تعامل داشته باشند. به بيان ديگر، هدف اين سازمان اين است كه سرويس هاي وب بتوانند با هم كار كنند،‌بدون توجه به اين كه تحت چه سكوي كاري عمل مي كنند و يا با استفاده از چه ابزارهايي ايجاد شده اند . اين مشخصه هاي سرويس هاي وب زمينه هاي گسترده اي را پوشش مي دهند، از پروتكل هاي نقل و انتقال داده تا امنيت كه مجموعه آن ها تحت عنوان پروفايل پايه WS-I جمع آوري شده اند.
مشخصه هاي سرويس هاي وب به طور عمده در گروههاي زير دسته بندي مي شوند:
نقل و انتقال (Tranport )
اين گروه از مشخصه ها، پروتكل هاي ارتباطي براي انتقال داده هاي خام بين سرويس هاي وب را تعريف مي كنند و پروتكل هاي HTTP، HTTPS و SMTP را شامل مي شوند.

پيغام رساني (Messaging)
اين گروه از مشخصه ها تعيين مي كنند كه پيغام هاي XMIL كه سرويس هاي وب تبادل مي كنند. چه فرمتي بايد داشته باشند. اين گروه مشخصه هاي SOAP براي نحوه رمز گذاري پيغام و مشخصه هاي XMIL و XSD براي كلمات كليدي پيغام (vocablury) . را شامل مي شود. مشخصه هاي آدرس دهي سرويس هاي وب نيز در اين گروه قرار دارد . اين مشخصه ها اطلاعا ت مقصد پيغام را از پروتكل نقل و انتقال داده ها، مستقل مي سازد . براي مثال مي توان با استفاده از مشخصه هاي آدرس دهي سرويس هاي وب، چندين مقصد براي يك پيغام XMIL تعريف كرد.

تشريح (Description)
اين گروه شامل مشخصه هايي براي تشريح و توضيح يك سرويس وب است . مشخصه هاي اصلي اين گروه WSDL ( براي قرارداد سرويس ) و XSD ( براي تعريف شماهاي نوع داده) هستند. اين گروه همچنين مشخصه سياست گذاري سرويس وب) WS-Policy )را شامل مي شود كه سياست گذاري هايي كه يك سرويس وب به هنگام ارتباط با يك سرويس گيرنده( كلاينت) اعمال مي كند و تشريح مي كند. براي مثال يك سرويس ممكن است شرايط خاصي براي فراخواني عملياتش داشته باشد. مشخصه WS-Policy به سرويس وب اين امكان مي دهد كه به سرويس گيرنده هاي احتمالي بگويد براي اجراي يك درخواست سرويس موفق بايد از چجه قوانيني تبعيت كنند. نهايتا،‌ در اين گروه مشخصه UDDI براي يافتن ( description) سرويس هاي وب گنجانده شد ه است.

ضمانت هاي سرويس (Service Assurances)
سرويس هاي وب نبايد فقط به سادگي پيغام هاي XMIL را رد و بدل كنند. اين سرويس ها بايد تضميني براي سرويس گيرنده داشته باشند كه اولا پيغام به نحوي ايمن منتقل خواهد شد، ثانيا اين كه سرويس گيرنده بايد حتما پاسخي دريافت كند، حتي اگر در نقطه اي از جريان كار، نقصي پيش آمده باشد. اين گروه از مشخصه ها شامل مشخصه امنيت سرويس وب ( براي تضمين رسيدن پيغام ها) مشخصه پيغام رساني مطمئن سرويس وب ( براي تضمين رسيدن پيغام ها در شبكه هاي ناپايدار و بدون قابليت اطمينان) و تعداد زيادي از مشخصه هاي مربوط به تراكنش است.

تركيب سرويس (Service Composition)
مجموعه گسترده مشخصه هاي WS-I Basic Profile را نمي توان به طور كامل در هر سرويس وب پياده كرد. به همين خاطر، توسعه دهندگان بايد مشخصه هايي كه براي يك سرويس خاص مهم و مناسب هستند را انتخاب و در آن سرويس پياده كنند. براي تامين اين هدف،‌ سرويس ها داراي ويژگي تركيب سرويس هستند . كه به توسعه دهندگان اجازه مي دهد مشخصه هاي مختلف را براي هر سرويس انتخاب كنند و آن ها را در سند WSDL گرد آوري و ثبت كنند.
در ادامه بحث ،تعدادي از مهمترين مشخصه هاي سرويس هاي وب و اهداف آن را بيان مي كنيم:
WS-Seccurity (امنيت سرويس وب ): مشخصه اي جامع كه مجموعه اي از تكنولوژي هاي متداول امنيتي را تحت پوشش دارد، از جمله امضاهاي ديجيتال و رمز گذاري مبتني بر نشانه هاي امنيتي،شامل گواهي هاي X.509
WS-Policy (سياستگذاري سرويس وب ): به سرويس هاي وب امكان مي دهد نيازها، ترجيحات(‌preferences ) و توانايي هاي خود را براساس مجموعه اي از فاكتورها بيان و مستند سازي مي كند كنند. البته تمركز بيشتر با فاكتورهاي امنيتي است . براي مثال سياستگذاري يك سرويس وب مي تواند شامل نيازهاي امنيتي آن، نظير رمز گذاري و امضاي ديجيتال بر اساس يك گواهي X.509 باشد.
WS-Adressing (آدرس دهي سرويس وب): نقاط انتهايي سرويس را در يك پيغام مشخص مي كندو امكان update شدن اين نقاط انتهايي را در مواردي كه پيغام بين دو يا چند سرويس منتقل مي شود، فراهم مي سازد. اين مشخصه به طور گسترده در حال جايگزيني مشخصه قديمي تر WS-Routing (مسير دهي سرويس وب )است.
WS-Messaging (پيغام رساني سرويس وب): امكان پشتيباني از ساير پروتكل هاي كانال ارتباطي، نظير TCP ، را در كنار HTTP براي سرويس وب فراهم مي سازد. اين مشخصه ساخت و توسعه نرم افزارهاي پيغام رساني، از جمله برنامه هاي كاربردي غير همزمان كه با استفاده از SOAP روي HTTP ارتباط برقرار مي كنند، را تسهيل مي كند.
WS-Secure Conversation(مكالمه ايمن سرويس وب): با استفاده از نشانه هاي امنيتي (Security tokens) ارتباطات مورد اعتماد براي جلسات كاري فراهم مي كند.
WS-Reliable Messaging (پيغام رساني مطمئن سرويس وب): مكانيسم هايي براي تضمين اطمينان از رسيدن پيغام،حتي در صورتي كه يك يا چند سرويس در زنجيره سرويس ها قابل دسترس نباشند ، را فراهم مي سازد. اين مشخصه شامل روش هايي براي اعلام رسيدن پيغام است، به طوري كه فرستنده بتواند بفهمد كه آيا گيرنده در دريافت پيغام موفق بوده است يا نه.
با معرفي و ثبت مشخصه هاي جديد و بهبود مشخصه هاي قبلي ، مشخصه هاي سرويس هاي وب دائما در حال تكامل هستند. البته، مجموعه مشخصه هاي پايه اي كه در مقاله بيان شد، احتمالا براي مدتي به عنوان زير بناي اصلي مشخصه هاي سرويس هاي وب باقي خواهند ماند،‌ چرا كه اين مشخصه ها نيازهاي اصلي و بنيادي برنامه هاي كاربردي سرويس گرا را پوشش مي دهند.

معرفي .NET Web Services Enhancements 2.0 for
Web Services Enhancements (WSE) 2.0 مجموعه اي از ابزارهاي مديريت شده تحت .NET را جهت پياده سازي مشخصه هاي سرويس هاي وب براي توسعه دهندگان فراهم آورده است. WSE جهت فراهم آوردن پشتيباني بيشتر زيرساختي، فراتر از آنچه كه در حال حاضر به وسيله چهارچوب كاري دات نت تامين مي شود،‌براي راه حل ها ي SOA ارايه شده است. به كمك WSE همچنين زير ساخت پردازشي براي ميزباني سرويس هاي وبي كه WS-Specification را پياده سازس مي كنند، فراهم مي آورد. براي مثال، WSE به شما امكان مي دهد كه به آساني سرويس هاي وبي بسازيد كه رمز گذاري و امضاهاي ديجيتال را روي درخواست ها و پاسخ هاي سرويس وب اعمال مي كنند. در نهايت،‌WSE يك ابزار بهره وري است كه براي هدايت توسعه دهندگان دات نت به سمت نسخه آينده Indigo طراحي شده است .Indigo از محصولات آينده مايكروسافت است كه پشتيباني يك پارچه براي برنامه هاي كاربردي پيغام رساني و سرويس گرا را هم فراهم مي آورد.
WSE يك محصول در حال تكامل است و در حال حاضر تمام مشخصه هاي سرويس هاي وب را پشتيباني نمي كند، ولي بسياري از مشخصه هاي مهم نظير WS-Seccurity و WS-Policyپشتيباني مي نمايد . به خاطر داشته باشيد كه SOA تحت تاثير مجموعه اي از استانداردها و مشخصه هاي فني است كه خودشان در حال تغيير هستند . نگارش هاي WSE براي هماهنگي با نسخه هاي جديد اين استانداردها و تكنولوژي ها بايد چرخه انتشار انعطاف پذيري داشته باشند. به همين خاطر مايكروسافت تصميم گرفته است كه چرخه انتشار WSE از چرخه انتشار نگارش هاي .NET Framework جدا كند،‌تا بتواند انتشار نگارش هاي اين محصول را با انعطاف پذيري بيشتري برنامه ريزي كند.

خلاصه
در اين مقاله مفاهيم اصلي معماري سرويس گرا (SOA) براي برنامه هاي كاربردي توزيع شده مبتني بر تكنولوژي سرويس هاي وب ،‌معرفي شدند. در اين مقاله بيان كرديم كه يك سرويس، ‌در رابطه با SOA در واقع چه چيزي است و جنبه هاي مهم و اصلي معماري SOA را مرور نموديم. همچنين به طور مختصر WS-I Basic Profile و WS-Specificationو Web Services Enhancementsمعرفي شدند.

• يک نرم افزار يا مجموعه نرم افزاری واحد و متحد الشکل بر روی هر گره اجرا می شود.
• همه ماشینها یک کرنل مشابه را اجرا می کند.
• هر کرنل منابع خود را کنترل می کند

• شفافیت
• انعطاف پذیری
• قابلیت اطمینان
• کارایی خوب
• قابليت گسترش

• در دسترس بودن یک فاکتور مهم مرتبط با اين سيستم ها است.

• طراحی نباید به گونه ای باشد که نیاز به اجرای همزمان کامپوننت های اساسی باشد.
• افزونگی بیشتر داده هاه باعث افزایش در دسترس بودن شده اما ناسازگاری را بیشتر میکند.
• قدرت تحمل نقص(Fault tolerance) باعث پوشاندن خطاهای ایجاد شده توسط کاربر می شود.

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

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

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

• سرور- ایستگاه کاری
• Processor pool
• هیبرید
• یکپارچه

• انتقال پيام Message Passing
• فراخوانی از راه دور رویه ها Remote Procedure Call

• مجتمع سازی داده ها و سرويس ها Encapsulating
• پردازش همزمان
• محافظت داده ها

• دسترسی(Access)
• موقعیت (Location)
• همزمانی(Concurrency)
• کپی برداری داده ها (Replication)
• اشکالات (Failure)
• تبديل پلتفرم (Migration)
• کارآیی (Performance)
• توسعه پذيری (Scaling)

• مدل خادم / مخدوم (Client/Server)
• مدل یکپارچه
• مدل پایپ
• فراخوانی رویه از راه دور(RPC)

• کنترل منابع اختصاصی بر روی یک سرور متمرکز می شود.
• هر سرور به طور بالقوه یک گلوگاه (Bottleneck) است.
• برای بهبود کارآیی، پیاده سازی چندگانه برای توابع مشابه باید انجام شود.

• طبیعت توزیع شدگی برخی از برنامه های دیتا بیس
• افزایش قابلیت اطمینان و در دسترس بودن
• امکان به اشتراک گذاشتن داده ها
• افزایش کارآیی

• دسترسی به سایتها و انتقال جستجو ها و داده ها
• اطلاع از توزیع داده ها و Replication در کاتالوگ DDBMS
• بکارگیری استراتژیهای مناسب برای اجرای پرس و جو ها و ... که دادهایشان در چندين سایت مختلف قرار دارد.
• تصمیم گیری در مورد استفاده از کدامین داده Replicate شده
• سازگار نگه داشتن کپی های داده های Replicate شده
• قابلیت بازیابی داده ها از سایتهایی که دارای مشکل شده اند.
• و ...

1. استقلال محلی
2. عدم وابسته بودن به سایت مرکزی
3. عملیات پیوسته
4. استقلال Location
5. استقلال قطعات(Fragmentation)
6. استقلال Replication
7. پردازش توزیع شده جستجوها
8. مدیریت توزیع شده Transaction
9. استقلال سخت افزاری
10. استقلال سیستم عامل
11. استقلال شبکه
12. استقلال DBMS

• سایتها باید تا حد امکان(بیشترین حد ممکن) مستقل باشند.
• داده های محلی باید در محل ذخیره و مدیریت شوند(با توجه به در نظر گرفتن یکپارچگی و امنیت)
• عملیات محلی باید حتما در خود محل اجرا شوند.
• تمام عملیات در یک سایت باید توسط همان سایت کنترل شود. این بدین معناست که سایت X نباید برای انجام موفقیت آمیز عملیات خود وابسته به سایت Y باشد.
• در برخی موارد، از دست دادن مقدار کمی از استقلال، اجتناب ناپذیر است:

• به هیچ عنوان نباید برای یک سرویس مرکزی به یک سایت وابسته بود. بعنوان مثال نباید دارای یک پردازشگر مرکزی(متمرکز) جستجوها یا مدیریت مرکزی(متمرکز) Transaction بود، چرا که کل سیستم به یک سایت خاصی وابسته می شوند.
• وابسته بودن به یک سایت خاص، حداقل به دو دلیل زیر غیر مطلوب می باشد:

• در یک سیستم توزیع شده، عملیات زیر (در میان سایر عملیات) حتما باید توزیع شده باشند:

• نه تنها کاربران نباید از محلی فیزیکی ذخیره داده ها مطلع باشند، بلکه از لحاظ منطقی باید به تصور کنند که داده ها در سایتهای محلی خودشان قرار دارد.
• ساده کردن برنامه های کاربر و فعالیتهای ترمینال
• اجازه تغییر سکو
• فراهم کردن استقلال Location برای عملیات ساده بازیابی ساده تر از عملیات به روز رسانی می باشد.
• داشتن طرحی برای نام گذاری داده توزیع شده(Distributed Data Naming Scheme) و ایجاد پشتیبانی مناسب از طریق زیر سیستم دیکشنری
• مواردی که باید در مورد کاربران پیاده سازی شود:

• دسترسی های هر کاربر در هر سایت به وی اختصاص داده شود.

• سیستمهای توزیع شده از قطعه قطعه شدن داده ها پشتیبانی می کنند، منوط به اینکه یک رابطه خاص قابلیت تقسیم به قسمتهای مختلف برای ذخیره در محلهای فیزیکی گوناگون را داشته باشد. سیستمی که این قابلیت را داشته باشد، از استقلال قطعات نیز پشتیبانی می کند.
• کاربران باید از لحاظ منطقی به گونه ای تصور کنند که گویا اصلا داده ها در قسمتهای مختلف ذخیره نشده اند.
• از دلایل قطعه قطعه شدن داده ها، می توان به افزایش کارآیی اشاره کرد.
• قطعه قطعه شدن افقی(Select)
• قطعه قطعه شدن عمودی(Project)
• قطعه قطعه شدن باید در متن یک پایگاه داده توزیع شده تعریف شود.
• استقلال قطعات همانند استقلال Location باعث ساده تر شدن برنامه های کاربر و فعالیتهای ترمینال می شود.
• داده هایی که به کاربران نمایش داده می شود، از ترکیب منطقی قطعات مختلف (به واسطه الحاقها(Joins) و اجتماعات(Unions) مناسب)به دست می آید.

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

• مشکل انتشار به روز رسانی
• استقلال Replication   همانند استقلال قطعات و استقلال Location باعث ساده تر شدن برنامه های کاربر و فعالیتهای ترمینال می شود.
• رو نوشت از داده ها (Snapshots)

• یکی از مهمترین و حیاتی ترین نکات در مرود سیستمهای پایگاه داده توزیع شده، انتخاب استراتژی مناسب برای پردازش توزیع شده جستجو(Query) می باشد.
• پردازش جستجو در سیستم های توزیع شده شامل موارد زیر می باشد:
  • عملیات محلی ورودی و خروجی(I/O) و CPU در سایتهای مجزا
  • تبادل اطلاعات میان سایتهای فوق الذکر
• Query Compilation Ahead Of Time
• Views That Span Multiple Sites
• integrity constraints that within DDBS that span multiple sites

• دو نکته مهم برای مدیریت Transaction، کنترل بازیابی(Recovery Control ) و کنترل سازگاری(Consistency Control) می باشد که نیاز به اعمال و دقت بیشتری در محیط های توزیع شده دارند.
• در یک سیستم توزیع شده، یک Transaction می تواند باعث اجرای کد در چندین سایت شده که همین امر خود می تواند باعث عملیات به روز رسانی در سایتهای مختلف شود.
• هر Transaction را می توان شامل چندید Agent در نظر گرفت که هر Agent، فرآیندی است که از طرف Transaction  در سایت به خصوصی اجرا می شود.

لینک کتاب گرید از گروه گرید دانشگاه آزاد تفرش
www.tiziran.com/download/grid/GridComputing.pdf

مقاله گرید
www.tiziran.com/pirahansiahGrid.pdf

وبلاگ استاد عزیزم حامد سلیمی پور رودسری سرپرست گروه گرید
www.xgrid.blogfa.com

آموزش اوراکل 11

www.tiziran.com

آموزش جاوا

www.learnjava.ir

آموزش پردازش تصویر
www.pirahansiah.com