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

web window with a speed meter on it

بهینه سازی وبسایت برای ترافیک بالا

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

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

 

بهینه‌سازی دیتابیس

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

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

 

بهینه‌سازی سیستم عامل و وب‌سرویس

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

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

سرویس پایگاه داده چیست؟

پایگاه داده به عنوان سرویس که بیشتر با عنوان سرویس دیتابیس یا پایگاه داده مدیریت شده نیز شناخته می‌شود اولین بار در سال ۲۰۰۹ با معرفی یکی از سرویس های AWS معرفی شد. از آن زمان تاکنون تخمین زده می‌شود که تا سال ۲۰۲۵، مارکت این سرویس به ۳۲۰ میلیارد دلار رسیده و سریع‌ترین سرویس ابری در حال رشد در دنیا باشد. دلیل اصلی این رشد، قابلیت‌هایی است که سرویس پایگاه داده در بهبود بهره‌وری،‌ استانداردسازی و امنیت داده‌ها روانه بازار کرده است.

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

 

راه اندازی

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

 

مقیاس گذاری

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

 

DBaaS بر روی IaaS

دیتابیس به عنوان سرویس اغلب به عنوان مولفه‌ای از یک بستر جامع‌تر ارائه می‌شود که خدماتی تحت عنوان IaaS (زیرساخت به عنوان سرویس) ارائه می‌دهد. راه حلی که سرویس پایگاه داده در نظر می‌گیرد به این صورت است که از زیرساخت موجود تحت شبکه، منابع لازم برای انجام اموری مانند محاسبه، ذخیره سازی و امور شبکه را درخواست کرده و اساسا نیاز به بخشی تحت عنوان IT در یک سازمان برای انجام امور دیتابیس را از بین خواهد برد.

چه افرادی از سرویس دیتابیس استفاده می‌کنند؟

درک این نکته مهم است که بدانیم مانند سایر فناوری های ابری، DBaaS‌ دارای دو نوع مصرف کننده اصلی است:

  • سازمان های IT که مدیریت و نگهداری فضای ابری را بر عهده دارند.
  • End-user هایی که منابع ابری را مصرف میکنند که به طور معمول توسعه دهندگان هستند.

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

 

مزایای سرویس پایگاه داده

سرویس دیتابیس مزایای بسیاری را برای سازمان به همراه می آورد. مزایای اصلی آن عبارت اند از:

  • سرعت بالاتر در توسعه
  • بهره وری بالاتر
  • قابلیت اطمینان و عملکرد برنامه
  • امنیت برنامه

حال بیایید به هرکدام از موارد بالا نگاهی بیاندازیم.

 

چابکی توسعه دهنده

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

  • توسعه‌دهنده سازمان یک درخواست (تیکت) باز می‌کند
  • قسمت IT سازمان تیکت را بررسی کرده و به اختصاص منابع محاسبه، ذخیره‌سازی و شبکه مورد نیاز برای پایگاه داده توسعه دهنده می‌پردازد
  • قسمت IT منابع تخصیص یافته را پیکربندی می‌کند
  • قسمت IT پایگاه داده را به توسعه دهنده می‌دهد و توسعه‌دهنده از این مرحله به بعد را بر عهده می‌گیرد

 

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

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

 

بهره وری IT

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

 

قابلیت اطمینان و عملکرد برنامه

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

 

امنیت برنامه

یک DBaaS خوب با ویژگی هایی که دارد می‌تواند مدیریت مداوم امنیت را برای انواع پایگاه داده‌هایی که ممکن است در سازمان‌تان استفاده کنید را به همراه بیاورد؛ این در حالی است که برخی ویژگی‌های امنیتی جدید نیز به آن اضافه خواهد کرد. علاوه بر رمزگذاری داده‌ها به صورت بومی، ممکن است به دنبال مواردی مانند امنیت شبکه به صورت end-to-end و شبکه های خصوصی مجازی نیز باشید. DBaaS قادر است تا برای تایید هویت کاربر با استفاده از سیاست های مختلف کنترل دسترسی مختلف ایجاد کند.

 

حل چالش های ابر با استفاده از DBaaS‌ داخلی

