دسته بندی : پایگاه داده - database

نوشته شده در 1396/01/14

پایگاه داده بزرگ چیست؟

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

 

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

پایگاه داده کوچک

پایگاه داده متوسط

پایگاه داده بزرگ

در حافظه قرار می‌گیرد

در یک سرور قرار می‌گیرد

در چندین سرور پخش می‌شود

مدیر پایگاه داده (DBA) نیاز ندارد

یک DBA نیاز دارد

بیش از یک DBA نیاز دارد

<105 رکورد

105– 107 رکورد

>107 رکورد

<10 GB داده

10GB – 40GB داده

>40GB داده

بدون تقسیم‌بندی (پارتیشن)

کم‌ترین تقسیم‌بندی (پارتیشن)

به طور انبوه اشتراک‌گذاری‌شده

کارایی یک مسئله (مشکل) نیست

کارایی یک مسئله است!


 

عواملی که یک پایگاه داده بزرگ را تعریف می‌کنند

دلیل اینکه اصطلاح «پایگاه داده بزرگ» یک هدف متحرک است این است که فناوری در حال تکامل است. چیزی که وقتی روی یک هارد دیسک اجرا می‌شود بزرگ در نظر گرفته می‌شود ممکن است وقتی روی یک SSD، حافظه یا یک پایگاه داده مقیاس‌پذیر مانند NoSQL یا ScaleDB برای MySQL اجرا شود قابل اداره‌کردن (کنترل) به نظر برسد. به عنوان یک نتیجه، ما می‌توانیم اندازه پایگاه داده را تحت تاثیر چهار عامل زیر در نظر بگیریم:

حجم داده: مقدار داده که با تعداد رکوردها، جداول، ترابایت/پدابایت و ... تعریف می‌شود.

سخت‌افزار: اجرای حتی یک پایگاه داده کوچک روی یک سرور بسیار محدود مانند یک پایگاه داده (مشکل) بزرگ به نظر می‌رسد.

توان عملیاتی: این زبان ویژه پایگاه داده برای استفاده است. اگر شما یک پایگاه داده کوچک دارید اما آن به 10 میلیون کاربر همزمان سرویس می‌دهد، مانند یک پایگاه داده بزرگ به نظر می‌رسد. یا ممکن است شما یک مشتری (کاربر) تنها داشته باشید اما میلیاردها تراکنش را اجرا کند، که این هم بزرگ به نظر می‌رسد. اندازه‌گیری سطوح استفاده، توان عملیاتی در نظر گرفته می‌شود.

نرم‌افزار: نرم‌افزار می‌تواند هر دوی سیستم مدیریت پایگاه داده (DBMS) که شما استفاده می‌کنید و پیاده‌سازی خود پایگاه داده را شامل شود. پیاده‌سازی ممکن است استفاده گسترده از I/O، شبکه یا پردازش‌های شدید CPU مانند joinها یا بررسی‌های محدوده را ایجاد کند. همچنین ممکن است به استفاده شما از بهینه‌سازی مانند شاخص‌ها بستگی داشته باشد.

پایگاه داده شما تنها به خوبی ضعیف‌ترین عامل از این چهار عامل است، اما شما همچنین می‌توانید ضعف را جبران کنید. برای مثال اگر سخت‌افزار شما یک دیسک کوچک دارد، شما می‌توانید از فشرده‌سازی استفاده کنید. یا اگر RAM شما کم است، به جای یک DBMS حافظه‌ای (که متکی به حافظه است)، شما یک DBMS می‌خواهید که در مورد RAM کارآمدتر باشد.


 

اداره کردن یک پایگاه داده بزرگ: Scale-Up در مقابل Scale-Out

اگر شما از یک DBA (مدیر پایگاه داده) یک سوال کلی بپرسید، اغلب پاسخ «بستگی دارد» خواهد بود. وقتی شما بپرسید که scale-up بهتر است یا scale-out پاسخ البته «بستگی دارد» است.

Scaling-up به یک دلیل ساده بدنام است؛ اینکه سرورهای بزرگ‌تر یک نسبت قیمت/کارایی بدتر از ماشین‌های کالا دارند. به عبارت دیگر وقتی گران‌ترین سرورها را خریداری می‌کنید، عملکرد بر دلار (عملکرد/دلار) کاهش می‌یابد. بنابراین پاسخ واضح، scale-out به نظر خواهد رسید. اگرچه دو نکته دیگر نیز وجود دارد.

