خردمند کسی است که از همه می آموزد.

با درود فراوان به همه ی همراهان عزیز.

صبح زیبای پاییزیتون پر از شادی و نشاط و آرامش🌷

ضمن عرض خوش آمد گویی به اعضای جدید کانال از جمله:

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

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

با تشکر از توجه شما🌷

گلناز اردشیری

@BigDataTechnology

مکانیسم ذخیره سازی توزیع شده برای کلان داده ها:
سیستم فایل ها:


فناوري و دانشي را در نظر بگيريد که در پس زمينه صفحه اصلي موتور جست‌وجوي گوگل مورد استفاده قرار مي‌گيرد. در پس الگوريتم‌ها و ساير قابليت‌هايي که امکان جست‌وجو بر مبناي متن وارد شده را فراهم مي آورد، يک مرکز داده بزرگ نيز وجود دارد. در اين مرکز داده،کپي متني و کاملي از هر آنچه در اينترنت وجود دارد ذخيره شده است. در همان زمان که شما و هزاران نفر ديگر در حال وارد کردن متن مورد نظر و جست‌وجوي اينترنتی هستيد، اين کپي عظيم از داده نيز به طور متناوب با داده‌هاي جديد به‌روزرساني مي‌شود. به موازات همه اين فرآيندها، داده‌هاي موجود توسط پردازند‌ه‌های هزاران سرور مجزا در حال پردازش است. هر يک از اين پردازنده‌ها مي‌تواند هر کاري، از انتخاب آگهي متناسب با متن مورد جست‌وجوي شما تا فرآيند مرتب‌سازي جهت تعيين ترتيب نمايش آن‌ها را انجام دهد.
سیستم ذخيره‌سازي استفاده شده در موتور جست‌وجوي گوگل بايد بتواند در هر روز به ميليون‌ها درخواست خواندن و نوشتن اطلاعات پاسخ دهد. اين درخواست‌ها توسط پردازش‌‌هايي ارسال مي‌شود که به صورت مستقل روي هزاران سرور، در حال اجرا هستند. فرآيند پشتيبان‌گيري يا نگه‌داري از سيستم، تحت هيچ شرايطي نبايد منجر به غير‌فعال شدن اين سرويس‌ها شوند. از طرف ديگر اين مجموعه داده‌اي ناچار است به صورت بي‌وقفه در حال رشد و گسترش باشد. اين قابليت از آن جهت اهميت دارد که زيرساخت ذخيره‌سازي بايد بتواند صفحات يافته شده توسط روبات‌هاي جست‌وجو‌گر اينترنت را که هر روز بر تعداد آن‌ها افزوده مي‌شود، ذخيره کنند. در حال حاضر، روبات‌هاي موتور جست‌وجوي گوگل روزانه بيش از بیست پتابايت داده را پردازش مي‌کنند. شرکت گوگل براي پاسخ‌گويي به چنين نيازي نمي‌تواند حتي به قوي‌ترين معماري‌هاي ذخيره‌سازي که به صورت معمول در ساير پروژه‌هاي بزرگ استفاده مي‌شوند تکيه کند. ساير غول‌هاي دنياي وب و ابرشرکت‌هاي ارائه دهنده محيط پردازش ابري و مراکز داده فوق‌العاده بزرگ نيز با چالش‌هاي مشابهي روبه‌رو هستند. از جمله اين ابر شرکت‌ها مي‌توان به آمازون و شبکه‌های اجتماعی اشاره کرد. بيشتر مراکز داده سعي دارند تا فرآيند مقياس‌پذيري فضاي ذخيره‌سازي داده را از طريق افزودن به ظرفيت‌هاي ديسک‌ها و تعداد سرورهاي پايگاه‌داده و سرورهاي متصل به رسانه‌هاي ذخيره‌سازي، به انجام برسانند. اما اين رويکرد معمولاً با شکست مواجه مي‌شود زيرا محدوديت‌ها و التزام‌هاي موجود در محيط ابري جهت رسيدن به سطح کارايي و عملکرد بالا، چالشي است که روش مذکور نمي‌تواند پاسخ‌گوي آن باشد. در محيط ابري ممکن است در هر زمان با هزاران کاربر فعال مواجه باشيم که بايد به داده‌ها دسترسي داشته‌باشند و داده‌هايي که بايد در هر لحظه نوشته يا خوانده شوند، از چندين هزار ترابايت فراتر می‌رود.