اگر داده های خود را روی یک ابر عمومی نگه دارید، هزینه‌هایی که مرتبط با این داده ها است احتمالا بسیار بالا خواهد بود. اما تنها مشکل این نیست؛ قیمت ها می‌توانند در مناطق مختلف با توجه به دسترسی شما متفاوت باشند. این هزینه‌ها میتوانند تا جایی بالا بروند که بعضی کمپانی ها مجبور اند سالانه میلیون ها دلار برای پابلیک کلود هزینه کنند. اما این هزینه ها چطور تاثیر گذار هستند؟ بیایید با یک مثال ساده جواب این سوال را بدهیم. فرض کنید که کمپانی شما به حد خوبی از رشد رسیده و اکنون نیازمند آن هستید که داده های‌تان را برون سپاری کنید چرا که مدیریت آن‌ها زمان و هزینه زیادی از شما می‌گیرد. راه حل چیست؟ اگر مقاله را به دقت مطالعه کرده باشید جواب ساده است : سرویس دیتابیس (DBaaS).

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

 

DBaaS برای توسعه دهندگان و تیم آی‌تی

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

 

پیشنهاد ما

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

پنج ویژگی کلیدی که باید هنگام خرید DBaaS‌ در نظر بگیرید

امروزه ارائه دهندگان دیتابیس به عنوان سرویس، در طیف گسترده‌ای از ویژگی ها قرار دارند؛ در نتیجه برای انتخاب بهترین سرویس دیتابیس موجود برای سازمان‌تان بایستی موارد زیر را در نظر بگیرید.

انتخاب صحیح پایگاه داده به عنوان سرویس برای موفقیت هر سیستم مبتنی بر مدیریت پایگاه داده ضروری است. بر اساس گزارش اخیر research market انتظار میرود که بازار جهانی DBaaS از ۱۲ بیلیون دلار در سال ۲۰۲۰، به ۲۴.۸ بیلیون دلار در سال ۲۰۲۵ برسد. به نظر می‌رسد تنها چیزی که باعث این رشد شده است تقاضای روزافزون برای پردازش و نمایش داده‌ها با حداقل تاخیر باشد.

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

ولی زمانی که به بازار DBaaS‌ نگاه می‌کنید می‌بینید که به طور فزاینده‌ای در حال رشد و بزرگتر شدن است و رقابت سرویس‌های دیتابیس نیز در آن بیشتر شده است. از این رو هر سرویس سعی می‌کند تا با ارائه ویژگی های بهتر و جدیدتر پیروز این میدان باشد و شما نیز احتمالا در انتخاب سرویس مناسب گیج خواهید شد. این‌جا ست که بایستی با تجزیه و تحلیل دقیق، مناسب‌ترین سرویس را برای سازمان‌تان انتخاب کنید. ما در این مطلب می‌خواهیم به شما کمک کنیم تا ابعاد اساسی برای انتخاب تامین کننده مناسب را بشناسید و بر اساس آن تصمیم بگیرید.

 

پنج فاکتور مهم برای انتخاب سرویس پایگاه داده

ارائه دهندگان سرویس پایگاه داده، همگی یک شکل نیستند و در طیف گسترده‌ای از ویژگی‌ها تفاوت قابل توجهی دارند. برای انتخاب بهترین سرویس برای سازمان خود، بایستی این ۶ عامل را در نظر بگیرید:

  • در دسترس بودن و انعطاف‌پذیری بالا
  • مقیاس پذیری و عملکرد بهینه
  • انعطاف پذیری برای محل قرار گرفتن دیتابیس
  • مدل‌های مدرن داده‌ای
  • هزینه

حال بیایید نگاهی دقیق تر به هر کدام از این ویژگی ها بیاندازیم:

 

در دسترس بودن و انعطاف پذیری بالا

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

 

مقیاس پذیری بالا

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

 

انعطاف پذیری برای محل قرار گرفتن دیتابیس

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

 

مدل‌های مدرن داده‌ای

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

 

هزینه

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

تفاوت اوراکل و پست‌گرس چیست؟