اگر scaling-up به سادگی معنی خرید بیشتر RAM یا یک دیسک سریع‌تر مانند SSD را بدهد، ممکن است مقرون به صرفه‌تر باشد تا به سادگی ماشین خود را ارتقا دهید، که یک شکل کم هزینه از scaling up است. نکته دوم هزینه‌های دیگر است، هزینه‌هایی بجز سخت‌افزار سرور. این هزینه‌های دیگر می‌تواند شامل لایسنس‌های اضافی نرم‌افزار (پایگاه داده، اپلیکیشن و ...)، دوباره‌نویسی اپلیکیشن برای scale-out کردن باشد، شاید switch شما پورت اضافی نداشته باشد و شما باید یک سوییچ گران‌قیمت برای اداره یک scale-out بخرید. وقتی شما تصمیم می‌گیرید که چگونه پایگاه داده خود را مقیاس‌دهی کنید، باید تمام این چیزها را در نظر بگیرید.

به طور کلی، مخصوصا اگر شما از نرم‌افزار open source استفاده می‌کنید، scale-out راه‌حل مقرون به صرفه‌تر و مقیاس‌پذیرتر است. شما معمولا می‌توانید بیشتر از یک مجموعه بزرگ از سرورهای کالا (سرورها) را بگیرید نسبت به اینکه یک سرور ویژه بزرگ را بگیرید. علاوه بر این اگر شما پایگاه داده خود را در cloud (که به طور پیش‌فرض scale-out است.) اجرا می‌کنید، شما یک معماری پایگاه داده scale-out خواهید خواست. نکات cloud برای پایگاه داده‌های بزرگ را برای جزئیات بیشتر ببینید. همچنین، همانطور که در بالا اشاره شد، هزینه نوشتن دوباره نرم‌افزار برای اداره scaling-out را در نظر بگیرید. این در بخش زیر بیان شده است.


 