اينجا مسئله چيزي غير از سرعت خواندن و نوشتن ديسک است. وقتي جريان داده در سطح شبکه ذخيره‌سازي به اين حد مي‌رسد، عملکرد و بازدهي شبکه ذخيره‌سازي داده است که مشکل‌ساز مي‌شود. حتي در صورت استفاده از بهترين سرورها و رسانه‌هاي ذخيره‌سازي، باز هم ممکن است تجهيزات SAN مورد استفاده، تبديل به گلوگاهي در مسير دسترسي و پردازش داده، شوند. معمولاً در اين وضعيت، با مشکلات مرتبط با محدوديت در مقياس‌پذيري سيستم مواجه مي‌شويم. با در نظر گرفتن سرعت افزايش ظرفيت مراکز داده در شرکت‌هاي بزرگ مبتني بر وب (براي نمونه به گفته جيمز هميلتون، نايب رئيس آمازون، در حال حاضر اين شرکت، روزانه به اندازه کل فضاي مورد استفاده توسط شرکت در سال ۲۰۰۱ ، به ظرفيت مرکز داده خود مي‌افزايد.) با استفاده از روش‌هاي معمولي که در مراکز داده کنوني براي ارتقاي ظرفيت به کار مي‌رود،‌هزينه‌هاي نرم‌افزاري، سخت‌افزاري و مديريتي اين فرآيند، بسيار زياد خواهد بود.

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

گوگل، بيشتر جزئيات تکنيکي معماري GFS را به دلايل کاملاً مشخص محرمانه نگاه داشته‌است. اما در مقاله‌‌اي که در سال ۲۰۰۳ توسط سان‌جاي گماوات (Sanjay Ghemawat) عضو گروه تحقيقاتي شرکت گوگل، هوارد گوبيوف (Howard Gobioff) مهندس پايه و شان‌تک‌ليونگ (Shun-Tak Leung) عضو گروه مهندسان ارشد منتشر شد، اين‌ طور عنوان شده که سيستم‌فايلي GFS با در نظر گرفتن اولويت‌هاي بسيار خاصي طراحي شده است. اين مقاله عنوان مي‌کند که هدف از طراحي GFS، تبديل تعداد زيادي از سرورها و هاردديسک‌هاي ارزان‌قيمت، به مجموعه‌اي است که بتواند صدها ترابايت داده را ذخیره و مديريت کرده و در صورت بروز خطا يا نقص‌های سخت‌افزاري بتواند مشکل به وجود آمده را برطرف کند. اين سيستم‌فايلي به طور سفارشي و متناسب با روش جمع‌آوري و خواندن داده توسط گوگل،‌ طراحي شده است و مي‌تواند به چندين برنامه امکان دهد تا به طور همزمان حجم‌ بزرگي از داده‌ها را به سيستم بيافزايند و با بالاترين سرعت ممکن به داده‌ها دسترسي داشته‌باشند.

