× بستن تبلیغات
پایان نامه رشته کامپیوتر با موضوع بانک اطلاعاتی توزیع شده
تاريخ : شنبه 2 بهمن 1395 | 22:17 | نویسنده : حسین | بازدید : 20
پایان نامه رشته کامپیوتر با موضوع بانک اطلاعاتی توزیع شده

دانلود کامل پایان نامه رشته کامپیوتر با موضوع بانک اطلاعاتی توزیع شده

دانلود پایان نامه رشته کامپیوتر با موضوع بانک اطلاعاتی توزیع شده

دانلود کامل پایان نامه رشته کامپیوتر با موضوع بانک اطلاعاتی توزیع شده
پایان نامه رشته کامپیوتر
کسب درآمد اینترنتی
دانلود مقاله
دانلود نرم افزار
دانلود اندروید
دانلود پایان نامه
دانلود پروژه
دانلود پرسشنامه
دانلود فایل
دانلود پاورپوینت
دانلود کتاب
دانلود نمونه سوالات
دانلود گزارش کارآموزی
دانلود طرح توجیهی
کار در منزل
دانلود
دسته بندی کامپیوتر و IT
فرمت فایل docx
حجم فایل 319 کیلو بایت
تعداد صفحات فایل 91

بانكهای اطلاعاتی توزیع شده

(گزارش شماره 1)

 

در این گزارش مباحثی كلی در مورد بانكهای اطلاعاتی توزیع شده، معماریهای آنها و مسائل و مشكلاتی كه هنگام حركت از بانكهای اطلاعاتی متمركز به سمت بانكهای اطلاعاتی توزیع شده با آنها روبرو هستیم صحبت شده و تعدادی از كارهای جدیدی كه در زمینه برطرف شدن مشكلات مربوطه انجام شده شرح داده شده است. از جمله یك كار جدیدی كه در زمینه سنكرون كردن داده های كپی شده انجام شده در انتهای این گزارش شرح داده شده است.

فهرست مطالب این گزارش :

1. ذخیره اطلاعات به صورت توزیع شده

2. تراكنشهای توزیع شده

3. مدیریت همزمانی در بانكهای اطلاعاتی توزیع شده

4. مدیریت بن بست

5. سنكرون كردن اطلاعت كپی شده

6. منابع

 

مقدمه

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

 

1. ذخیره اطلاعات به صورت توزیع شده

 

ذخیره اطلاعات به صورت توزیع شده به دو روش Replication یا Fragmentationو یا تركیبی از این دو روش انجام می گیرد. در روش Replication دقیقا یك كپی فیزیكی از اطلاعات در نقاط مختلف سیستم یعنی سایر سایتها ذخیره می گردد ولی در روش Fragmentation‌ اطلاعات به چند بخش یا پارتیشن تقسیم می شود و هر بخش در یكی از سایتها نگهداری می شود. در روش تركیبی اطلاعات به چند بخش تقسیم می شوند و از تعدادی از بخشها و یا همه آنها كپی هایی در سایتهای مختلف نگهداری می شود. روش Fragmentation به دو طریق عمودی و افقی صورت می گیرد. در روش عمودی تقسیم بندی یك Relation روی فیلدها صورت می گیرد. یعنی هر بخش از اطلاعات مشتمل بر تعدادی از فیلدهای Relation است ولی در روش افقی تقسیم بندی روی ركوردهای Relation صورت می گیرد. برای مثال ركوردهای مربوط به ماه خرداد در یك بخش و ركوردهای مربوط به ماه تیر در بخش دیگری ذخیره می گردند. در روش عمودی برای دستیابی به Relation اولیه باید بین بخش های مختلف join بزنیم و در روش افقی برای دستیابی به آن باید از اجتماع استفاده نماییم.

محاسن روش Replication عبارتند از:

-           در دسترس بودن :‌ در شرایطی كه یكی از سایتها بنا به دلیلی از بیفتد حداقل یك سایت دیگر وجود دارد كه می تواند دسترسی به اطلاعات سایت از كار افتاده را امكان پذیر سازد. پس اگر درخواست دسترسی به اطلاعاتی كه مربوط به یك سایت از كار افتاده است، صادر شود، پاسخگویی به این درخواست از طریق سایت دیگری كه replication ای از سایت از كار افتاده را در اختیار دارد امكان پذیر می شود.

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