پایگاه داده اوراکل یک سیستم مدیریت دیتابیس اختصاصی‌ است که توسط شرکت اوراکل تولید شده و در حال حاضر بزرگترین پایگاه داده رابطه ای در دنیا است. در حالی که اوراکل هنوز هم بزرگ‌ترین پایگاه داده رابطه‌ای در مارکت است، محبوبیت آن در طول چند سال گذشته تا ۱۸ درصد دچار کاهش شده است. اما چه عواملی باعث این جا‌به‌جایی تغییر نزولی در محبوبیت اوراکل شده است؟ افزایش قابل توجه پایگاه داده های منبع باز، به خصوص یک پایگاه داده مشهور و متن‌باز یعنی پست گرس. در این مقاله ما Oracle  و PostgreSQL را از نظر تفاوت در ویژگی ها و سهولت در استفاده بررسی می‌کنیم.  PostgreSQL که یک پایگاه داده متن‌باز و و رابطه‌ای است، بیش از ۳۰ سال سابقه توسعه فعال داشته و به عنوان محبوب‌ترین پایگاه داده رابطه‌ای شناخته می‌شود. پست گرس در سال های ۲۰۱۷ و ۲۰۱۸ محبوب ترین DBMS سال شد و در سال ۲۰۲۰ نیز به رشد خود ادامه داد.

هزینه

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

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

عملکرد

قابلیت‌های پست گرس روز به روز در حال تکامل بیشتر بوده و با وجود جامعه متن‌باز آن ابزارهایی بسیاری در جهت پیشرفت پست‌گرس طراحی شده اند و همیشه نیز به تعداد آن ها افزوده می‌شود و این در حالی است که هیچ وقت هزینه ای از شما گرفته نمی‌شود. اوراکل اما به مدیریت مداوم و پیچیده تری احتیاج داشته چرا که همه پیکربندی های پایگاه داده بایستی با طرح واره های آن یکی باشند و به صورت سفارشی انجام شوند. پیچیدگی شدید در اوراکل هم چنین خطر خطا را افزایش می‌دهد که میتواند منجر به اشتباهات مهمی شود که برای حل آن‌ها زمان و هزینه بیشتری را لازم خواهید داشت. پست گرس همچنین بسیاری از ویژگی های کلیدی و جدیدی را در ورژن ۱۰ معرفی کرد و در ورژن ۱۱ و ۱۲ آن را توسعه داد که در نتیجه آن را به یک رقیب جدی برای اوراکل تبدیل کرده است.

سادگی استفاده

انجمن پست گرس یکی از فعال ترین انجمن های منبع باز است؛ طیف گسترده ای از ابزارها و افزونه‌ها نیز استفاده از آن را برای شما هموارتر کرده و عملکرد خیلی خوبی ارائه می‌دهد. همه این ویژگی ها که پست گرس از آن بهره میبرد، میزان زمانی که تیم های توسعه برای پرداختن به سناریوهای مختلف احتیاج خواهند داشت را کاهش خواهد داد. اوراکل نیز ابزارهای مختلفی را ارائه میدهد اما همه آن ها تنها با گرفتن لایسنس و پرداخت هزینه پشتیبانی و مجوز به روز رسانی در دسترس هستند. در پست گرس اما اوضاع اینطور نیست و بسیاری از گروه های محلی کاربران در سرتاسر جهان در دسترش شما هستند.

کدام انتخاب بهتر است؟

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

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

راه‌های تشخیص کوئری‌های کند در پستگرس PostgreSQL

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

روش‌های زیادی برای ارزیابی مشکلات عملکردی وجود دارند، با این حال ما از سه روش کلیدی برای ارزیابی سریع کوئری‌ها و برطرف کردن عملکرد بد سیستم پایگاه داده استفاده می‌کنیم که عبارت‌اند از:

  • استفاده بهینه از لاگ کوئری‌های کند
  • چک کردن دستورات اجرا با استفاده از auto_explain
  • تکیه کردن بر اطلاعات تجمیع شده در pg_stat_statements

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

استفاده کردن از لاگ کوئری‌های کند

استفاده از لاگ کوئری‌ها یک روش سنتی برای شناسایی کوئری‌های کند است. ایده کلی به این صورت است:

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

در کانفیگ اولیه پستگرس این لاگ فعال نیست و باید آن را فعال کنید. در این جا چند انتخاب دارید، اگر می‌خواهید این لاگ را به صورت Global فعال کنید بایستی فایل postgresql.conf را به شکل زیر تغییر دهید:

log_min_duration_statement = 5000

با وارد کردن دستور بالا، پستگرس، کوئری‌هایی که بیشتر از 5 ثانیه طول بکشند را کوئری کند تشخیص داده و آن ها را به لاگ میفرستد. با انجام این تغییر در فایل ذکر شده، نیازی به ری‌استارت کردن سرویس نیز وجود ندارد و یک reload به صورت زیر کافی است:

1- postgres=# SELECT pg_reload_conf();
2- pg_reload_conf 
3- ----------------
4- t
5- (1 row)