نحوه عملکرد GFS بسيار شبيه روش انجام فرآيند RAID5 در رسانه‌هاي ذخيره‌سازي است که در آن داده به صورت تکه‌تکه در سطح تمام ديسک‌ها ذخيره مي‌شود تا جلوي از دست رفتن داده، گرفته شود. در GFS نيز فايل‌ها به صورت تکه‌هایي با اندازه ثابت در سطح خوشه‌اي از سرورها کپي شده و توزيع مي‌شود. از آنجا که در اين روش از کامپيوترها و هاردديسک‌هاي ارزان قيمت استفاده مي‌شود، ممکن است اين سرورها به طور ناخواسته با مشکل مواجه شوند. در نتيجه GFS،‌ طوري طراحي شده‌است که بتواند بدون از دست دادن حجم قابل توجهي از داده براي اين گونه خطاها، راهکار ارائه دهد. اما شباهت‌هاي مکانيزم RAID 5 و GFS به همين موارد ختم مي‌شود. در GFS مي‌توان سرورهاي مورد بحث را در سطح شبکه توزيع کرد. به اين ترتيب، سرورها مي‌توانند در يک يا چند مرکز داده توزيع شوند و تصميم‌گيري در اين مورد به کاربرد داده بستگي دارد. GFS براي آن طراحي شده تا بتواند حجم عظيمي از داده را به صورت گروهي، پردازش کند. آنچه که در اين فرآيند اهميت دارد، خواندن سريع داده است و فاکتورهايي نظير سرعت دسترسي به يک قسمت خاص از فايل يا سرعت نوشتن داده در سيستم‌فايلي اهميت چنداني ندارد. GFS براي سريع کار کردن، ‌داده‌ها را به صورت تکه‌‌تکه و از سطح چندين رسانه مي‌خواند يا مي‌نويسد. هزينه دستيابي به سرعت بالا در سيستم‌فايلي GFS، نوشتن و خواندن قطعه‌بندي شده روي چندين ديسک است. به گفته گماوات در مقاله ذکر شده «نوشتن قطعات کوچک داده در آدرس‌هاي متعدد و متفاوت توسط اين سيستم‌فايلي پشتيباني مي‌شود اما لزوماً کارايي بالايي ندارد.» ماهيت توزيع شده GFS و حجم بسيار زياد داده‌اي که توسط اين سيستم‌فايلي مديريت مي‌شود (ميليون‌ها فايل که حجم بيشتر آن‌ها بالاي صد مگابايت و معمولاً در محدوده گيگابايت است.) به معني هزينه‌ها و اثرات جانبي مشخصي است و اين اثرات جانبي باعث مي‌شود تا سيستم‌فايلي GFS براي نصب روي يک سرور مستقل و منفرد، گزينه نامناسبي به شمار آيد. از آنجا که صدها نفر ممکن است به طور همزمان در حال نوشتن يا خواندن از يک فايل باشند، لازم است که سيستم‌فايلي تا حد ممکن از فرآيند تکه‌تکه کردن و ايجاد قطعات کوچک داده پشتيباني کرده و بدون تأثير بر ساير برنامه‌ها از فرآيند بازگرداندن و معکوس کردن فرآيندهاي ناموفق نیز، پشتيباني کند. همچنين اين سيستم‌فايلي بايد جامعيت داده‌ها را تضمين کرده و سربار ناشي از فرآيند همزمان‌سازي را نيز به حداقل برساند تا از هر گونه کاهش کارايي ناشي از انجام اين‌گونه فرآيندها، جلوگيري شود. GFS از سه لايه تشکيل شده‌است: يک کلاينت GFS که وظيفه آن پاسخ‌گويي به درخواست داده از جانب برنامه‌ها است؛ يک مرجع که با استفاده از يک انديس مقيم در حافظه به رديابي فايل‌هاي داده و مکان قطعات هر فايل داده در حافظه مي‌پردازد. المان بعدي اين معماري خود سرورهاي ارائه خدمات است که “chunk servers” نام دارند.