معایب روش Replication :

1-         افزایش سربار بروزرسانی اطلاعات :‌ به دلیل اینكه از یك داده كپی های مختلفی در سایتهای مختلف وجود دارد در هنگام تغییر دادن این داده باید همه كپی های آن را نیز تغییر داد تا سازگاری در كل سیستم حفظ شود كه این كار سرباز زیادی به همراه دارد.

2-         پیچیدگی در مدیریت همزمانی :‌ به دلیل اینكه از یك داده چند كپی وجود دارد مدیریت Lock در این روش پیچیدگی بیشتری را نسبت به روش متمركز به همراه خواهد داشت.

به طور كلی روش Replication بازدهی عمل خواندن را بالا برده و در دسترس بودن ایجاد می كند ولی برای عمل نوشتن بهینه نیست و سربار اضافی دارد.

 

2. تراكنشهای توزیع شده

 

هر سایتی یك مدیر تراكنش دارد كه وظیفه آن حفظ خصوصیت های ACID در همان سایت است. همچنین هر سایت یك هماهنگ كننده تراكنش (Transaction Coordinator) دارد كه وظیفه آن این است كه در مورد تراكنشهایی كه از آن سایت شروع می شوند:

1-         تراكنش را شروع كند

2-         تراكنش را به تعدادی زیر تراكنش تقسیم كند و آنها را بین مدیران تراكنش سایتهای مربوطه توزیع كند.

3-         تراكنش را به پایان برساند یعنی یا آن را commit كند و یا در صورت commit نشدن تراكنش را در همه سایتهای شركت كننده در آن Abort‌ كند.

 

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

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

 

3. مدیریت همزمانی در بانكهای اطلاعاتی توزیع شده

 

همانطور كه در یك سیستم متمركز برای برقراری همزمانی مابین فراروندها از یك پروتكل Lock‌ استفاده می كنیم در سیستمهای توزیع شده نیز از یك پروتكل Lock استفاده می كنیم با این تفاوت كه این پروتكل برای سیستم های توزیع شده طراحی شده است. برخی از این پرتكل ها عبارتند از Single Lock Manager، Primary Copy، Majority Protocol، Biased Protocol و ...

در Single Lock Manager یكی از سایتها را Lock Manager‌ می كنیم. هر كس كه بخواهد Lock یا Unlock بكند از این سایت درخواست می كند. وقتی سایتی درخواست Lock می كند اگر بتواند Lock را به آن می دهد و در غیر این صورت آن را در صف آن Lock قرار می دهد.

محاسن این روش عبارتند از : سادگی پیاده سازی و مدیریت Deadlock همانند روش متمركز.

معایب این روش عبارتند از :‌ تبدیل سایتی كه مدیر Lock روی آن قرار دارد به گلوگاه سیستم و از كار افتادن كل سیستم در صورت از كار افتادن مدیر Lock.

در Primary Copy به ازای هر داده ای كه از آن چند كپی در سیستم وجود دارد یك Primary Copy داریم و زمانی كه می خواهیم Lock را بگیریم به سراغ Primary Copy  می رویم.

عیب این روش این است كه ممكن است سایتی كه Primary Copy را در اختیار دارد از كار بیفتد ولی كپی آن موجود باشد. در این شرایط به دلیل اینكه Lock فقط باید روی Primary Copy گرفته شود لذا امكان تغییر داده وجود نخواهد داشت در حالی كه باید بتوان داده را در كپی های آن در سایت های سالم تغییر داد.

در Majority Protocol باید برای گرفتن Lock از داده ای كه n كپی از آن وجود دارد حد اقل به سراغ n/2+1 كپی از آن برویم و از آنها Lock‌ بگیریم.

عیب این روش این است كه ممكن است در حین Lock گرفتن روی یك داده هم بن بست به وجود بیاید. فرض كنید می خواهیم روی داده ای Lock بگیریم كه 4 كپی از آن وجود دارد. اگر از دوتا از كپی ها Lock بگیریم و قبل از گرفتن Lock از سومی پروسه دیگری از دوتای دیگر Lock بگیرد در این شرایط دو پروسه منتظر همدیگر می مانند و برای دسترسی به یك داده بن بست به وجود می آید. این در حالی است كه حتی در سیستم های متمركز نیز برای دستیابی به یك داده به تنهایی به این شكل هیچگاه بن بست به وجود نمی آید.

