دانلود رایگان ترجمه مقاله الگوهای پایگاه داده توزیع شده (اسپرینگر ۲۰۱۵)

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

تکرار، برای توزیع حجم‌کار انبار داده‌ها محدودیت دارد. حجم‌کار OLTP معمولا شامل تعداد زیادی درخواست کوتاه مدت است. بااین‌حال، در یک محیط انبار داده‌ها، حجم‌کار معمولا تعداد کوچکتری از اطلاعات فشرده شده است. در سرورهای پایگاه‌داده، پرسش عظیم توسط فرایندهای متعدد یا موضوعات انجام می‌گیرد، که هر کدام می‌تواند هسته پردازنده جداگانه‌ای را با کانال‌های ورودی و خروجی متعدد استفاده کند.
موازی‌سازی یک پرس‌وجو در چندین سرور پایگاه داده مختلف، نیاز به یک رویکرد جدید دارد. فروشندگان انبار داده‌ یک راه‌حل برای این مشکل با اجرای یک پایگاه‌داده مشترک ارائه کرده‌اند. همانند مفاهیم بسیاری در جهان رابطه، ایده به اشتراک گذاشتن هیچ چیزی مهمترین آنها بود که در سال ۱۹۸۰ توسط Michael Stonebraker برنامه‌ریزی شد. سرور پایگاه‌داده ممکن است به‌صورت زیر طبقه‌بندی شود:
• به اشتراک گذاشتن هر چیزی: در این مورد، هر فرایند پایگاه‌داده، حافظه، CPU، و منابع دیسک یکسانی را به اشتراک می‌گذارد. به اشتراک‌گذاری حافظه نشان می‌دهد که هر فرایند در سرور یکسانی است و از این رو معماری پایگاه‌داده تک گره است.
• دیسک به اشتراک گذاشته شده: در این مورد، فرآیندهای پایگاه‌داده ممکن است بر روی گره‌های جداگانه در خوشه وجود داشته باشند و به پردازنده و حافظه سرور که بر روی آنها قرار دارند دسترسی یابند. بااین‌حال، هر فرآیند دارای دسترسی برابری به دستگاه‌های دیسک است، که در سراسر گره‌های خوشه به اشتراک گذاشته شده‌اند.
• به اشتراک گذاشتتن هیچ چیزی: در این مورد، هر گره در خوشه نه تنها به حافظه خود و CPU دسترسی دارد بلکه به دستگاه‌های دیسک اختصاص داده شده و زیر مجموعه پایگاه‌داده خود نیز دسترسی دارد. ما چند نمونه از معماری اشتراک هیچ چیزی را در کتاب حاضر بیان کرده‌ایم، از جمله طراحی MySQL اشتراکی در فصل ۳ و طرح پارتیشن‌‎بندی VoltDB در فصل ۷٫
مدل اشتراک هیچ چیزی، پایه و اساس سیستم‌های چند پایگاه‌داد‌ه‌ای خوشه‌ای، مانند Teradata است. که یک مدل جذاب برای وظایف سنگین انبار داده‌ها فراهم می‌کند که می‌تواند به راحتی در گره‌های متعدد براساس دسترسی به داده‌های آنها موازی‌سازی شود. برای یک سیستم که آرزوی به حداکثر رساندن حجم‌کار براساس خواندن را دارد، پیاده‌سازی آن به‌طور قابل توجهی آسان است. پیاده‌سازی پایگاه‌داده‌ها با مدل اشتراک هر چیزی، اغلب خود را به‌عنوان پردازنده‌های موازی پایگاه‌داده (MPP) معرفی می‌کنند. شکل ۸-۳ مدل اشتراک هیچ چیزی را نشان می‌دهد.