در ابتدا به منظور حفظ سادگي اين روش،از يک مرجع به ازاي هر کلاستر يا خوشه استفاده مي‌کرد. به اين ترتيب وظيفه سيستم اين بود که تا حد ممکن بار کاري پردازش مرجع را در جهت تعيين روش دسترسي به داده، به حداقل برساند. اما اکنون گوگل يک سيستم مرجع توزيع شده فراهم کرده است که مي‌تواند مديريت صدها مرجع را انجام دهد و هر يک از اين مرجع‌ها نيز مي‌تواند حدود صد ميليون فايل را مديريت کند. زماني که کلاينت فايل سيستم GFS، درخواستي را به منظور دسترسي به يک فايل داده خاص دريافت مي‌کند، درخواستي را براي سرور مرجع ارسال مي‌کند تا آدرس فايل را به دست آورد. سرور مرجع آدرس يکي از کپي‌هاي داده مورد نظر را اعلام مي‌کند و کلاينت نيز به طور مستقيم با آن chunk server تعامل مي‌کند و به اين ترتيب فرآيند نوشتن و خواندن داده انجام مي‌شود. سرور مرجع ديگر در اين فرآيند نقشي نخواهد داشت، مگر آن‌که بخشي از اين فرآيند و عملکردها، با خطا مواجه شود. سيستم‌فايلي GFS براي تضمين بالاترين ميزان دسترسي به اين مجموعه داده، بعضي از هزينه‌ها را پذیرفته و برخی قابلیت‌ها را قربانی می‌کند، نظير اصل ثبات و تشابه داده به ازاي کليه کپي‌هاي داده. همچنين GFS اصل تکه‌تکه‌کردن داده را تا حد ممکن اعمال مي‌کند. اگر يکي از فرآيندهاي نوشتن داده با خطا مواجه شود، در اين صورت فرآيند بازگرداندن متاديتا به وضعيت قبلي انجام مي‌شود و يک کپي از داده قبلي را دوباره در اختيار درخواست مورد نظر قرار مي‌دهد. اما از طرفي عدم مشارکت سرور مرجع در فرآيندهاي نوشتن به آن معنا است که به موازات نوشته شدن داده در سيستم اين تغييرات به طور آني در ساير کپي‌هاي آن داده که در سطح هر خوشه وجود دارند، منعکس نمي‌شود. اين سيستم از فرآيندي بهره ‌می‌برد که گوگل آن را “relaxed consistency model” مي‌نامد. اين مدل به واسطه نيازهايي که در صورت دسترسي همزمان به داده‌ها مطرح مي‌شد و همچنين به دليل محدوديت‌هايي که شبکه ايجاد مي‌کرد، طراحي شده است. استفاده از اين فرآيند،‌ به معناي آن است که سيستم GFS هيچ مشکلي با ارائه اطلاعات کهنه و قديمي ندارد. به عبارت ديگر اگر در آن لحظه خاص داده جديد هنوز در سطح سيستم توزيع نشده باشد و کپي‌هاي در دسترس، نسخه‌هاي قديمي باشد، GFS همان داده هاي قديمي را به درخواست کننده تحويل خواهد داد. البته پردازه مرجع تا حد امکان سعي خواهد کرد داده‌ها را به روز نگه دارد و براي اين کار به رديابي تغييرات مي‌پردازد و براي اين منظور به ازاي هر کپي، شماره نگارش قطعات داده را با هم مقايسه مي‌کند. به محض این‌که بعضي از کپي‌هاي داده از فرآيند به روزرساني عقب ‌مانده و به اصطلاح بيات می‌شوند، پردازه مرجع GFS اين اطمينان را ايجاد مي‌کند که آدرس اين قطعات در اختيار کلاينت‌ها قرار نمي‌گيرد و اين محدوديت تا زماني اعمال مي‌شود که داده آن chunk به‌روزرساني شود. اما اين مسئله لزوماً درباره پردازه‌هايي که از قبل آدرس آن chunk را در اختيار گرفته‌اند، انجام نمي‌شود. متا‌ديتاي مربوط به تغييرات تا زماني که پردازه مرجع، تغييرات را بررسي نکرده و آن‌ها را در متا‌ديتا منعکس نکرده‌باشد، اعمال نمي‌شود. همچنين لازم است تا خود متادیتا نيز در چندين مکان مختلف کپي شود تا در صورت بروز خطا در کپي اصلي، جايگزيني براي آن، موجود باشد. اگر اين فرآيند انجام نشود، با از دست رفتن داده‌های مرجع، کل اطلاعات مورد نياز جهت استفاده از اين سيستم‌فايلي، از دست مي‌رود. همچنين اگر در طول فرآيند نوشتن، پردازه مرجع با خطا مواجه شود، در اين صورت نيز تغييرات به طور کامل از دست مي‌رود. البته با توجه به نحوه تعامل گوگل با داده‌ها، اين مسئله، مشکل بزرگي به شمار نمي‌رود زيرا اکثريت نسبي داده‌هاي مورد استفاده توسط برنامه‌هاي اين شرکت، به ندرت تغيير مي‌کنند و تغييرات هم به جاي به‌روزرساني اطلاعات موجود، در قالب افزوده شدن داده به سيستم، انجام مي‌شود.

 سيستم‌فايلي GFS براي پاسخ‌گويي به برنامه‌هايي تهيه شد که گوگل در سال ۲۰۰۳ به کاربران خود معرفي کرده بود، يعني زماني که گوگل هنوز با مشکلات مرتبط با مقياس‌پذيري سيستم‌ها مواجه نشده‌بود. حتي قبل از تملک یوتیوب نيز استفاده از سيستم‌فايلي GFS با مشکلاتي مواجه شد. اين مسئله بيشتر از آن جهت بروز کرده‌بود که برنامه‌هاي جديد گوگل در تعامل با اندازه فايل ايده‌آل ۶۴ مگابايتي شرکت، عملکرد درستي نداشتند. براي برطرف کردن اين مشکل، گوگل براي ذخيره‌سازي داده به سراغ روش مبتني بر Bigtable رفت که روي زيرساخت و سيستم‌فايلي GFS قرار مي‌گيرد. اين روش به شکل بسيار مبهمي ساختار پايگاه‌داده را در ذهن تداعي مي‌کند. ماهيت Bigtable نيز همانند سيستم‌فايلي GFS «فقط يک‌بار نوشتن» است. در نتيجه کليه تغييرات در قالب افزوده شدن داده به جدول‌ها، بروز مي‌کند. به عنوان مثال، گوگل از اين راهکار در برنامه‌هايي نظير Google Docs استفاده مي‌کند تا مسئله کنترل نگارش داده را مديريت کند.