با ویرایش کردن postgresql.conf تغییر بر روی کل دیتابیس انجام خواهد شد که به نظر میرسد خیلی دقیق نباشد. اگر می‌خواهید دقت را بالا ببرید بایستی برای یک یوزر خاص یا یک دیتابیس خاص ویرایش زیر را انجام دهید:

1- postgres=# ALTER DATABASE test SET log_min_duration_statement = 5000;
2- ALTER DATABASE

Alter Database به ما اجازه می‌دهد که تغییرات را بر روی یک پایگاه داده خاص انجام بدهیم.
در این جا برای تست یک کوئری کد را اجرا می‌کنیم:

1- postgres=# \c test
2- You are now connected to database "test" as user "hs".
3- test=# SELECT pg_sleep(10);
4- pg_sleep
5- ----------
6-
7- (1 row)

نتیجه به صورت لاگ زیر نشان داده می‌شود:

2018-08-20 08:19:28.151 CEST [22845] LOG: duration: 10010.353 ms statement: SELECT pg_sleep(10);

با استفاده از این روش می‌توانید بلافاصله از کوئری‌های کند با خبر شوید و هر زمان یکی از کوئری‌ها کند باشد متوجه آن خواهید شد. هرچند که مزیت این روش میتواند تبدیل به ضعف آن نیز بشود چرا که روش استفاده کردن از لاگ کوئری‌های کند به صورت تکی به دنبال کوئری ها می‌گردد ولی اگر عملکرد بد دیتابیس پستگرس توسط تعداد زیادی از کوئری‌های نه چندان کند ایجاد شده باشد چه می‌شود؟
برای مثال فرض کنید هر کوئری 10 ثانیه به طول می‌انجامد و ما آن را به عنوان کوئری کند شناسایی می‌کنیم؛ تا اینجا همه چیز خوب پیش می‌رود، ولی اگر 1 میلیون کوئری داشته باشیم که هرکدام 500 میلی ثانیه طول بکشند چه؟ تمام این‌ها هیچ‌وقت در لاگ کوئری‌های کند ظاهر نمی‌شوند چرا که به نظر سریع می‌رسند. در نتیجه اگر برای پیدا کردن کوئری‌های کند فقط به این روش متکی باشید احتمالا موفق نخواهید بود.

چک کردن برنامه‌های اجرایی ناپایدار

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

1- test=# CREATE TABLE t_demo AS
2- SELECT * FROM generate_series(1, 10000000) AS id;
3- SELECT 10000000
4- test=# CREATE INDEX idx_id ON t_demo (id);
5- CREATE INDEX
6- test=# ANALYZE;
7- ANALYZE

Table ای که در اینجا ساختیم 10 میلیون ردیف دارد. حال بیایید به کوئری زیر نگاه کنیم:

1- test=# explain SELECT * FROM t_demo WHERE id < 10;
2- QUERY PLAN
3- ---------------------------------------------------------------------------
4- Index Only Scan using idx_id on t_demo (cost=0.43..8.61 rows=10 width=4)
5- Index Cond: (id < 10)
6- (2 rows)
7-
8- test=# explain SELECT * FROM t_demo WHERE id < 1000000000;
9- QUERY PLAN
10- ------------------------------------------------------------------
11- Seq Scan on t_demo (cost=0.00..169248.60 rows=10000048 width=4)
12- Filter: (id < 1000000000)
13- JIT:
14- Functions: 2
15- Inlining: false
16- Optimization: false
17- (6 rows)

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

مثال زیر را در نظر بگیرید:

1- test=# LOAD 'auto_explain';
2- LOAD
3- test=# SET auto_explain.log_analyze TO on;
4- SET
5- test=# SET auto_explain.log_min_duration TO 500;
6- SET

دستور load ماژول auto_explain را در دیتابیس بارگذاری می‌کند. در یک سیستم تولیدی می‌توان از Postgresql.conf یا Alter Database/Alter Table نیز برای بارگذاری ماژول استفاده کرد. اگر می‌خواهید تغییر در postgresql.conf نیز انجام شود، خط زیر را به فایل کانفیگ اضافه کنید:

session_preload_libraries = 'auto_explain';

Session_preload_libraries اطمینان حاصل می‌کند که ماژول به طور پیش فرض بر روی تمام کانکشن‌های دیتابیس تنظیم شده باشد. دیگر نیازی به دستور Load نیست، بعد از ایجاد اولین تغییر می‌توانید کوئری زیر را اجرا کنید:

1- test=# SELECT count(*) FROM t_demo GROUP BY id % 2;
2- count
3- ---------
4- 5000000
5- 5000000
6- (2 rows)

کوئری به بیش از 500 میلی ثانیه احتیاج دارد و سپس در لاگ نمایش داده میشود:

1- 2018-08-20 09:51:59.056 CEST [23256] LOG: duration: 4280.595 ms plan:
2- Query Text: SELECT count(*) FROM t_demo GROUP BY id % 2;
3- GroupAggregate (cost=1605370.36..1805371.32 rows=10000048 width=12)
4- (actual time=3667.207..4280.582 rows=2 loops=1)
5- Group Key: ((id % 2))
6- -> Sort (cost=1605370.36..1630370.48 rows=10000048 width=4)
7- (actual time=3057.351..3866.446 rows=10000000 loops=1)
8- Sort Key: ((id % 2))
9- Sort Method: external merge Disk: 137000kB
10- -> Seq Scan on t_demo (cost=0.00..169248.60 rows=10000048 width=4)
11-  (actual time=65.470..876.695 rows=10000000 loops=1)

مزیت این رویکرد این است که شما می‌توانید کوئری های کند را به راحتی شناسایی کنید و ببینید که چه زمان کوئری در مورد برنامه تصمیم اشتباهی می‌گیرد. با این حال جمع‌آوری اطلاعات هنوز مشکل است چرا که ممکن است میلیون‌ها کوئری در برنامه داشته باشید.

چک کردن Pg_Stat_Statements

روش سوم استفاده از pg_stat_statements است. ایده این روش گروه‌بندی کوئری‌های یکسانی است که فقط پارامترهای متفاوتی دارند. فعال کردن این ویژگی به شما کمک می‌کند که از همه اتفاقات سیستم باخبر شوید. برای فعال کردن pg_stat_statements خط زیر را به Postgresql.conf اضافه کرده وسیستم را ری‌استارت کنید:

1- shared_preload_libraries = 'pg_stat_statements'

سپس CREATE EXTENSION pg_stat_statements را در دیتابیس خود اجرا کنید و Postgresql برای شما یک نما ایجاد می‌کند.

1- test=# CREATE EXTENSION pg_stat_statements;
2- CREATE EXTENSION
3- test=# \d pg_stat_statements
4- View "public.pg_stat_statements"
5- Column        |       Type       | Collation | Nullable | Default
6- ---------------------+------------------+-----------+----------+---------
7- userid               | oid              |           |          |
8- dbid                 | oid              |           |          |
9- queryid              | bigint           |           |          |
10-query                | text             |           |          |
11-calls                | bigint           |           |          |
12-total_time           | double precision |           |          | 
13-min_time             | double precision |           |          |
14-max_time             | double precision |           |          |
15-mean_time            | double precision |           |          |
16-stddev_time          | double precision |           |          |
17-rows                 | bigint           |           |          |
18-shared_blks_hit      | bigint           |           |          |
19-shared_blks_read     | bigint           |           |          |
20-shared_blks_dirtied  | bigint           |           |          |
21-shared_blks_written  | bigint           |           |          |
22-local_blks_hit       | bigint           |           |          |
23-local_blks_read      | bigint           |           |          |
24-local_blks_dirtied   | bigint           |           |          |
25-local_blks_written   | bigint           |           |          |
26-temp_blks_read       | bigint           |           |          |
27-temp_blks_written    | bigint           |           |          |
28-blk_read_time        | double precision |           |          |
29-blk_write_time       | double precision |           |          |

این نما به ما می‌گوید که کدام کوئری چند بار اجرا شده است و در مورد کل زمان اجرای کوئری‌ها و همچنین در مورد توزیع زمان اجرا برای دسته‌های مختلف از کوئری‌ها به ما اطلاعات می‌دهد.
در ادامه می‌توانید داده های به دست آمده از pg_stat_statments را مورد آنالیز نیز قرار دهید.
مزیت این روش در این است که شما می‌توانید میلیون‌ها کوئری سریع را پیدا کنید. علاوه بر آن این روش در مورد رفتار I/O کوئری‌های نیز به شما اطلاعات می‌دهد. نکته منفی اینجا ست که دنبال کردن کوئری‌هایی که بیشتر مواقع سریع و بعضی اوقات کند هستند مشکل است.