معماری مشترک هیچ چیزی، تمایل به شکستن در حالات کاربردی دارد، چرا که نیاز به هماهنگ‌سازی تراکنش‌ها دارد که ممکن است داده‌ها بر روی گره‌های متعدد را ملاقات کند. از آنجا که تراکنش‌های ACID، “همه یا هیچ چیز،” هستند، بنابراین هماهنگ‌سازی برای تمام گره‌ها در اجرای تراکنش ضروری است. این هماهنگی، که به‌عنوان commit دو فازی شناخته شده است، برای پیاده‌سازی مشکل است و ممکن است نتایج “in doubt” در تراکنش‌ها ایجاد کند و موجب تضعیف عملکرد تراکنش‌ها گردد.

اشکال دیگر معماری اشتراک هر چیزی این است که بدون پارتیشن‌بندی دقیق، حجم‌کار خوشه نامتعادل می‌شود. حفظ پارتیشن‌بندی درست یک فعالیت عملیاتی است. زمانی که گرهی از خوشه اضافه یا حذف می‌شود، ایجاد توازن مورد نیاز است.
معماری به اشتراک‌گذاری دیسک، از لحاظ نظری مقیاس‌پذیری بیشتری را منجر می‌شود و حذف آن نیاز به انجام عملیات توازن دارد. این سرویس همچنین یک راه‌حل در دسترس مقرون به صرفه‌تر ارائه می‌کند، زیرا هیچ گرهی مسئولیت منحصر به فردی برای مجموعه‌ای خاص از داده‌ها ندارد. در اشتراک هیچ چیزی، نتایج خرابی گره در بخشی از پایگاه‌داده در دسترس نیست، درحالی‌که در اشتراک دیسک، گره باقی‌مانده قادر به از سرگیری مسئولیت گره شکست خورده است.
چالش معماری اشتراک دیسک، ضرورت در هماهنگی داده‌های cache شده در سراسر گره است. بدون کش در حافظه، عملکرد تمام عملیات بنا به سرعت دیسک کاهش می‌یابد. اما برای حفظ تداوم داده‌ها در تمام گره‌ها، هر گره نیاز به حفظ کش سازگار دارد. نگهداری از این کَش یک فشار بر روی شبکه و بین گره‌ها قرار می‌دهد که پیاده‌سازی موفق آن را دچار مشکل می‌کند.
تا به امروز، تنها بازمانده تجاری و موفق RDBMS اشتراک دیسک در پایگاه‌داده‌ی خوشه‌ای نرم‌افزار اوراکل (RAC) است. RAC پایه و اساس پایگاه‌داده اوراکل است. شکل ۸-۴ مدل اشتراک دیسک را نشان می‌دهد.