اگر در گوگل کار نمي‌کنيد، ‌بقيه داستان براي شما حالتي آکادميک و رسمي خواهد داشت. هر چند مي‌تواند به کاربران App Engine،‌سيستم ‌ذخيره‌سازي ابري و حتي ساير خدمات گوگل کمک کند تا درک بهتري از زيرساخت مورد استفاده‌شان داشته باشند. در حالي‌که محيط Google Cloud Storage، راهکاري را فراهم مي‌کند تا عموم کاربران بتوانند آنچه را مي‌خواهند از طريق يک رابط تحت وب، در سطح سيستم‌فايلي GFS، ذخيره کنند و به آن دسترسي داشته باشند اما اطلاعات دقيق در مورد رابط‌ها و ابزارهاي اصلي براي دسترسي به سيستم‌فايلي GFS، منتشر نشده‌است. البته مستنداتي که سيستم‌فايلي GFS را تشريح مي‌کنند منجر به ارائه يک سيستم‌فايلي توزيع‌شده ديگر بسيار شبيه GFS شد که کاربردهاي بسیار گسترده‌تري يافته است. اين سيستم فايلی با نام هدوپ Distributed File System معرفي شده‌است.

منبع : Bigdata.ir

 http://www.bigdata.ir/1394/01/%d8%b3%d9%8a%d8%b3%d8%aa%d9%85%e2%80%8c%d9%87%d8%a7%d9%8a-%d9%81%d8%a7%d9%8a%d9%84%d9%8a-%d8%af%d8%b1-%d8%b9%d8%b5%d8%b1-%da%a9%d9%84%d8%a7%d9%86-%d8%af%d8%a7%d8%af%d9%87/

ذخیره سازی توزیع شده کلان داده ها:

پایگاه داده:

سیستمهای مدیریت پایگاه های داده مبتنی بر ستون، بر اسـاس قدرتمندسازی همان طبیعت کلید-مقدارشکل گرفته اند. برخلاف آن تصور عامه در اینترنت که گفته میشود یادگیری این پایگاه داده ها مشکل است، این نوع پایگاه داده ها به طور خیلی ساده و بر اساس ساخت کلکسون هایی از یک یا چند جفت کلید – مقدار کار می کنند که با یک رکورد مطابقت دارد. بر خلاف تعاریف قدیمی از قالب (Schema) در سیستم های رابطه ای، یک سیستم مبتنی بر ستون نیازمند جدولی از پیش تعیین شده جهت کار کردن با داده ها در آن نیست. هر رکورد با یک یا چند ستون که دربردارنده اطلاعات هستند، ارائه می شود و هر ستون از هر رکورد می تواند متفاوت باشد. به طور ساده، این نوع پایگاه داده ها، آرایه هایی دو بعدی هستند که به موجب آن، هر کلید (در اینجا معادل سطر یا رکورد)، یک یا چند جفت کلید – مقدار را به همراه دارند که به آنها متصل هستند. این سیستم، اجازه استفاده و نگهداری حجم عظیمی از داده های ساخت نایافته را می دهد. (مثلا یک رکورد با مقادیر عظیمی ازاطلاعات)
ایـن سیسـتم معمـولا زمانـی اسـتفاده میشـود که جفتهای کلید – مقدار کافی نیستند و ذخیره تعداد بسیار زیاد از رکوردها با تعداد اطلاعات بسیار بزرگ، یک ضرورت محسوب می شود.
این سیستم قابلیت بسط پذیری بسیار خوب و بالایی را دارد. برای سیستمهای مدیریت پایگاه داده های مبتنی بر ستون می توان موارد زیر را معرفی نموده :