نتیجه

در پایان بایستی بدانید که از چه تکنیکی، چه زمانی استفاده کنید تا بتوانید کوئری‌های آهسته را به خوبی تشخیص دهید. امیدواریم این مطلب به شما ایده کلی در زمینه ردیابی مشکلات عملکردی سیستم را داده باشد. در صورتی که از دیتابیس ابری پستگرس پنکیک استفاده می‌کنید، می‌توانید از داشبورد دیتابیس لاگ‌های پستگرس را مشاهده کنید.

افزایش کارایی خواندن از دیتابیس های postgres

امروزه PostgreSQL  سریع ترین نرم افزار مدیریت دیتابیس در دنیا است با این وجود توسعه دهنده گان هنوز ترجیح میدهند از یک سیستم Non-relational استفاده کنند؛ فقط و فقط به خاطر یک مسئله: مقیاس گذاری

تفکری که حول PostgreSQL وجود دارد به این صورت است: PostgreSQL یک دیتابیس رابطه‌ای است، دیتابیس های رابطه‌ای برای مقیاس گذاری مناسب نیستند پس از دیتابیس های غیر رابطه‌ای استفاده کنیم.

هرچند این سیستم‌های غیر رابطه‌ای ممکن است برای مقیاس گذاری مناسب باشند اما معایبی هم دارند: قابلیت اطمینان پایین، ضعف در اجرای کوئری، مشکلات سازگاری.

حالا بیایید ببینیم منظور از scalability چیست؟

وقتی صحبت از مقیاس پذیری میشود میدانیم که توسعه دهندگان معمولا به دنبال ترکیبی از 3 مورد زیر هستند:

  • عملکرد بهتر در Insert
  • عمکرد بهتر در read
  • قابلیت دسترسی بهتر (که عمدتا به مقیاس پذیری ربطی نداشته ولی باز هم یکی از دلایل به شمار می‌‌آید)

PostgreSQL  از 2 ویژگی بالا یعنی عملکرد بهتر در read و قابلیت دسترسی بهتر با استفاده از یک ویژگی به نام همانندسازی جریان (streaming replication) استفاده میکند.

بنابراین اگر workload شما زیر 50 هزار insert در ثانیه است نباید مشکلی با مقایس پذیری از طریق PostgreSQL داشته باشید.

در این مطلب ما در مورد مقیاس پذیری و قابلیت دسترسی در PostgreSQL با استفاده از همانندسازی جریان توضیح میدهیم.

 

نحوه کار همانندسازی جریانی در PostgreSQL

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

همانندسازی با انتقال مداوم بخش‌های WAL  از سرور اصلی به هر رپلیکیشن مرتبط کار میکند.

 

WAL  چیست؟

قبل از آنکه بیشتر به replication بپردازیم، ببینیم منظور از WAL چیست؟

WAL(write ahead along) یک سری دستورالعمل است که از هر تغییر کوچک در دیتابیس باخبر میشود.

استفاده کردن از WAL در دیتابیس، یک روش متداول در سیستم‌های پایگاه داده برای اطمینان از atomicity و تداوم است.  به خصوص تداوم اهمیت بسیار دارد؛ با این تصور که وقتی دیتابیس یک transaction انجام میدهد، داده ی حاصل شده در آینده قابل جستجو است، حتی زمانی که سرور اصطلاحا crash میشود. اینجا ست که WAL وارد عمل میشود.

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

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

حال اگر سرور خراب شود بعد از ری استارت میتواند تمامی تغییرات را بر روی WAL اعمال کند.

 

در حین یک عملیات عادی PostgreSQL باعث تغییر در حالت پرس و جو میشود و همزمان آنها را بر روی WAL مینویسد. اگر سرور کرش کند، سرور از WAL کمک گرفته و هر تغییری را که میتوانست به خاطر کرش سرور از بین برود را برمیگرداند.

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

 

WAL و Replication

متوجه شدیم که WAL  در صورتی خرابی و ری استارت شدن سرور به کار می آید اما یک محدودیت بزرگ هم دارد: در صورتی که دیسک خراب شود یا مشکل غیرقابل بازگشت دیگری به وجود آید WAL نمیتواند به ما کمک کند.

فرض کنید که تمام دیتای ما بر روی یک سرور است و به خاطر خرابی برای دیسک ممکن است از بین برود، بنابراین ما به چیزی نیاز داریم که ما را در مقابل خرابی های این چنینی مقاوم کند. اینجا است که replication به کمک می آید.