نکات معماری DBMS

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

      1. NoSQL: SQL یک زبان قدرتمند برای دستکاری داده‌ها فراهم می‌کند. NoSQL یک کلاس از DBMS توصیف می‌کند که با نام انبارهای (مخازن) کلید-مقدار (key-value) شناخته می‌شود. اپلیکیشن یک کلید به پایگاه داده NoSQL ارائه می‌کند، که مقداری را که با کلید در ارتباط است برمی‌گرداند. NoSQL مقدار زیادی از پردازش را به اپلیکیشن تحمیل می‌کند. این پایگاه داده را بسیار مقیاس‌پذیر می‌کند، اما آن لودکردن (بارگیری) را به اپلیکیشن منتقل می‌کند. برای مثال اگر شما بخواهید یک join را انجام دهید، اپلیکیشن شما باید تمام داده‌ها را به داخل لایه اپلیکیشن بکشد و join را خودش انجام دهد. اگر اپلیکیشن شما به خوبی مقیاس‌گذاری و اجرا کند، پس این رویکردی است که ممکن است برای شما کار کند. این می‌تواند باعث انتقال مقدار زیادی داده شود، برخلاف پردازش داده‌ها در جایی که آن‌ها قرار دارند. همچنین بسته به اپلیکیشن می‌تواند باعث کاهش کارایی شود. با تحمیل عملکرد به لایه اپلیکیشن، همچنین می‌تواند باعث هزینه بیشتر کدنویسی، اشکال‌زدایی (debug) و نگهداری اپلیکیشن شود. NoSQL همچنین ثبات (استحکام) را کم می‌کند – یکی از خصوصیات ACID (Atomicity, Consistency, Isolation, Durability) – اما فرض کنید که این یک مشکل برای اپلیکیشن شما نیست، در این صورت NoSQL می‌تواند مقیاس‌پذیری افقی خوبی را فراهم کند.

      2. تقسیم‌بندی (Sharding): یک shard پایگاه داده یک قسمت افقی از داده‌ها در یک پایگاه داده یا موتور جست‌وجو است. هر قسمت واحد به یک shard یا یک shard پایگاه داده اشاره دارد. هر shard روی یک نمونه سرور پایگاه داده جدا نگهداری می‌شود تا بار را پخش کند. بعضی از داده‌ها در یک پایگاه داده در تمام shardها حاضر باقی می‌مانند اما بعضی دیگر تنها در یک shard واحد ظاهر می‌شوند. هر shard (یا سرور) به عنوان منبع واحد برای این زیرمجموعه از داده‌ها عمل می‌کند. اصل اساسی پشت تقسیم‌بندی، شکستن یک پایگاه داده بزرگ آهسته یا سنگین به تعداد زیادی پایگاه داده‌های کوچک سریع است، هر کدام با فضای ذخیره‌سازی و محاسبه اختصاصی. هر پایگاه داده یا قسمت (shard) مستقل است، یعنی هیچ دانشی از یا هیچ هماهنگی با دیگر قسمت‌ها (shardها) ندارد. با حذف هر وابستگی بین قسمت‌ها، هر پردازشی که شامل بیشتر از یک قسمت (shard) باشد باید در اپلیکیشن اداره شود، خیلی شبیه مثال NoSQL بالا. برای مثال، یک join یا range scan نیاز به لودکردن داده‌ها به داخل اپلیکیشن خواهد داشت و سپس داشتن عملیات اپلیکیشن سراسر آن داده‌ها، به جای اجازه دادن به پایگاه داده برای اداره آن پردازش. تقسیم‌بندی همچنین به این نیاز دارد که اپلیکیشن هر درخواست پایگاه داده را تا قسمت (shard) خاص مسئول آن داده مسیریابی کند. همانطور که داده‌های شما رشد می‌کنند، آن می‌تواند انحراف را تحمل کند، باعث می‌شود داده‌ها را بین شاردها حرکت (انتقال) دهید، یک پردازش که re-sharding (قسمت‌بندی دوباره) نامیده می‌شود. Re-sharding می‌تواند واقعا سخت باشد. ابزارهایی مانند DBShard، ScaleBase و ScaleArc وجود دارد تا فرآیند تقسیم‌بندی (sharding) را آسان کند.

      3. مجازی‌سازی پایگاه داده: راه دیگر برای مقیاس‌دهی پایگاه داده بزرگ شما، مجازی‌سازی پایگاه داده است. مجازی‌سازی پایگاه داده اپلیکیشن را با یک پایگاه داده منطقی واحد فراهم می‌کند، اما فراخوانی‌های واقعی پایگاه داده توسط یک گروه مقیاس‌پذیر از پایگاه داده‌ها اداره می‌شود، که به عنوان لایه محاسبه شناخته می‌شود. این لایه محاسبه متکی بر یک لایه مقیاس‌پذیر از گره‌های ذخیره‌سازی است، یعنی لایه ذخیره‌سازی. مجازی‌سازی پایگاه داده به صورت یک پایگاه داده واحد عمل می‌کند، وقتی که در واقع در سراسر یک گروه مقیاس‌پذیر از سرورهای پایگاه داده یا نمونه‌های مجازی اجرا می‌شود. برخلاف NoSQL و sharding (تقسیم‌بندی)، مجازی‌سازی پایگاه داده توابع مرسوم پایگاه داده را مانند counts، range scans، joinها و ... فعال می‌کند که به طور یکپارچه در داخل پایگاه داده اداره می‌شود. مجازی‌سازی پایگاه داده همچنین سازگاری (ثبات) را فراهم می‌کند، برخلاف NoSQL که تنها سازگاری (ثبات) احتمالی یا مشروط را فراهم می‌کند. مجازی‌سازی پایگاه داده همچنین انتقال تابع، انتقال پردازش به گره‌های ذخیره‌سازی را پیشنهاد می‌کند تا تاخیر و ترافیک شبکه را کاهش دهد. این پردازش موازی شبیه به Hadoop’sMapReduce.ScaleDB که یک پیشرو در مجازی‌سازی پایگاه داده است را فراهم می‌کند.

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