Cassandra:
مخزن داده مبتنی بر
BigTable و DynamoDBHBase:
مخزن داده سکوی ،
Apache Hadoop
مبتنی بر ایده ی
BigTable

موارد مناسب جهت استفاده:
نگهداری از داده های ساخت نایافته و اطلاعات غیر فرار:

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

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

MongoDB:
پایگاه داده بسیار پرطرفدار و بسیار کارا
CoudhDB:
یک مخزن داده ی پیشرو و سنت شکن
Coudhbase :
مبتنی بر
JSON
قابلیت ذخیره در حافظه اصلی موارد مناسب جهت استفاده:
اطلاعات تودرتو این سیستمها اجازه کار با داده های بسیار پیچیده و تودرتو را میدهد.کار با جاوااسکریپت :
یکی از حیاتی ترین کارکردهای این نوع سیستمها، روشی است که در آن با برنامه های جاوا اسـکریپتی روبرو میشوند، مثلا استفاده از قالب JSONمناسب برای جاوا اسکریپتمبتنی بر گراف:
در نهایت، می توان به سیستم جذاب مدیریت پایگاه داده های مبتنی بر گراف اشاره کرد. این سیستمها داده ها را به شکلی کاملا متفاوت از سه مدل قبلی که به آن اشاره شد، ارائه میکنند.
آنها ساختار درختی را همانند آنچه که در گرافها هست ارائه می کنند، با راس ها و یال هایی که به وسیله ی رابطه ها به یکدیگر متصل هستند. مشابه تصویری ریاضی گرافها و به لطف طبیعت گرافها (مانند اتصال و دسته بندی اطلاعات مرتبط با هم)، برخی از عملیات خاص در این سیستمها، بسیار ساده تر صورت میپذیرند. (مانند ارتباط آدمها) این پایگاه داده های به طور معمول در برنامه هایی استفاده می شوند که برقراری مرزهای مشخص در اتصالات ضروری است. به عنوان مثال هنگامی که وارد یک شبکه اجتماعی شویم، اتصال دوستانتان به شما و نیز اتصال دوستان دوستانتان به شما از طریق سیستمهای مدیریت پایگاه داده های مبتنی بر گراف ساده تر است.

معرفی سیستمهای مدیریت پایگاه داده های NoSQL و مخازن داده:

گرچه مدل رابطه ای بسیار قدرتمند و انعطاف پذیر است، اما همان طور که اشاره شد، کار کردن با این مدل داده مهارت خاص خود را می طلبد. جدای از این، خیلی از کاربران، مشکلات و نیازمندی هایی دارند که راهکار پایگاه داده های رابطه ای و حتی شی-رابطه ای برایشان مناسب نیست. در دهه اخیر سیستم هایی موسوم به NoSQL و برنامه های مربوط به آنها بسیار پرطرفدار و فراگیر شده اند، با این شعار که در کنار معرفی کارکردهای جدید، بسیاری از دشواری های کار کردن با مدل رابطه ای را نیز برطرف کنند. در واقع هدف این است که با ریشه کن کردن محدودیت های سختگیرانه ای که قبلا در سیستم رابطه ای معرفی شده بود، بتوان به راحتی و انعطاف بالا در نگهداری، پرسوجو و استفاده از داده ها رسید. پایگاه دادههای NoSQL با استفاده از شیوه های ساخت نایافته (یا ساخت یافته در زمان عملی) به حذف محدودیت های رابطه ها کمک میکند و راههای متعدد و مختلفی را جهت موارد استفاده ی خاصی هم چون ذخیره “تمام متن” اسناد “full-text dooument storage “ارائه می کند. بر خلاف آنچه که در مقدمه آورده شده، در سیستمهای پایگاه داده های NoSQL هیچ مدل دادهای همانند سیستمهای پایگاه داده های رابطه ای، مورد استفاده یا نیاز نیست. هر سیستم مدیریت پایگاه دادهه ای NoSQL، به منظورهای خاص و هر یک به شیوه خاص، این منطق را پیاده سازی کرده اند. این پیاده سازی ها و راهکارهای بدون قالب (Schemaless) هم اجازه ی پشتیبانی از أنواع نامتناهی از فرم های دادهای را فراهم می آورد و هم این که به طور ساده و بسیار موثری، از قالب «کلید – مقدار»ی که در مدل رابطه ای بود، پشتیبانی میکنند. پشتیبانی از قالب کلید-مقدار بیشتر برای تعداد دادهه ای کوچک و معمولا به منظور cache کردن داده ها به کار میرود که در بخش مقایسه سیستمهای NoSQL به آن پرداخته می شود. بر خلاف پایگاه داده های رابطه ای، قادر خواهیم بود تا کلکسیونی ” collection”از داده ها را درون یک سیستم پایگاه دادههای NoSQL همانندMongoDB داشته باشیم این پایگاه داده های یا به عبارت دیگر این «مخازن اسناد» (document stores) هر داده را در کنار سایر داده ها، تحت عنوان یک کلکسیون (یا همان سند) در پایگاه داده های نگهداری می کند. این اسناد می توانند تحت عنوان اشیاء داده مستقلی مانند قالب JSON به نمایش درآیند و همچنین بر اساس صفت هایش پرس وجو شوند.

سیستم های پایگاه داده های nosql برخلاف سیستم رابطه ای که از زبان SQL استفاده می کرد، روش های مشترکی را برای پرس وجو از داده ها ارائه نمیکنند و هر سیستم NoSQL راهکار پرس وجو یا دسترسی خاص خود به داده ها را دارا است.
منبع:
www.bigdata.ir

GFS☝

MongoDB
یک پایگاه داده‌های سند-گرای متن‌باز، کارا، مقیاس‌پذیر، بدون نیاز به طرح‌بندی اولیه نوشته شده در زبان برنامه‌نویسی سی++ است.

هدف مانگودی‌بی پرکردن فاصلهٔ ذخیره‌بندی‌های کلید/مقداری—که سریع و مقیاس پذیر هستند— و سامانه‌های سنتی مدیریت پایگاه داده رابطه‌ای—که درخواست‌های غنی و عملکرد عمیقی دارند— بوده‌است. مانگودی‌بی برای رفع مشکلاتی طراحی شده که با پایگاه داده‌های رابطه‌ای به سادگی رفع نمی‌شوند؛ برای مثال اگر پایگاه داده کارسازهای زیادی را دربرگیرد.

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

SimpleDB
پایگاه داده ی توزیع شده و یک سرویس دهنده وب آمازون است.
داده ها بر اساس دامنه های مختلف سازمان دهی شده اند که ممکن است داده های ذخیره شده حاصل شوه و  پرس و جو شده باشند.
دامنه ها شامل خواص مختلف و مجموعه جفت های نام/ مقدار پروژه ها هستند.
برای تضمین امنیت داده ها و بهبود کارایی تاریخ در ماشین های متفاوت در مراکز داده ی مختلف ثبت شده است.
زیرا سیستم از تقسیم بندی خودکار پشتیبانی نمیکند.
بنابراین با تغییر حجم داده ها نمیتواند گسترش داده شود.
این پایگاه داده برای پرس و جو به کاربران اجازه استفاده از SQL را میدهد.

CouchDB

در سال 2005 برای اولین بار منتشر شد ولی در سال 2008 بنیاد آپاچی مالک آن شد. CouchDB که در ابتدا با زبان برنامه نویسی سی ++ پیاده سازی شده بود بعد ها در سال 2008 به زبان ارلنگ منتقل شد. این پایگاه داده نیز همانند اعضای دیگر، یک پایگاه داده سندگرا است که با استفاده از فرمت JSON داده ها را در غالب سند ذخیره میکند. این پایگاه داده که با شعار “یک دیتابیس که مفهوم وب را بپذیرد” شروع به کار کرد.