در اینجا PostgreSQL از یک رویکرد زیرکانه استفاده میکند، به جای آن که از یک ساختار کاملن جدا بسازد که از replication استفاده کند، از WAL به عنوان یک ابزار استفاده کرده و آن را برای بقیه سرورها میفرستد، حالا ما یک رپلیکیشن کامل از دیتابیس خود بر روی یک سرور دیگر داریم!

در تصویر بالا میبینیم که سرور اصلی در هر دو حالت read/write تمامی تغییرات داده را کنترل میکند (insert, update,delete) ، برای تمامی transaction ها برنامه ریزی میکند و محل ذخیره، آپدیت، پاک کردن اطلاعات را مشخص میکند،. هرگونه دستورالعمل حاصل از تغییر دیتابیس به WAL ارسال میشود و در این میان یک پیام به مشتری نیز ارسال میشود.
در حالت عادی وقتی در recovery mode قرار داریم، نوشتن و خواندن بر روی دیتابیس مجاز نیست، و یک سرور رپلیکیشن را میتواند بر روی حالت hot standby قرار دهد. این حالت اجازه write را گرفته و شما در وضعیت read-only قرار میگیرید. در نتیجه میتوانید در حالی که تغییرات دیتا در حال استریم شدن است از سرور رپلیکیشن برای خواندن استفاده کنید.

حالات مختلف رپلیکیشن برای موقعیت های مختلف

PostgreSQL از 3 نود اصلی در رپلیکیشن استفاده میکند، که هرکدام از آن ها مقادیر تکرار داده را که قبل از اینکه یک write رخ بدهد اعمال میکند.
Asynchronous replication بعد از اینکه دیتا بر روی WAL اصلی نوشته شد آن را به کلاینت بر میگرداند، اما
Synchronous Write زمانی که برروی WAL نوشته شد این مقدار را برمیگرداند

Asynchronous replication(همانندسازی آسنکرون)

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

Write performance (عملیات نوشتن):

رپلیکیشن به صورت async معروف ترین نوع برای انجام insert ها است. کلاینت ها فقط بایستی منتظر سرور اصلی برای نوشتن WAL باشند. هرگونه تاخیر بین سرور اصلی و سرور رپلیکیشن از مدت زمان نوشتن که مشتری آن را میبیند جدا است.

Read consistency (عملیات خواندن):

از آنجایی که تضمینی وجود ندارد که داده ها پس از نوشتن به صورت موفقیت آمیز به رپلیکیشن منتقل شوند، این حالت ممکن است منجر به ناسازگاری موقت داده ها بین سرور اصلی و سرور رپلیکیشن شود.
تا زمانی که WAL مربوطه به رپلیکیشن نپیوندد و به دیتابیس آن اعمال نشود، مشتریانی که از این رپلیکیشن ها میخوانند، اطلاعات جدید را در کوئری خود نخواهند دید.

Data loss (از دست رفتن دیتا):

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

Synchronous write replication:

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

Write performance (عملیات نوشتن):

عملکرد write در این نوع رپلیکیشن حرکت کندتری نسبت به asynchronous دارد.

Data Loss (از دست رفتن دیتا):

از دست دادن دیتا در این حالت هنوز امکان پذیر است هرچند که نسبت به اجرای async کم تر شده است، در اکثر موارد synchronous هر دو سرور هم اصلی و هم رپلیکیشن دچار کرش میشوند.

Synchronous apply replication:

نه تنها تضمین میکند که WAL برای همه رپلیکیشن ها به صورت مشخص نوشته شده است بلکه تمام بخش های WAL در پایگاه داده اعمال میشوند.

Write performance (عملیات نوشتن):

از آنجایی که مشتری باید منتظر بماند تا کلیه عملیات نوشتن در سرور اصلی و رپلیکیشن انجام شود، این حالت کندترین نوع ممکن است.

Read performance (عملیات خواندن):

تضمین میکند که هر رپلیکیشن مشخص شده به طور کامل با سرور اصلی سازگار باشد و عملیات write تاز مانی که در پایگاه داده اعمال نشود موفقیت آمیز تلقی نخواهد شد.

Data loss (از دست رفتن دیتا):

در مورد از دست دادن دیتا، این نوع از رپلیکیشن حتی تضمین بهتری نسبت به 2 مورد قبلی است.
در هر نوع تنظیماتی از synchronous apply، پایگاه داده اصلی و تمامی رپلیکیشن ها به صورت پایدار خواهند بود.