توجه کنید که اجرا کردن یک پایگاه داده روی یک ماشین مجازی، کاملا با مجازی‌سازی پایگاه داده متفاوت است.

      1. عمل تعادل حافظه: حافظه می‌تواند حدود 100 برابر سریع‌تر از دسترسی دیسک اجرا شود، بنابراین شما نیاز دارید تا استفاده خود از حافظه را حداکثر کنید. SSD از لحاظ کارایی جایی در وسط قرار دارد که آن را تبدیل به گزینه دیگری برای افزایش کارایی (عملکرد) می‌کند. برخی پایگاه داده‌های بزرگ منحصرا در حافظه اجرا می‌شوند. یعنی هر دوی داده‌ها و شاخص‌ها باید در حافظه قرار گیرند. دیگر پایگاه داده‌ها به داده‌ها اجازه می‌دهند تا روی دیسک قرار گیرند – در حالت ایده‌آل تا جایی که ممکن باشد در حافظه، کش می‌شوند – اما نیاز به قرار گرفتن تمام شاخص‌ها در حافظه دارد. هنوز دیگر آن‌ها حافظه را برای هر دوی شاخص‌ها و داده‌ها حداکثر می‌کنند، اما به آن‌ها اجازه می‌دهند تا روی دیسک سرریز شوند.

      2. وقتی یک DBMS را برای پایگاه داده بزرگ خود انتخاب می‌کنید، مطمئن شوید که در نظر دارید چگونه از حافظه و همچنین پلتفرم هدف استفاده می‌کند. برای مثال، اگر شما قصد دارید تا یک پایگاه داده بزرگ را پشتیبانی کنید و می‌خواهید آن را در یک فضای ابری (cloud) عمومی که روی RAM فیزیکی در دسترس، محدودیت‌هایی دارد اجرا کنید، ممکن است دریابید که پایگاه داده بزرگ شما دچار یک پایگاه داده in-memory (پایگاه داده‌ای که در حافظه قرار می‌گیرد.) شده است و حتی ممکن است پایگاه داده‌ای که نیاز به قرارگیری تمام شاخص‌ها در حافظه دارد را نابود کند. مطمئن شوید که وقتی یک DBMS را انتخاب می‌کنید، رشد برنامه‌ریزی‌شده و محدودیت‌های RAM را در نظر دارید. اگر شما مجازی‌سازی پایگاه داده را در نظر دارید، به بررسی کش‌کردن محلی نیز نیاز خواهید داشت. وقتی از مجازی‌سازی پایگاه داده استفاده می‌کنید، برخی پایگاه داده‌ها (مانند گروه MySQL) کش‌کردن داده‌ها در حافظه را در لایه محاسبه ارائه نمی‌کنند. بقیه (مانند ScaleDB) از کش‌کردن محلی پشتیبانی می‌کنند. مزیت کش‌کردن محلی این است که درخواست‌های پایگاه داده که از یک کش محلی به کار گرفته می‌شوند با یک ضریب 10-100 بسیار سریع‌تر از دسترسی دیسک هستند. به عنوان یک نتیجه، کش‌کردن در لایه محاسبه می‌تواند به طور قابل توجهی کارایی را افزایش دهد.


 

نتیجه

اگر شما با یک پایگاه داده بزرگ یا پایگاه داده‌ای که در طول زمان بزرگ خواهد شد سر و کار دارید، نکات زیادی وجود دارد که انتخاب DBMS و طراحی پایگاه داده شما را تحت تاثیر قرار می‌دهد. آیا چالش شما سخت‌افزار، DBMS، حجم زیاد داده‌ها یا توان عملیاتی بالا است؟ هر کدام از این‌ها ممکن است باعث شود پایگاه داده شما آهسته و سنگین به نظر برسد. مطمئن شوید که نکات تجاری را در طرح پایگاه داده خود در نظر دارید، شامل تحمل کسب و کار در برابر از دست دادن داده‌ها و مدت از کار افتادگی (زمان down شدن). آیا شما قصد دارید تا پایگاه داده خود را در فضای ابری اجرا کنید؟ اگر این طور است، برای scale-out برنامه‌ریزی کنید وقتی که به محدودیت‌های یک سرور پایگاه داده واحد برخورد می‌کنید. و البته با یک مدیر پایگاه داده (DBA) درجه یک کار کنید، کسی که بتواند پایگاه داده را برای گرفتن حداکثر خروجی کارایی تنظیم کند.

نظرات 4

test . 1396/02/06

test

xpass . 1397/04/30

ت

xpass . 1397/04/30

ت

xpass . 1397/04/30

ت

ارسال نظر