این پایگاه داده با اینکه از MapReduce استفاده میکند ولی دسترسی آن فقط از طریق API های وب امکان پذیر است. به این صورت که برای دریافت اسناد می بایست یک دستور Get به HTTP فرستاده شود. این پایگاه داده بر خلاف پایگاه داده های دیگر که یک نود اصلی و چند نود فرعی هستند (Single Master/Multiple Slaves)، این پایگاه داده از نوع چند نود اصلی و چند نود فرعی (Multi Masters/Multi Slaves) است و اینکه این پایگاه داده تنها عضوی است که می توان از آن فعلا در برنامه نویسی اندروید استفاده کرد. سیستم مدیریت دیتابیس هم که Futon نام دارد از طریق مرورگر قابل دسترسی است.

Platform for nimble universal table storage :
سکو برای ذخیره سازی جدول جامع:
یک سیستم توزیع شده موازی در مقیاس بزرگ برای برنامه های کاربردی وب در یاهو

https://wiki.apache.org/hadoop/Hbase/PNUTS

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

زندگی ما زاییده اندیشه ماست.

سلام و درود فراوان خدمت همراهان و سروران عزیز.

آخرین هفته پاییزتون سرشار از آرامش و نشاط و سلامتی.

امروز با یاد ایزد با مطالبی پیرامون مدل برنامه نویسی پایگاه داده کلان داده ها از جمله :

MapReduce
Dryad
All-Pairs
Pregel
در خدمت شما هستم.

با تشکر از توجه شما 🌷

گلناز اردشیری
@BigDataTechnology

مدل برنامه نویسی پایگاه داده :

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

مدل برنامه نویسی پایگاه داده :
MapReduce

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

این چارچوب با الهام‌گیری از نگاشت و کاهش که در واقع در زبان‌های برنامه‌نویسی تابعی وجود دارد، ایجاد شد.
اگرچه آنچه که امروزه استفاده می‌شود دقیقاً همان چیزی نیست که مد نظر سازندگان اولیه‌اش است.
کتابخانه‌هایِ نگاشت‌کاهش برای زبان‌های سی++ وسی‌شارپ٬ ارلارج ٬جاوا ٬پرل ٬پایتون ٬روبی ٬اف‌شارپ٬آر و سایر زبان‌ها نوشته‌شده‌اند.

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

گامِ "نگاشت": گره اصلی (Master Node) ورودی را به قطعاتی کوچک‌تر تقسیم می‌نماید(تقسیم مساله‌ی بزرگ به مسایل کوچک) و سپس تقسیم این مسایل کوچک(زیر مسایل) بین گره‌های کارگر.
 یک گره کارگر نیز ممکن است این عملیات را به نوبه‌ی خود تکرار نماید، که ایجاد کننده‌ای ساختاری درختی و چند مرحله‌ای است. هر گره کارگر زیر-مساله‌ی خود را حل نموده و نتیجه را به گره اصلیِ خود برمی‌گرداند.

گامِ "کاهش": سپس گره‌ِ اصلی جواب زیر-مسایل را از گره‌های کارگرش گرفته و خروجی را می‌سازد تا خروجی، که حل مساله‌ی ورودی است، را ایجاد نماید.

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

 همچنین موازی‌سازی امکان بازسازی بعد از بروز خطایِ جزیی در سرورها را در طول عملیات فراهم می‌آورد:
 اگر یکی از نگاشت‌کنندگان یا کاهندگان دچار خطا شود، کار دوباره زمان‌بندی خواهدشد- با فرض اینکه داده‌همچنان در دسترس باشد.

یک راه کار پیشنهادی برا بهبود بازده برنامه نویسی و اسان کردن کار برای کاربران ترکیب سبک SQL در چارچوب MapReduce هست.
چندین زبان پیشرفته در این رابطه معرفی شده است :

گوگل --------- Sawzall
یاهو --------- Pig
فیس بوک ----- Hive
مایکروسافت -- Scope