در Biased Protocol بین خواندن و نوشتن تفاوت قائل می شویم. برای خواندن گرفتن Lock از هر كدام از سایتها كافی است اما برای نوشتن باید از تمام كپی ها Lock بگیریم. بازدهی این مكانیزم خود را در سیستمی به خوبی نشان می دهد كه توالی خواندن در آن بیشتر از توالی نوشتن باشد.

 

 

 

4. مدیریت بن بست

 

همانگونه كه در سیستم متمركز از wait for graph استفاده می شود در اینجا نیز از همین روش استفاده می شود با این تفاوت كه در اینجا باید wait for graph مربوط به همه سایتها را جمع كنیم و یك global wait for graph بسازیم. این كار بر عهده یكی از سایتها گذاشته می شود. در global wait for graph به دنبال دور می گردیم. چنانچه دوری پیدا شد یك یا چند تا از تراكنش ها را Abort یا Rollback می كنیم. مشكل اینجاست كه این wait for graph به صورت آنلاین ساخته نمی شود و لذا ممكن است برای مثال دوری تشخیص داده شود در حالی كه یكی از تراكنشها بنا به دلیلی Abort كرده باشد و در واقعیت دوری وجود نداشته باشد و به خاطر تشخیص اشتباهی كه داده شده است یكی از تراكنشهای مفید كه می توانسته به پایان برسد بیهوده Abort شود.

در هنگام به وجود آمدن بن بست برای اینكه بتوانیم بهترین و مناسب ترین تراكنش را برای Abort كردن انتخاب كنیم باید همه تراكنش ها و همه منابعی كه آنها برای commit شدن نیاز دارند را بشناسیم. به این كار مساله پیدا كردن مجموعه مینیمم Abort می گویند كه در[2] به آن اشاره شده است. همچنین برای بالا بردن بازدهی كار می توان از مكانیزم check pointing استفاده نمود. در این روش به جای Abort‌كردن تراكنش در قسمتی از آن check point قرار می دهیم و در صورت لزوم به آن check point ، rollback می كنیم[3] . این روش موجب می شود كه حداقل تا حدودی از انجام دوباره كارهایی كه تا به اینجا انجام شده است جلوگیری شود.

برای رفع مشكل Deadlock سه روش وجود دارد: Deadlock Prevention ، Deadlock Avoidance و Deadlock Detection and Resolution . تجربه نشان داده است كه روشهای اول و دوم راههای مقرون به صرفه ای نیستند و در برخی از موارد نمی توان حتی آنها را عملی نمود. در عمل در جاهایی كه مساله بن بست موضوع مهمی به شمار می رود از روش سوم یعنی Deadlock Detection and Resolution استفاده می شود. چنانچه در یك سیستم توزیع شده مرتبا از این مكانیزم استفده شود به دلیل رد و بدل شدن پیغامهای زیاد، بازدهی سیستم تا حد زیادی كاهش پیدا خواهد كرد و این در حالی است كه ممكن است بن بست وجود نداشته باشد و مكانیزم جستجوی بن بست كار بیهوده ای انجام داده باشد. اگر هم این مكانیزم دیر به دیر استفاده شود، در زمانی كه بن بست وجود دارد، بدون توجه به آن تراكنشهای جدید دیگری ممكن است به سیستم اضافه شوند و deadlock را توسعه دهند و لذا زمان Deadlock Resolution در چنین شرایطی به شدت افزایش خواهد یافت. در [4] ثابت شده است پریود زمانی خاصی جود دارد كه چنانچه عمل جستجوی بن بست مطابق با آن صورت گیرد بازدهی عمل مدیریت بن بست به حداكثر خود خواهد رسید. این توالی بهینه از O((αn)1/3) تبعیت می كند كه در آن α نرخ به وجود آمدن بن بست در سیستم و n تعداد تراكنشها است.

 

5. سنكرون كردن اطلاعت كپی شده

 

