ما در این محتوا به بررسی 5 راهکار برای توزیع پایگاه داده که باید بدانید خواهیم پرداخت و از طرفی چالش های پیش رو را نیز بررسی خواهیم کرد.
یکی از چالشهایی که پس از بزرگ شدن سیستم ها (کسب و کار یا سازمانی) کندی پایگاه داده و افزایش حجم داده های پایگاه داده است. و یکی از موثر ترین راهکارهایی که به ذهن یک برنامه نویس یا مالک سیستم می رسد شکستن سیستم پایگاه داده بیت سیستم های دیگر است. اما به همین راحتی ها هم نیست.
چگونه به طور موثر پایگاه داده خود را تنظیم کنید، و فرآیندهای مربوط به انتخاب الگوی مناسب توزیع پایگاه داده را یافته و بکار بگیریم؟
اگر نرم افزار شما با مشکلات کندی مواجه شده است،
شما به انتهای ظرفیت کاربرانی رسیده اید که نرم افزار شما قادر به سرویس دهی است، از این رو همه چیز شروع به کند شدن کرده و سیستم خطا هایی صادر می مند که انتظار آن را ندارید. زمان درخواست‌های شبکه به پایان میرسد یا به اصطلاح تخصصی time out می شوند، و از آم طرف درخواست‌های پایگاه داده مدتی طول می‌کشد تا اجرا شوند و باعث میشوند تا صفحات به کندی اجرا شوند.
اینجا است که – برنامه شما آماده توزیع شدن است! شما باید قبل از اینکه کاربران با ارزش سیستمتان به سراغ رقیب شما بروند فکری به حال این مشکل کنید.
هزینه های توزیع پذیری
قبل از شروع به اشتراک گذاری پایگاه داده خود به صورت عمودی، افقی و درون به بیرون*، یک اصل مهم را باید در نظر داشت. شما نباید بهینه سازی های پیش از موعد را اجرا کنید یا سعی کنید نرم افزار خود را قبل از اینکه واقعاً مورد نیاز باشد، توزیع کنید. پیاده سازی راه حل های توزیع کردن پیچیدگی های زیر را ایجاد می کند:
- افزودن ویژگی های جدید به نرم افزار بیشتر طول می کشد
- سیستم با درگیر شدن قطعات و متغیرهای بیشتر پیچیده تر می شود
- تست کد ممکن است دشوارتر باشد
- یافتن و رفع اشکالات سخت تر می شود
فقط در صورتی باید این مشکلات را بپذیرید که ظرفیت نرم افزار شما واقعا تکمیل باشد و سیستم را نتوان از این بیشتر بهینه سازی کرد.
پس سیستم را تا می توانید ساده نگه دارید، پیچیدگی های توزیع پذیری را تا میتوانید برخود تحمیل نکنید مگر اینکه واقعا راهی نداشته باشید.
یافتن گلوگاه ها با استفاده از متریک (اعداد)
هر برنامه/سیستم متفاوت است، برای تعیین اینکه کدام راه حل توزیع کردن را باید پیاده سازی کنید، ابتدا باید تعیین کنید که گلوگاه کجاست. وقت آن است که به سیستم نظارت بر منابع (مانیتورینگ) خود نگاهی بیندازید یا اگر مانیتورینگ ندارید یک نمونه پیاده سازی کنید و توسط آن منابع مورد نظر را بررسی کنید گلوگاه ها را پیدا کنید و با توجه به آنها ببینید راکاری برای بهینه سازی وجود دارد یا نه.
اگر براز یکی از ارائه دهندگان سرویس های ابری استفاده میکنید که زیرساخت مورد نظر رو بصورت ابری IaaS (زیرساخت به عنوان سرویس) در اختیار شما قرار میدهند میتوانید به راحتی یک سیستم مانیتورینگ خوب پایده سازی کنید که اطلاعات خوبی در اختیار شما قرار می دهند.
چند نمونت از ارائه دهندگان سرویس های ابری به شرح ذیل هستند:
- Microsoft Azure
- AWS
- GCP
این ابزارها عملکرد منابع شما را از طریق نمودارها و سایر روش های نمایش داده ها نشان می دهند. از این نمودارها برای جستجوی گلوگاه ها استفاده کنید. معمولاً اطلاعات مورد نظر به این معنی است که یک منبع پر شده یا دیگر ظرفیت ندارد پس قادر به انجام عملیات جدید نیست.
اگر ظاهراً هیچ مشکلی در ظرفیت منبع مربوطه موجود وجود ندارد، اما به نظر میرسد برنامه شما کند کار میکند، سعی کنید گزارش‌ها را دقیق تر برسسی کنیدتا ببینید گلوگاه کجای عملیات کند شده رخ می دهد.
گزارش‌ها را برای منابعی که بارگیری آنها از طریق شبکه زمان زیادی طول می‌کشد، بررسی کنید، ممکن است سرور دیگری مانند API شخص ثالث یا سرور پایگاه داده شما تاخیرهایی داشته باشند. اگر تاخی از منابع شما است میتوانید پایگاه داده خود را روی سرور دیگری میزبانی کنید، از این رو باید مانیتورینگ مناسب برای بررسی منابع هر دو سرور تنظیم کنید تا گزارش های کامل و مناسبی دریافت نمایید.
با فکر کردن در مورد نحوه استفاده از نرم افزار شما توسط کاربران و تفکر منطقی در مورد خطاها یا گزارش هایی که شروع به مشاهده می کنند، تعیین محل گلوگاه می تواند بسیار ساده باشد. به عنوان مثال توییتر را در نظر بگیرید، این پلتفرم خاص بیشتر برای خواندن و نوشتن توییت ها استفاده می شود.
اگر سرویس‌های مانیتورینگ توییتر بار سنگینی را در پایگاه داده‌های مربوط به این اقدامات نشان میدهند، منطقی است که تیم آنها شروع به بهینه‌سازی آن ناحیه از پلتفرم کنند. در این مقاله، ما به راه‌حل‌های توزیع کردن پایگاه داده می‌پردازیم، که معمولاً اولین نقطه شکست است.
توزیع نمودن یک برنامه از نمای مانیتورینگ
اکنون که به خوبی متوجه شده ایم که مشکلات / گلوگاه ها چیست / کجا هستند، می توانیم راه حل هایی را برای رسیدگی به این مسائل پیاده سازی کنیم. به یاد داشته باشید، سادگی کلید است، همیشه سعی می کنیم از ورود به پیچیدگی های غیر ضروری در سیستم خودداری کنیم.
هدف سطح بالای راه‌حل‌های توزیع پذیری این است که کار کمتری برای رایج‌ترین درخواست‌های نرم افزار انجام شود و یا اینکه به طور مؤثر حجم کاری سیستم را بین منابع متعدد توزیع کرد. روشی هایی که تکنیک های توزیع پذیری انجام می دهند، معمولاً به یک یا چند مورد از موارد زیر گفته می شود:
- استفاده مجدد از داده‌هایی که ، نرم افزار قبلاً جستجو کرده و بدست آورد است
- حذف درخواست‌های مشتری برای داده‌هایی که نرم افزار قبلاً در اختیار کاربر قرار داده است
- ذخیره نتایج عملیات رایج به منظور کاهش محاسبات تکراری
- اجتناب از عملیات های پیچیده در چرخه ی درخواست-پاسخ
بسیاری از تکنیک‌های توزیع پذیری به نوعی از حافظه پنهان خلاصه می کنند. در گذشته، حافظه گران و کمیاب بود. اما امروزه اضافه کردن آن به سرورها ارزان تر است. از این رو استفاده از حافظه پنهان برای دسترسی به داده ها در مقایسه با دیسک یا شبکه بسیار سریعتر است. در این دوران که کاربران انتخاب های زیادی دارند، همراه با حداقل دامنه توجه ما، سرعت و عملکرد برای بقای نرم افزار شما بسیار مهم است.
راه حل های توزیع پذیری پایگاه داده
بیایید شروع کنیم و 5 راهکار برای توزیع پایگاه داده که باید بدانید را با یکدیگر مرور کنیم.
1. پرس و جوهای پایگاه داده کش
کش کردن پرس و جوهای (Query) پایگاه داده یکی از ساده ترین پیشرفت هایی است که می توانید برای مدیریت بارگذاری پایگاه داده بکاربگیرید. چرا که معمولاً یک نرم افزار تعداد انگشت شماری پرس و جو دارد که در اکثر درخواست های ارسال شده اجرا می شوند. من به آنها داده های پر کاربرد می گویم.
خوب به جای اینکه هر بار برای بدست آوردن داده های پر کاربرد یک رفت و برگشت از طریق شبکه انجام شود، می توان آن را به سادگی در حافظه کش وب سرور ذخیره کرد. درخواست اول داده ها را از پایگاه داده واکشی می کند و نتایج را در سرور ذخیره می کند، سپس درخواست های آینده فقط از حافظه کش شده داده مورد نظر را خوانده و استفاده می کنند.
این عمل منجر به افزایش کارایی و عملکرد کل نرم افزار می شود. چرا که داده ها زمان کمتری را صرف انتقال از طریق شبکه و یا اجرا در سمت سرور می کنند و یک لایه به مشتری نزدیک تر می شوند.
همچنین وقت منابع گرانبهای شما در سرور پایگاه داده کمتر گرفته می شود و همیشه منابع بیشتری در دسترس خواهیم داشت. علاوه بر افزایش کارایی و در دسترس بودن داده ها، اگر پایگاه داده در دسترس نباشد، کش همچنان می‌تواند خدمات مستمری را به برنامه ارائه دهد و سیستم را در برابر خرابی سیستم مقاوم‌تر کند.
ابزارهای زیادی وجود دارد که می توانید از آنها برای تجزیه و تحلیل گزارش های جستجوی پایگاه داده استفاده کنید، بنابراین قابل مشاهده خواهد بود که تکمیل کدام پرس و جوها بیشتر زمان صرف خواهد کرد و کدام پرس و جوها بیشتر درخواست شده و اجرا می شوند.
بدیهی است که داده‌هایی که در حافظه پنهان ذخیره میشوند می‌توانند به سرعت «کهنه» یا قدیمی شوند. از این رو ، باید مراقب باشید که کدام داده‌ها را برای ذخیره در حافظه پنهان انتخاب می کنید و مدت زمان آن چقدر است. به عنوان مثال، یک روزنامه آنلاین هر 24 ساعت یک روزنامه روزانه جدید داشته باشد، به جای درخواست آن داده ها از پایگاه داده هر بار که کاربر به سایت مراجعه می کند، می تواند آن داده ها را به مدت 24 ساعت در وب سرور ذخیره کرده و مستقیماً از سرور ارائه کند.
یاد آوری می کنم که الزامات محصول یا کسب و کار تعیین می کند که چه چیزی می تواند ذخیره شود و چه چیزی نمی تواند ذخیره شود.
اولین راهکار از 5 راهکار برای توزیع پایگاه داده که باید بدانید بررسی شد. برای کسب اطلاعات بیشتر در این خصوص ممکن است نیاز به نیروی کار با تجربه داشته باشید.
2. شاخص های پایگاه داده
نمایه سازی (ایندکس گذاری) پایگاه داده تکنیکی است که سرعت عملیات بازیابی داده ها از طریق را در جداول پایگاه داده بهبود می بخشد.
ایندکس ها برای مکان یابی سریع داده ها بدون نیاز به جستجوی هر ردیف در جدول در هر بار دسترسی به جدول استفاده می شوند. معمولاً، ساختار داده برای فهرست کردن در پایگاه داده، درخت جستجوی باینری است.
نمایه سازی اجازه می دهد تا پیچیدگی زمانی دسترسی به داده ها از زمان خطی O(n) به زمان لگاریتمی Olog(n) کاهش یابد.
بسته به تعداد ردیف‌های یک جدول، نمایه سازی می‌تواند باعث صرفه‌جویی قابل توجهی در زمان اجرای پرس و جوی درخواست‌هایی شود که از ستون نمایه‌سازی شده استفاده می‌کنند. به عنوان مثال، اگر شما 10000 کاربر داشتید و برنامه شما دارای صفحات نمایه ای است که کاربر را با نام کاربری جستجو می کند، یک پرس و جو فهرست نشده تک تک ردیف های جدول کاربران را بررسی می کند تا زمانی که نمایه ای را پیدا کند که با نام کاربری ارسال شده به درخواست مطابقت دارد. این می تواند تا 10000 بررسی ردیف را طول بکشد یعنی زمان O(n).
با ایجاد یک نمایه برای ستون «نام کاربری»، پایگاه داده می تواند آن ردیف را تحت پیچیدگی زمانی لگاریتمی (Olog(n)) بیرون بکشد. که در این صورت حداکثر تعداد بررسی ردیف به جای 10000 عدد 14 تغییر خواهد کرد!
نمایه سازی موثر افزایش کارایی بار روی پایگاه داده را کاهش می دهد، همچنین عملکرد قابل را بطور توجهی افزایش می دهد که منجر به تجربه کاربری بهتر می شود.
ایجاد یک نمایه مجموعه دیگری از داده‌ها را برای ذخیره در پایگاه داده اضافه میکند، بنابراین هنگام تصمیم‌گیری درباره اینکه چه فیلدهایی باید فهرست شوند، باید بررسی دقیقی انجام داد.
حتی با وجود فضای ذخیره‌سازی موجود که استفاده می‌شود، نمایه‌سازی ارزش بهای پرداختی آن را دارد، به خصوص در توسعه مدرن که حافظه ارزان است و عملکرد برای بقا بسیار ضروری است.
3. ذخیره سازی نشست یا جلسه
بسیاری از نرم افزار ها هنوز نشست ها را با ذخیره شناسه نشست کاربر در کوکی و سپس ذخیره داده‌های واقعی هر نشست را در جدولی در پایگاه داده ذخیره می کنند و بدین شکل آن را مدیریت می‌کنند.
این کار می تواند باعث حجم عظیمی از عملیات های خواندن و نوشتن را به بار در پایگاه داده شما اضافه کند. که اگر پایگاه داده شما مملو از داده های نشست باشد، ایده خوبی بسیار خوبی است که درباره نحوه و مکان ذخیره سازی نشست ها تجدید نظر کنید.
انتقال داده های جلسه به یک ابزار ذخیره سازی حافظه داخلی مانند redis یا memcached می تواند گزینه خوبی باشد. این کار باعث حذف بار داده های جلسه از پایگاه داده شما می شود و همچنین سرعت دسترسی را افزایش می دهد زیرا حافظه داخلی سریعتر از حافظه دائمی (دیسک) است که اکثر پایگاه های داده از آن استفاده می کنند.
با این حال، از آنجایی که حافظه داخلی یک حافظه فرار است، در صورت آفلاین شدن سیستم کش، خطر از دست دادن تمام داده های جلسه وجود دارد. همچنین، از آنجایی که این راه حل داده های کاربر را با استفاده از حافظه سرور ذخیره و مدیریت می کند، پتانسیل توزیع پذیری محدودی دارد زیرا حافظه منبع نسبتاً محدودی است.
راه حل دیگر این است که اجرای احراز هویت خود را تغییر دهید تا اطلاعات جلسه را در خود کوکی ذخیره کنید، که به جای آن ابزار شما برای حفظ وضعیت جلسه از سرور و روی کلاینت منتقل می شود.
برای این روش JWT ها محبوب ترین پیاده سازی احراز هویت مبتنی بر توکن هستند. این امر پایگاه داده شما را از داده های نشست خالی می کند و وابستگی نشستها را به سمت سرور حذف می کند، اگرچه چالش های متعددی ایجاد می کند و بهتر است اصول و روش های پیاده سازی آن به خوبی رعایت شود.
4. تکرار خواندن پایگاه داده
اگر پایگاه داده شما حتی پس از ذخیره پرس و جوهای رایج، ایجاد نمایه های کارآمد و مدیریت ذخیره سازی جلسات همچنان تحت بار زیادی از خواندن قرار دارد، تکرار ممکن است بهترین کار بعدی باشد.
با ایجاد سرور پایگاه داده تکراری برای خواندن ، شما یک پایگاه داده واحد دارید که در آن می نویسید و در چندین پایگاه داده ماکت (به تعداد مورد نیاز) یا تکراری که از آنها می خوانید، کلون می شود و هر پایگاه داده ماکت روی ماشین دیگری قرار دارد.
این کار بار خواندن را از یک پایگاه داده اولیه (اصلی) برداشته و آن را در چندین سرور پایگاه داده توزیع می کند. قطعا در این روش عملکرد نوشتن نیز بهبود می یابد، چرا که پایگاه داده اصلی به نوشتن اختصاص داده شده است، در حالی که به طور چشمگیری سرعت خواندن را افزایش می دهد و تاخیر را کاهش می دهد.
قطعا مفید تر خواهد بود که پایگاه داده ماکت یا مشابه در مناطق مختلف پخش شوند تا دسترسی به آنها سریعتر انجام شود.
از آنجایی که هر پایگاه داده ماکتی روی ماشین دیگری قرار دارد، نوشته‌ها در پایگاه داده اولیه باید به رونوشت‌ها منتشر شوند که می‌تواند منجر به ایجاد داده‌های ناسازگار گردد.
اگر می‌خواهید فوراً داده‌های نوشته شده در پایگاه داده را بخوانید، مثلاً در حال به‌روزرسانی یک نمایه هستید و می‌خواهید فوراً ارائه شود، میتوانید از پایگاه داده اولیه بخوانید.
Read Replication یک راه‌حل توزیع پذیری فوق‌العاده قدرتمند است، اما با پیچیدگی‌هایی همراه است. عاقلانه تر است که این راه حل را پس از اتمام بررسی سایر راه حل های ساده تر و اطمینان از بهینه بودن سیستم بطور موثر در نرم افزار پیاده سازی کنید.
این الگوی معماری به طور سنتی به عنوان تکرار پایگاه داده بصورت Master-Slave شناخته می شود، اما اصطلاحی است که در طول سال ها مورد انتقاد قرار گرفته است و در حال جایگزینی در سراسر جامعه فناوری است. امروزه بیشتر از آن به عنوان پایگاه داده تکراری برای خواندن یاد می شود.
5. Sharding پایگاه داده
بسیاری از این راه حل های توزیع پذیری تا کنون بر کاهش بار از طریق مدیریت خواندن از پایگاه داده متمرکز شده اند. اشتراک گذاری پایگاه داده یک راه حل توزیع افقی برای مدیریت بار با مدیریت خواندن و نوشتن در پایگاه داده است.
این روش یک الگوی معماری است که شامل فرآیند تقسیم (پارتیشن بندی) پایگاه داده اصلی (مستر) به پایگاه داده های متعدد (شارد) است که مدیریت را سریعتر و آسان تر کند.
دو نوع تکنیک اشتراک گذاری پایگاه داده وجود دارد – اشتراک گذار افقی و اشتراک گذار عمودی.
هر دوی این تکنیک های اشتراک گذار مانند پارتیشن بندی جدول عمودی و پارتیشن بندی جدول افقی عمل می کنند، تفاوت اصلی این است که اشتراک گذار داده های شکسته شده را می گیرد و آن را در چندین گره/سرور پخش می کند. با پارتیشن بندی افقی، جداول گرفته می شود و روی ماشین های مختلف قرار می گیرد که هر جدول دارای ستون های یکسان، اما ردیف های مجزا است.
پارتیشن بندی عمودی پیچیده تر است و شامل تقسیم یک جدول در چندین ماشین می شود. یک جدول جدا شده و در جداول جدید و مجزا قرار می گیرد. داده هایی که در یک پارتیشن عمودی نگهداری می شوند مستقل از داده های سایر پارتیشن ها هستند، هر جدول دارای ردیف ها و ستون های مجزا است. که پیچیدگی های خاص خود را دارد.
معماری پایگاه داده خرد شده یا شاردینگ همچنین می تواند به طور قابل توجهی سرعت پرس و جوهای برنامه شما را افزایش دهد و همچنین انعطاف پذیری بیشتری در برابر خرابی ها ایجاد کند. هنگام ارسال یک پرس و جو در یک پایگاه داده جدا نشده، ممکن است مجبور شود هر ردیف در جدول را جستجو کند که می تواند به شدت کند باشد.
از طرف دیگر، با تقسیم کردن یک جدول به چندین جدول، پرس و جوها باید از رکوردهای بسیار کمتری عبور کنند تا نتایج را برگردانند.
از آنجایی که هر یک از آن جداول روی یک سرور جداگانه قرار دارند، تأثیر در دسترس نبودن سرور کاهش می یابد. با یک پایگاه داده خرد شده، تأثیر قطع به احتمال زیاد تنها بر یک قطعه منفرد تأثیر می گذارد، در مقایسه با یک پایگاه داده غیر شکسته شده که در آن قطعی پتانسیل این را دارد که کل یک برنامه کاربردی را از دسترس خارج کند.
داشتن یک معماری پایگاه داده خرد شده مزایای بسیار زیادی را ارائه می دهد، با این حال، پیچیده است و هزینه اجرا و نگهداری بالایی دارد. این قطعاً گزینه‌ای است که بهتر است پس از بررسی کامل بقیه راه‌حل‌های توزیع پذیری در نظر داشته باشید، چرا که پیامدهای اجرای ناکارآمد آن می‌تواند بسیار شدید باشد.
برای کسب اطلاعات بیشتر میتوانید به مطالب زیر رجوع فرمایید:
منابع تصاویر
https://fauna.com/blog/the-why-and-how-of-distributed-databases