پایگاه‌داده‌ی توزیع شده‌ی غیررابطه‌ای
حفظ تمامیت تراکنش ACID در سراسر گره‌های متعدد در یک پایگاه‌داده‌ی رابطه‌ای توزیع شده، چالش قابل توجهی دارد. بااین‌حال، در سیستم‌های پایگاه‌داده‌ی غیررابطه‌ای، از ACID پشتیبانی نمی‌کنند. برای پایگاه‌داده‌ی توزیع شده غیررابطه‌ای، ملاحظات زیر قابل‌توجه است:
• در دسترس بودن ثبات و پایداری: همانطور که در فصل ۳ دیدیم، قضیه CAP استدلال می‌کند که یک هدف پایگاه‌داده توزیع شده فراتر از یک مقیاس محلی در شبکه است که باید بین دسترس بودن و ثبات در شبکه یکی را انتخاب کند. یک پایگاه‌داده ACID سازگار موظف است ثبات را بر روی دیگر عوامل برقرار کند. با این حال، یک پایگاه‌داده غیررابطه‌ای بدون انطباق با محدودیت ACID می‌‌تواند تعادل متفاوتی ایجاد کند.
• اقتصاد سخت‌افزار: زمانی که یک سیستم به هزاران و یا صدها هزار گره متصل می‌شود تفاوت‌های کوچک در هزینه سرورهای شخصی به سرعت افزایش می‌یابد. بنابراین، یک معماری پایگاه‌داده با استفاده از بهترین نسبت قیمت / عملکرد موجود مقرون به صرفه خواهد بود. علاوه‌براین، ممکن است لازم باشد تا با اختلافات بین تنظیمات سرور کنار بیاییم، به‌طوری‌که سخت افزار جدید را می‌توان به خوشه پایگاه‌داده بدون نیاز به تمام گره‌های موجود برای آخرین مشخصات سخت‌افزاری به روز شده اضافه کنیم.
• انعطاف‌پذیری: در یک خوشه عظیم پایگاه‌داده، گره‌ها از زمانی به زمان دیگر دچار شکست می‌شوند. به هنگام شکست، می‌توان از دست دادن داده‌ها، وقفه دردسترسی، یا شاید حتی شکست در سطح تراکنش را تحمل کرد.
سه گروه معماری پایگاه‌داده توزیع شده توسط نسل بعدی پایگاه‌داده‌ها وجود دارد. سه مدل عبارتند از:
• تغییرات در معماری اشتراکی سنتی، که در آن داده‌ها در سراسر گره براساس ارزش “کلید اشتراکی” تقسیم‌بندی می‌شوند.
• تنوع در مدل هادوپ HDFS / HBase، که در آن یک “استاد دانای مطلق” تعیین می‌کند که داده‌ها باید براساس بار و عوامل دیگر در خوشه قرار گیرند.
• مدل هش سازگار آمازون Dynamo، که در آن داده‌ها در سراسر گره‌های خوشه براساس هش ریاضی قابل پیش‌بینی در یک مقدار کلید توزیع می‌شوند.
تکرار ممکن است در درون هر یک از این معماری‌ها به‎‌منظور اطمیناندر مورد از دست ندادن داده در صورت بروز شکست در سرور به‌صورت ذاتی وجود دارد، اگرچه استراتژی تکثیر متفاوت باشد. به نمونه‌هایی از این روش‌ها در باقی فصل نگاهی می‌اندازیم. در این مقاله از MongoDB به‌عنوان مثالی از یک معماری اشتراکی، HBase به‌عنوان نمونه‌ای از یک استاد دانای مطلق و Cassandra به‌عنوان مثالی از Dynamo استفاده می‌کنیم.

MongoDB shardingو تکرار
MongoDB از اشتراک‌گذاری برای ارائه قابلیت مقیاس‌پذیری و تکرار برای دسترسی بالا پشتیبانی می‌کند. با اينكه می‌توانند به‌طور مستقل از دیگر اجرا شوند، ما هر دو آنها یک سناریو تولید می‌کنند.

sharding
نمایشی سطح بالا از معماری MongoDB اشتراکی در شکل ۸-۵ نشان داده شده است. هر قسمت توسط یک پایگاه‌داده MongoDB متمایز اجرا می‌شود، که در بسیاری از جهات گسترده‌تر از سرور است (۱). پایگاه‌داده‌ی MongoDB جداگانه-سرور پیکربندی (۲)، شامل اَبَرداده است که می‌تواند برای تعیین چگونگی توزیع داده‌ها در سراسر ذرات استفاده شود. روند روتر (۳) مسئول مسیریابی درخواست‌ها به سرور مناسب است.

ممکن است در MongoDB، مجموعه‌ای برای ذخیره اسناد JSON استفاده شود که معمولا برخی از ویژگی‌های مشترک را دارند. برای اجتماع یک مجموعه، یک کلید shard انتخاب می‌شود که یک یا چند ویژگی نمایه برای تعیین توزیع اسناد در سراسر ذرات استفاده شده است. ساختار درختی شاخص MongoDB شامل اطلاعات لازم برای توزیع کلید به‌طورمساوی در سراسر ذرات است.

مکانیزم sharding
توزیع داده‌ها در سراسر ذرات می‌تواند براساس محدوده و یا براساس هش باشد. در پارتیشن‌بندی مبتنی بر محدوده، هر shard به یک محدوده خاص از مقادیر کلیدی shard اختصاص داده می‌شود. MongoDB درباره توزیع مقادیر کلیدی در شاخص برای اطمینان از هر shard اختصاص داده شده به همان تعداد کلید مشورت می‌گیرد. در sharding مبتنی بر هش، کلیدها براساس یک تابع هش به کلید shard توزیع شده اعمال می‌شوند.