در این بخش به بررسی روشهایی كه برای سنكرون كردن تعدادی client كه به یك سرور مركزی متصل می شوند و اطلاعات خود را با آن سنكرون می كنند می پردازیم. فرض كنید تعدادی client داریم كه هر كدام به بخشی از اطلاعات سرور نیاز دارند و این اطلاعات را پس از دریافت از سرور درون خود به صورت Local نگهداری می كنند. هر client بنا به نیاز اطلاعات Local خود را update می كند. در بازه های زمانی خاصی client ها update های خود را به سمت سرور می‌فرستند. update ها حتی می توانند بلافاصله به سمت سرور فرستاده شوند كه این بستگی به مبایل یا غیر مبایل بودن آنها دارد زیرا در سیستم های مبایل اصولا برای هر بار ارسال مقداری انرژی سربار مصرف می شود ممكن است به صرفه این باشد كه اطلاعات هر چند گاه یكبار به سمت سرور ارسال شود. حال فارغ از اینكه سیاست ارسال Update ها از سوی client ها به سمت سرور چگونه است به این مساله می پردازیم كه سرور چگونه client  ها را با هم سنكرون می كند.برای روشن تر شدن مساله فرض كنید client1 و client2 هر دو جدول A را از سرور دریافت كرده و در حافظه محلی خود نگه داشته اند. client1 سه ركورد به جدول محلی خود اضافه می كند و client2 چهار ركورد به جدول محلی خود اضافه می كند و یكی از ركوردهای جدول محلی خود را نیز update می كند بعد از مدتی و یا به طور همزمان با تغییرات هر كدام از client ها اطلاعات update شده خود را به سرور می فرستند. سرور باید بعد از اینكه اطلاعات همه را دریافت كرد، در بازه های زمانی خاصی اطلاعات به روز شده را به همه client ها ارسال كند تا client1 از تغییراتی كه client2 در جدول محلی خود داده بود با خبر شود و برعكس client2 نیز از تغییراتی كه client1 در جدول محلی خود داده بود آگاهی یابد. حال مشكل اینجاست كه عمل ارسال اطلاعات از سرور به client ها چگونه و به چه روشی صورت گیرد تا بهترین بازده را داشته باشد. همانطور كه می دانیم سرور باید اطلاعات بروز شده را به تك تك client ها ارسال كند و چون این عمل به صورت سریال انجام می‌شود لذا افزایش تعداد client ها می تواند مدت زمان عمل synchronization را بسیار طولانی نماید. فرض كنید كه client‌ها مبایل باشند و پهنای باند ارتباطی نیز كم باشد و ارسال اطلاعات به روز شده به سمت هر client حدود 30 ثانیه طول بكشد. در چنین شرایطی چنانچه 100 عددclient داشته باشیم زمان synchronization در بهترین حالت 3000 ثانیه به طول می‌انجامد. البته این در حالتی است كه سرور تمام جدول بروز شده جدید را برای تك تك client ها ارسال كند. علت این امر این است كه سرور نمی داند كه هر كدام از client ها نسبت به قبل چه تغییری كرده اند. اگر بخواهیم كاری كنیم كه سرور قادر باشد این مطلب را بفهمد باید به ازای هر client یك نسخه جدول را روی سرور نگهداری كنیم و این نسخه از جدول همواره با محتوای موجود در حافظه محلی client‌ مطابقت داشته باشد. یعنی هر بار كه سرور اطلاعات update از یك client  دریافت می كند قبل از اینكه update را روی جدول اصلی اعمال كند آن را روی جدول معادل با آن client روی سرور update كند. به این ترتیب همیشه در سمت سرور می دانیم كه جدول محلی client نسبت به جدول سرور چه تغییری باید بكند و لذا فقط تغییرات را برای آن می فرستیم و این عمل صرفه جویی زیادی در پهنای باند می كند و سرعت synchronization را نیز افزایش می دهد ولی این روش نیاز به فضای زیادی روی Hard Disk دارد و در عین حال I/O‌ بیشتری دارد واین فضای مورد نیاز با افزایش تعداد client ها افزایش می یابد.

دانلود پایان نامه رشته کامپیوتر با موضوع بانک اطلاعاتی توزیع شده







ادامه ي مطلب
امتیاز : 1



طبقه بندی: ،
پایان نامه رشته کامپیوتر با موضوع بانک اطلاعاتی توزیع شده,

ارسال نظر برای این مطلب
نام شما:
ايميل :
سايت :
متن نظر :
وضعیت نظر:
کد امنیتی : *