نحوه به روزرسانی PostgreSQL 10 به 11

امروزه یکی از سخت‌ترین کارها هنگام کار کردن با PostgreSQL، پیدا کردن راه حلی برای آپگرید کردن است، برای انجام بروزرسانی‌ها باید به روش هایی نظیر pg_upgrade، دامپینگ و بازیابی و یا استفاده از ابزارهای دیگری مانند Slony یا Bucardo فکر کنید، که البته هرکدام معایبی دارند.
حال چرا این اتفاق مشکلات وجود داشت؟ به خاطر اینکه راه حل PostgreSQL برای توزیع داده‌ها یا همان رپلیکیشن Replication بصورت اصطلاحا فیزیکی انجام می‌شد. نحوه عملکرد آن به این صورت است که: تغییرات را در سطح پایین بصورت بایت بایت انجام می‌دهد و یک کپی مشابه از پایگاه داده را در یک سرور دیگر ایجاد می کند. این روش هنگام به روز رسانی دارای معایبی نیز هست؛ مثلا شما به سادگی نمی‌توانید در یک نسخه دیگر سرور یا معماری دیگری همانندسازی کنید.

حال اینجا است که PostgreSQL 10 تفاوت‌ها را رقم میزند؛ با استفاده از این نسخه و هم چنین نسخه 11، PostgreSQL پیاده‌سازی رپلیکیشن را به صورت تکرار منطقی انجام می‌دهد که بر خلاف تکرار فیزیکی می‌تواند بین نسخه‌های مختلف و اصلی PostgreSQL همانندسازی (Replication) را انجام دهد.

در این مقاله خواهیم دید که Logical Replication چیست و اساس کار آن چگونه خواهد بود و در ادامه‌ی این مطلب، آموزشی برای به روزرسانی PostgreSQL 10 به 11 یا حتی ۱۲ خواهیم داشت.

Logical Replication چیست؟
تکرار منطقی یا همان Logical Replication روشی است برای تکرار اشیا داده‌ها و تغییرات آن‌ها، براساس هویت همانندساز آن‌ها (معمولا یک کلید اصلی)، که مبتنی بر یک حالت انتشار و اشتراک است، جایی که یک یا چند subscriber در یک یا چند منتشرکننده مشترک هستند.
انتشار مجموعه‌ای از تغییرات است که توسط جدول یا گروهی از جداول ایجاد می‌شود (همچنین به آن مجموعه تکرار نیز گفته می‌شود). به گره‌ای که یک انتشار در آن تعریف شده ناشر گفته می‌شود.

اشتراک یا subscription قسمت پایین دست تکرار منطقی است؛ گره‌ای که در آن اشتراک تعریف شده باشد به عنوان subscriber شناخته می‌شود و اتصال به دیتابیس دیگر و دریافت مجموعه‌ای از انتشارات را فراهم می‌کند. Subscribe ها، داده هایی را از انتشاراتی که در آن مشترک می‌شوند جمع می‌کنند.

همانندسازی منطقی با معماری‌ای شبیه به تکرار جریان فیزیکی ساخته شده است؛ که با عملیات اجرایی “WalSender” اجرا می‌شود. فرآیند walsender رمزگشایی منطقی WAL را آغاز می‌کند و پلاگین رمزگشایی منطقی استاندارد را بارگذاری می‌کند. این پلاگین تغییرات خوانده شده از WAL را به پروتکل تکرار منطقی تبدیل می‌کند و داده‌ها را مطابق مشخصات انتشار فیلتر می‌کند.
سپس داده‌ها به طور پیوسته با استفاده از پروتکل تکرار جریان به worker متقاضی داده می‌شوند که داده‌ها را در جداول محلی ترسیم می‌کند و تغییرات را در صورت دریافت، به ترتیب صحیح تراکنش اعمال می‌کند.

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

پس از این که هماهنگ‌سازی‌ها انجام شد، کنترل همانندسازی جدول به فرآیند اصلی‌ای که همانندسازی در آن جا به صورت نرمال انجام می‌شود داده خواهد شد؛ در ادامه تغییرات در ناشر به subscriber ها و به صورت real-time ارسال می‌شود.

در ادامه این مطلب و پست بعدی می‌بینیم که چطور postgreSQL10 را به 11 ارتقا دهیم.