mysql ha dbaas

دسترسی پذیری بالا برای MySQL و MariaDB: مقایسه رپلیکیشن مستر-مستر با گالرا کلاستر

گالرا کلاستر (Galera Cluster) یکی از راهکارهای جدید پیاده‌سازی دسترسی بالا (High Availability) برای دیتابیس‌های MySQL و MariaDB است که نسبت به رپلیکیشن MySQL پیشینه کوتاه‌تری دارد. رپلیکیشن (Replication) MySQL، که بصورت درونی (native) از نسخه MySQL v3.23 پشتیبانی می‌شود، بصورت master-slave طراحی شده است اما با تغییر تنظیمات می‌توان آن را بصورت مستر-مستر (master-master) هم پیاده‌سازی کرد. گرچه پیاده‌سازی آن نسبتا آسان است و برای بعضی کاربردها جواب می‌دهد، اما محدودیت‌هایی هم دارد. در طرف دیگر، گالرا کلاستر تکنولوژی متفاوتی است پیاده‌سازی و مدیریت آن نیازمند دانش مروبط به خودش است.

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

رپلیکیشن دیتابیس چیست؟

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

رپلیکیشن MySQL

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

mysql replication

ابتدا رویداد به صورت باینری در لاگ باینری نود مستر MySQL ذخیره می‌شود. سپس نود یا نودهای slave بوسیله slave_IO_thread رویدادهای باینری را از لاگ‌های نود مستر پول (pull) کرده و در لاگ relay خودشان ذخیره می‌کنند. سپس slave_SQL_thread این رویدادها را خوانده و بصورت آسنکرون (Asynchronous) در پایگاه داده خود اعمال می‌کنند. با توجه به ذات آسنکرون این رپلیکیشن، تضمینی وجود ندارد که نود رپلیکا، در همان لحظه‌ی انجام تراکنش در نود مستر، اطلاعات جدید را اعمال کند.

به صورت ایده‌آل نودهای slave در رپلیکیشن دیتابیس MySQL با تنظیمات read_only=ON  یا super_read_only=ON  بصورت فقط خواندنی کانفیگ می‌شوند تا ارسال دستورات write تصادفی به این نودها، باعث ایجاد تناقض بین نودهای مستر و رپلیکا نشود. این ناهماهنگی بین نودهای رپلیکیشن مخصوصا هنگام failover ممکن است باعث بروز خطا شود. ولی در رپلیکیشن master-master باید آپشن فقط خواندنی در نود مستر دوم غیرفعال باشد تا امکان پردازش نوشتن‌های همزمان بین نودهای مستر وجود داشته باشد. در این سناریو با استفاده از آپشن CHANGE MASTER در مستر اول این امکان فراهم می‌شود تا بصورت چرخشی نود مستر اول هم با نود مستر دوم سینک شود.

رپلیکیشن گالرا کلاستر

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

Galera replication

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

جلوگیری از تصادم کلید اصلی در کلاستر MySQL

برای پیاده‌سازی رپلیکیشن مستر-مستر در دیتابیس MySQL باید افزایش خودکار کلیدهای اصلی پایگاه داده را طوری تنظیم کرد تا به مشکل تصادم کلید اصلی (Primary Key Collision) بین نودهای مستر برنخوریم؛ به این صورت که کلیدهای اصلی در نودهای مختلف به گونه‌ای افزایش یابند که با هم همپوشانی نداشته و در نتیجه یک شماره دو بار استفاده نشود. این کانفیگ باید براساس تعداد نودهای مستر در کلاستر،‌ به صورت دستی تنظیم شود. در زیر نمونه‌ای از تنظیمات نودهای مستر در رپلیکیشن مستر-مستر MySQL (در فایل my.cnf) را مشاهده می‌کنید.

Master1:
log-slave-updates
auto_increment_increment=2
auto_increment_offset=1

Master2:
log-slave-updates
auto_increment_increment=2
auto_increment_offset=2

مقدار auto_increment_increment باید در هر نود مستر برابر با تعداد کل مسترهای کلاستر باشد. متغیرهای auto_increment_offset هم باید با مقادیر منحصر به فرد در هر پایگاه داده مستر تنظیم شوند.

به طریق مشابه گالرا کلاستر هم راهکاری برای جلوگیری از تصادم کلیدهای اصلی در دیتابیس دارد؛ در این راهکار مقدار افزایش خودکار کلید اصلی بصورت خودکار و با استفاده از متغیر wsrep_auto_increment_control انجام می‌شود. در صورتی که این متغیر یک باشد (که بصورت پیشفرض هست) گالرا کلاستر متغیرهای auto_increment_increment و auto_increment_offset را بصورت خودکار و براساس تعداد نودهای مستر تنظیم می‌کند. مسلما در کلاسترهای master-slave این متغیر باید غیرفعال یا off باشد. جدول زیر نمونه‌ای از مقادیر کلید اصلی در یک کلاستر MySQL با ۳ نود مستر را نشان می‌دهد.

Auto increment valueAuto_increment_offsetAuto_increment_incrementNode
1, 4, 7, 10, 13, 16…13Node 1
2, 5, 8, 11, 14, 17…23Node 2
3, 6, 9, 12, 15, 18…33Node 3

اگر یک برنامه عملیات اینسرت (INSERT) را با ترتیب زیر روی این کلاستر MySQL انجام دهد:

Node1, Node3, Node2, Node3, Node3, Node1, Node3 ..

کلیدهای اصلی ذخیره شده در جدول دیتابیس به این صورت خواهد بود:

1, 6, 8, 9, 12, 13, 15 ..

به طور ساده، در صورتی که از رپلیکیش مستر-مستر استفاده می‌کنید (چه رپلیکیشن MySQL چه گالرا کلاستر)، برنامه شما باید قابلیت تحمل کلیدهای اصلی نامتوالی را داشته باشد.

همخوانی یا سازگاری (Consistency) داده‌ها در کلاستر MySQL

گالرا کلاستر دارای یک مکانیزم کنترل جریان داده است که به نودهای یک کلاستر دیتابیس MySQL این امکان را می‌دهد تا در اعمال تغییرات از بقیه نودها عقب نیفتند؛ به این صورت که بقیه نودها سرعت اعمال تغییرات را کم می‌کنند تا نود کم سرعت از سینک خارج نشود. با این راهکار، احتمال لگ بین نودها به حداقل می‌رسد. به صورت پیش‌فرض Galera Cluster به نودهای کلاستر دیتابیس اجازه می‌دهد تا حداکثر ۱۶ تراکنش عقب بیفتند (که با متغیر gcs.fc_limit قابل تنظیم است). چنانچه بخواهید یک کوئری SELECT مهم انجام دهید که نیاز به به‌روزترین داده‌ها داشته باشد، باید قبل از انجام کوئری نشست wsrep_sync_wait را ست کنید. در این صورت پایگاه داده قفل می‌شود تا جدیدترین تراکنش‌ها را از کلاستر دریافت کند، سپس کوئری اجرا می‌شود تا جدیدترین اطلاعات را بازگرداند.

گالرا کلاستر دارای یک مکانیزم داخلی برای جلوگیری از ناسازگاری (inconsistency) داده‌ها است؛ به این صورت که اگر نودی به هر دلیلی نتواند writeset های کلاستر را اعمال کند، از گالرا کلاستر خارج می‌شود. این خروج با پیام‌های خطای زیر همراه خواهد بود:

 [ERROR] WSREP: Failed to apply trx 1 4 times
 [ERROR] WSREP: Node consistency compromized, aborting..

برای اینکه نود بتواند مجددا وارد کلاستر شود، باید دیتابیسِ نود ناسازگار مجددا سینک شود. این عمل می‌تواند به صورت دستی یا بازگردانی خودکار یک اسنپ شات (snapshot) انجام شود.

رپلیکیشن مستر-مستر خودِ MySQL اما سازگاری داده‌ها را اجبار نمی‌کند و این امکان وجود دارد که یکی از نودها از اعمال داده‌های جدید عقب بیفتد. بررسی ناسازگاری پایگاه داده در این سناریو یا باید بصورت دستی انجام شود، یا با ابزارهای دیتابیس پرکونا (Percona) مانند pt-table-checksum و mysql-replication-check.

حل تعارض در دیتابیس

به طور ذاتی کلاسترهای دیتابیس مستر-مستر به بیش از یک نود یا عضو کلاستر این امکان را می‌دهند تا کوئری‌های write را پردازش کنند. در رپلیکیشن داخلی MySQL مکانیزم خودکاری برای حل تعارض‌های احتمالی بین نودهای کلاستر MySQL وجود ندارد. در صورت بروز تعارض، پروسه SQL از اعمال کوئری‌های جدید خودداری کرده تا مشکل بصورت دستی (یا با اسکیپ کردن رویداد یا سینک مجدد دیتابیس) حل شود.

در طرف دیگر، گالرا کلاستر راهکار بهتری برای حل تعارض در رپلیکیشن دیتابیس دارد. با تنظیم متغیر wsrep_retry_autocommit می‌توان کلاستر MySQL را مجبور کرد تا در صورت تعارض مجددا تراکنش را اعمال کند. این متغیر بصورت پیشفرض ۱ است و برای غیر فعال کردن آن می‌توان مقدار آن را صفر گذاشت. این متغیر مخصوصا به درد برنامه‌هایی می‌خورد که می‌خواهند کامیت خودکار (Autocommit) آن‌ها با ددلاک (deadlock) مواجه نشود.

اجماع نودها و failover در کلاستر MySQL

گالرا کلاستر از پروتکل GCS (Group Communication System) برای اجماع کلاستر و بررسی دسترسی‌پذیری نودهای کلاستر MySQL استفاده می‌کند. در صورتی تایم اوت نود (پارامتر gmcast.peer_timeout که پیشفرض ۳ ثانیه است) پر شود، وضعیت نود به unhealthy تغییر کرده و بصورت خودکار از کلاستر اخراج می‌شود. یک نود گالرا در صورتی که در وضعیت synced قرار داشته باشد، healthy تلقی شده و به کوئری‌های read و write پاسخ می‌دهد. این مکانیزم، راهکارهای healthcheck توسط لایه‌های بالاتر (مانند لود بالانسر load balancer) را بسیار راحت می‌کند.

در رپلیکیشن داخلی MySQL، نود مستر اهمیت چندانی به نودهای slave نمی‌دهد، نودهای slave هم به صورت مجزا و از طریق پروسه slave_IO_thread سینک بودن خود با نود مستر و دریافت رویدادهای باینری از آن را بررسی می‌کنند. در صورت fail شدن نود مستر، رپلیکیشن هم شکسته شده و نودهای slave هر ۶۰ ثانیه (مقدار پیشفرض برای slave_net_timeout) اقدام به اتصال مجدد به نود مستر می‌کنند. از دید load balancer در این راهکار، مکانیزم health check باید مقادیر زیر را بررسی کند:

Seconds_Behind_Master

Slave_IO_Running

Slave_SQL_Running

read_only variable

super_read_only variable (MySQL 5.7.8 and later)

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

اضافه کردن نودهای جدید به کلاستر دیتابیس MySQL

در رپلیکیشن داخلی MySQL عملیات اضافه کردن نود جدید به کلاستر دیتابیس بصورت دستی انجام می‌شود. به این صورت که قبل از ایجاد رپلیکیشن جدید،‌ باید یک پکاپ از نود مستر گرفته شده و به نود جدید انتقال داده شود. برای نودهای فعلی هم که رپلیکیشن آن‌ها بر اساس expire_logs_days شکسته شده است، همین روند می‌تواند برای عضویت مجدد نود به کلاستر هم انجام شود. البته ابزارهای مختلفی، مانند تولکیت پرکونا (Percona Toolkit) برای کمک به این روند در رپلیکیشن MySQL وجود دارند. همچنین با استفاده از ClusterControl می‌توان عملیات سینک مجدد نود کلاستر دیتابیس را با دو کلیک (از طریق کپی مستر فعلی یا بکاپ دیتابیس قبلی) انجام داد.

در گالرا کلاستر دو روش برای اضافه کردن نود جدید به کلاستر دیتابیس MySQL وجود دارد؛ روش اول: IST یا انتقال رویداد پلکانی (incremental state transfer)،‌ روش دوم: SST یا انتقال بصورت اسنپ شات (state snapshot transfer). برای مواردی که فقط چند تراکنش از دست رفته‌اند، روش IST اولویت دارد. روش SST مانند گرفتن یک بکاپ کامل (Full Backup) و انتقال آن عمل می‌کند و از نظر پردازشی نسبتا سنگین است. کلاستر گالرا بصورت خودکار و بر اساس وضعیت کلاستر بهترین روش را برای سینک دیتابیس انتخاب می‌کند. در مواردی که اضافه کردن نود جدید به کلاستر گالرا با خطا روبرو می‌شود، کافی است محتویات دایرکتوری datadir در MySQL را پاک کنید و مجددا سرویس MySQL را اجرا کنید. روند اضافه کردن نود جدید به گالرا کلاستر ساده است و افزایش مقیاس کلاستر دیتابیس و رفع مشکلات نودهای خراب را بسیار راحت می‌کند.

اتصال سفت در برای اتصال سست در کلاستر پایگاه داده

جفت شدن پایگاه‌داده‌ها در رپلیکیشن داخلی MySQL به اصطلاح سست (Loosely Coupled) است؛ به عبارت دیگر، میزان وابستگی بین نودهای مختلف کم است. رپلیکیشن MySQL با اتصالات کم سرعت و روی سخت‌افزارها و سیستم‌عامل‌های مختلف به راحتی کار می‌کند. همچنین از موتورهای ذخیره‌سازی گوناگون مانند MyISAM، Aria، MEMORY و ARCHIVE پشتیبانی می‌کند. مجموعه این ویژگی‌ها باعث شده تا کلاستر MySQL اصطلاحا سست باشد و رپلیکیشن مستر-مستر را در محیط‌های متفاوت راحت‌تر کند.

در مقابل، اتصال نودها در کلاستر گالرا محکم (Tightly Coupled) است؛ به عبارت دیگر، وابستگی نودها در رپلیکیشن مستر-مستر به یکدیگر بالا بوده و سرعت رپلیکیشن به اندازه سرعت کندترین نود در کلاستر است. گالرا دارای مکانیزم کنترل جریان داده در رپلیکیشن است و به صورت خودکار سرعت رپلیکیشن بین نودهای مختلف را تنظیم می‌کند؛ این مکانیزم می‌تواند باعث افزایش یا کاهش سرعت در همه نودها شود. بنابرین توصیه می‌شود در کلاستر MySQL گالرا از منابع و زیرساخت مشابه (پردازشگر، رم، دیسک و سرعت شبکه و تاخیر) برای همه نودها استفاده شود.

نتیجه‌گیری

گالرا کلاستر در برابر رپلیکیشن مستر-مستر MySQL برتری محسوسی دارد. پشتیبانی از رپلیکیشن آسنکرون، سازگاری بالا و ویژگی‌های پیشرفته مانند کنترل عضویت خودکار و slave های چند نخی (multi-threaded)، انتخاب گالرا کلاستر برای رپلیکیشن MySQL را بسیار راحت می‌کند. با توجه به موارد ذکر شده، به طور خلاصه موارد استفاده از هر کدام از رپلیکیشن‌های MySQL به صورت زیر است:

در چه کاربردهایی از رپلیکیشن داخلی MySQL استفاده کنیم؟
  • زمانی که منابع، زیرساخت و سرعت شبکه هر کدام از نودهای master متفاوت باشد (سناریو Loosely Coupled).
  • زمانی که از قبل از رپلیکیشن داخلی MySQL استفاده می‌کنید و می‌خواهید برای افزونگی بیشتر (redundancy) یک نود جدید به کلاستر اضافه کنید.
  • مواقعی که برنامه کاربردی شما قابلیت کنار آمدن با محدودیت‌های گالرا کلاستر نداشته و امکان استفاده از یک لود بالانسر SQLی مانند ProxySQL یا MaxScale را ندارید.
محدودیت‌ها و مواردی که گالرا کلاستر ساپورت نمی‌کند:
  • جدول‌های غیر از InnoDB.
  • تراکنش‌های XA.
  • رپلیکیشن مبتنی بر Statement بین مسترها.
  • وابستگی به استفاده مستقیم از قفل جدول (LOCK TABLES statement).
  • لاگ عمومی دیتابیس و لاگ کوئری‌های کند (Slow Query Log) بجای فایل در جدول ذخیره می‌شوند.
دلایلی که از گالرا کلاستر برای رپلیکیشن MySQL استفاده کنیم؟
  • قابلیت اعمال ایمن کوئری‌های write روی مسترهای مختلف.
  • مدیریت خودکار سازگاری داده‌ها بین دیتابیس‌های مختلف.
  • اضافه و سینک کردن آسان نودهای جدید به کلاستر پایگاه داده.
  • پاک کردن خودکار خطاها و ناسازگاری‌ها.
  • ویژگی‌های HA (High Availability) پیشرفته‌تر.
  • پشتیبانی از کلاستر MariaDB.

منبع

دیتابیس ابری مدیریت شده پنکیک

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

 

database backup plans

آموزش بکاپ گیری از دیتابیس MySQL

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

روش‌های بکاپ گیری از دیتابیس MySQL

روش‌های مختلفی برای بکاپ گیری (Backup) از پایگاه داده MySQL وجود دارد که براساس نحوه پیاده سازی سرویس شما و زیرساختی که از آن استفاده می‌کنید متفاوت است. چنانچه سایت یا اپلیکیشن خود را بطور مستقیم روی سرور مجازی پیاده سازی کرده‌اید، باید از ابزار mysqldump برای بکاپ استفاده کنید. اگر در کنار سرویس‌های سایت یا اپلیکیشن خود، ابزار phpMyAdmin را هم نصب کرده‌اید، می‌توانید از رابط گرافیکی آن برای دانلود نسخه پشتیبان از پایگاه داده خود استفاده کنید. همچنین در صورتی که سرویس دهنده شما پنل دایرکت ادمین یا cpanel در اختیار شما قرار داده یا از ارائه دهندگان دیتابیس ابری خدمت می‌گیرید، می‌توانید به راحتی از پرتال آن‌ها برای زمان‌بندی و بک آپ گیری دیتابیس خود استفاده کنید. در ادامه هر کدام از این روش‌ها را با جزئیات بیشتر شرح می‌دهیم.

نحوه بکاپ گیری از دیتابیس با استفاده از خط فرمان CLI سرور

اگر سایت یا نرم افزار شما بدون واسطه روی سرور لینوکسی نصب شده که مدیریت آن بر عهده‌ی خود شماست، می‌توانید براحتی با استفاده از ابزار  mysqldump (که بصورت پیش‌فرض با دیتابیس mysql نصب می‌شود) از دیتایس بکاپ بگیرید. برای این کار به سرور خود ssh زده و دستور زیر را با دسترسی روت اجرا کنید:

$ sudo mysqldump -u [user] -p [database_name] > [filename].sql

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

$ mysqldump --all-databases --single-transaction --quick --lock-tables=false > full-backup-$(date +%F).sql -u root -p

نحوه برگرداندن بکاپ دیتابیس با استفاده از خط فرمان CLI سرور

بازگردانی (Restore) بکاپ دیتابیسی که با استفاده از خط فرمان گرفته‌اید هم به اندازه بکاپ گیری آن ساده بوده و با یک خط انجام می‌شود. فقط به خاطر داشته باشید که برای برگرداندن بکاپ باید بجای mysqldump از دستور mysql استفاده کنید:

$ mysql -u [user] -p [database_name] < [filename].sql

نحوه بکاپ گیری از MySQL با استفاده از phpMyAdmin

یکی از ابزارهای اختیاری که مدیریت پایگاه داده MySQL را تسهیل می کند phpMyAdmin است. اگر این ابزار را روی سرور دیتابیس خود نصب کرده‌اید، می‌توانید از آن برای بکاپ گیری دیتابیس خود استفاده کنید.

برای این کار ابتدا وارد پنل phpMyAdmin شده و از ستون سمت چپ دیتابیس مورد نظر خود را انتخاب کنید.

سپس از نوار بالا روی لینک Export کلیک کنید. برای سرعت بیشتر متد بکاپ quick و فرمت sql را انتخاب کرده و دکمه Go را بزنید تا فایل بکاپ شما دانلود شود.

phpmyadmin database backup

نحوه برگرداندن بکاپ دیتابیس MySQL با استفاده از phpMyAdmin

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

بنابراین همیشه قبل از بازگردانی فایل پکاپ دیتابیس، دیتابیس فعلی را پاک کنید. برای این کار از ستون سمت چپ phpMyAdmin پایگاه داده مورد نظر خود را انتخاب کنید. سپس در انتهای لیست جدول‌ها گزینه Check All را انتخاب کرده و در لیست مقابل آن Drop را بزنید. برای تایید دکمه Yes را بزنید.

حالا برای بازگردانی بک آپ دیتابیس همانند ساخت بکاپ، روی دیتابیس مورد نظر کلیک کنید، فقط این بار بجای گزینه Export گزینه Import را انتخاب کنید. فایل بکاپ پایگاه داده را انتخاب کرده و دکمه Go را بزنید.

نحوه بکاپ گرفتن از دیتابیس در فضای ابری

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

یکی از روش‌های بهینه برای ذخیره سازی و نگهداری بک آپ های دیتابیس استفاده از فضای ابری است. فضای ذخیره سازی ابری که پرکاربردترین نوع آن آبجکت استوریج (object storage) است، به شما این امکان را می‌دهد تا فایل‌های خود را بصورت آبجکت در فضای امن و همیشه در دسترس ذخیره و نگهداری کنید. شرکت‌های ارائه‌ دهنده فضای ابری معمولا پلن‌های مختلفی متناسب با نیازهای شما ارائه می‌دهند که ذخیره‌سازی بکاپ‌های شما در فضای ابری را بسیار مقرون به صرفه می‌کند. برای مثال آمازون AWS پلن آبجکت استوریج با عنوان S3 IA (Infrequently Accessed) ارائه می‌کند؛ S3 IA یک آبجکیت استوریج برای فایل‌هایی است که به ندرت به آن‌ها نیاز خواهید داشت، دقیقا مثل فایل‌های بکاپ پایگاه داده. با استفاده از این پلن، هزینه نگهداری بکاپ‌های شما در فضای ابری بسیار پایین خواهد بود اما به ازای هر دانلود هزینه‌ای به فاکتور شما اضافه می‌شود. در ادامه نحوه بکاپ گیری از دیتابیس MySQL در فضای ابری AWS و همچنین آبجکت استوریج ابر آروان (که از استاندارد S3 آمازون AWS استفاده می‌کند) را آموزش خواهیم داد.

آموزش بک آپ گیری از دیتابیس روی آبجکت استوریج آمازون AWS

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

ابتدا یک باکت (Bucket) در کنسول آمازون AWS ایجاد کنید (دقت کنید که پلن 5GB Standard Free Tier را انتخاب کرده باشید). این قسمت در بخش S3 (زیر مجموعه Storage) قرار دارد. دقت کنید که قبل از ساخت باکت، region یا ناحیه مورد نظر خود را درست انتخاب کرده باشید. برای تغییر ناحیه از لیستی که سمت راست نوار بالای کنسول قرار دارد استفاده کنید.

حتما بعد از ساخت باکت یک حساب کاربری جدید با سطح دسترسی به باکت‌های S3 ایجاد کنید. برای این کار به بخش IAM در کنسول AWS وارد شده و از قسمت Users یک حساب کاربری جدید بسازید. هنگام ساخت یوزر جدید این موارد را رعایت کنید: اول اینکه نوع دسترسی کاربر (Access Type) را Programmatic Access انتخاب کنید تا کاربر شما امکان دسترسی با aws cli را داشته باشد. مورد دوم که باید رعایت کنید نوع permission انتخابی برای کاربر است که حتما باید شامل policy ادمین یا S3 باشد. در مرحله آخر هم حتما کلیدهای access و secret را ذخیره کنید زیرا فقط یک بار برای شما نمایش داده می‌شوند.

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

AWS Bucket Name

AWS Access Key ID

AWS Secret Access Key

بعد از ساخت باکت به ترمینال SSH سرور مجازی خود برگردید. برای اینکه امکان ذخیره سازی بکاپ دیتابیس روی فضای ابری AWS را داشته باشید باید AWS CLI را روی ماشین مجازی خود نصب کرده و Access key  و Secret Key خود را روی آن تنظیم کنید. در صورتی که از سرور مجازی AWS یا همان اینستنس EC2 استفاده می‌کنید این ابزار به صورت پیشفرض روی سرور شما نصب است.

$ apt install unzip curl
$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ unzip awscliv2.zip
$ ./aws/install
$ aws configure

بعد از زدن دستور آخر، ترمینال Access Key و Secret Key اکانت AWS شما را خواهد پرسید. اطلاعات خود را وارد کرده و اینتر کنید. از این به بعد به راحتی و تنها با یک خط می‌توانید بک آپ های دیتابیس خود را به فضای ابری AWS منتقل کنید:

$ aws s3 cp [filename].sql s3://[bucket-name]

با استفاده از دستور زیر می‌توانید لیست بکاپ‌های دیتابیس My SQL روی فضای ابری را مشاهده کنید:

$ aws s3 ls s3://[bucket-name]/

آموزش بک آپ گیری از دیتابیس روی آبجکت استوریج ابر آروان

چنانچه تمایل دارید از فضای ذخیره سازی ابری ایرانی برای نگهداری بک آپ پایگاه داده خود استفاده کنید، آبجکت استوریج ابر آروان و ایرانسل گزینه‌های مناسبی هستند. با توجه به اینکه ابر آروان دارای پلن فضای ذخیره سازی رایگان ۵ گیگابایتی (با محدودیت پهنای باند ۲۰ گیگابایت) است، ما هم در ادامه نحوه پشتیبان گیری دیتابیس روی این فضای ابری را شرح می‌دهیم. قیمت فضای ذخیره سازی آبجکت با همین مشخصات در خدمات ابری ایرانسل ماهیانه حدودا ۱۱۸۸۰ تومان است.

نحوه ذخیره سازی بکاپ دیتبایس روی فضای ابری ابر آروان بسیار شبیه به آمازون AWS است، با این تفاوت که به جای ابزار aws باید از rclone استفاده کنید. rclone قابلیت انتقال فایل به اکثر ارائه دهندگان فضای ابری، مخصوصا آن‌هایی که از استاندارد S3 آمازون استفاده می‌کنند را داراست. برای این منظور ابتدا پکیج rclone را نصب کرده و تنظیمات آن را به صورت زیر انجام دهید:

$ apt install rclone
$ rclone config

بعد از زدن آخرین دستور، لیست استوریج‌هایی که به rclone اضافه کرده‌اید را مشاهده خواهید کرد. قاعدتا این لیست باید خالی باشد. کاراکتر n  را برای اضافه کردن استوریج جدید وارد کنید. سپس یک اسم دلخواه برای سرویس دهنده خود وارد کنید، مثلا arvan. در مراحل بعدی نوع آبجکت استوریج را s3 انتخاب کرده و other را برای provider وارد کنید.

در مرحله بعدی false را انتخاب کنید تا بتوانید access key و secret key آروان را به صورت دستی وارد کنید. سپس گزینه ۱ را برای ریجن انتخاب کرده و در آخر آدرس endpoint که از ابر آروان دریافت کرده‌اید را وارد کنید.

از این پس می‌توانید با دستور زیر بک اپ های خود را به فضای ابری آروان منتقل کنید:

$ rclone copy [filename].sql arvan:[bucket-name]/[filename].sql

بکاپ گیری و بازگردانی اتوماتیک دیتابیس MySQL

راهکارهایی که تا الان بررسی کردیم مزایا و معایب متفاوتی دارند. اما مشکل یا عیب اصلی که بین همه‌ی این روش‌ها مشترک است، مدت زمان زیاد بازیابی یا ریستور دیتابیس است که Disaster Recovery Plan شما را بسیار کند می‌کند.  در صورتی که سرور عملیاتی شما دچار خرابی شده یا از دسترس خارج شود، شما نسخه‌ای از دیتابیس خود را در فضای ابری خواهید داشت، اما برگرداندن دیتابیس از فضای ابری و راه اندازی آن در سرور عملیاتی جدید زمان زیادی نیاز دارد که صدمه زیادی به سایت یا سرویس شما می‌رساند.

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

استفاده از سرویس دیتابیس ابری مدیریت شده به شما این امکان را می‌دهد تا در کنار مزایای همه روش‌های مذکور، این ۲ چالش برزگ را هم حل کنید.

بکاپ گیری و بازگردانی اتوماتیک دیتابیس با استفاده از دیتابیس ابری مدیریت شده

استفاده از دیتابیس ابری مدیریت شده به شما این توانایی را می‌دهد تا:

بکاپ اتوماتیک با فاصله زمانی کوتاه روی سرورهای عملیاتی جاری و ثالث ایجاد کنید.

هشدار کارایی و سلامت برای دیتابیس‌های خود داشته باشید.

تنها با یک کلیک و در عرض چند ثانیه بک آپ دیتابیس را روی سرور عملیاتی بازگردانید.

برای دسترسی به لیست بکاپ‌های دیتابیس ابتدا وارد پنل مدیریت پنکیک شوید. در صورتی که قبلا دیتابیس خود را ایجاد کرده باشید، سکوی ابری پنکیک بصورت خودکار هر ساعت از دیتابیس شما فول بکاپ می‌گیرد. برای مشاهده لیست بکاپ‌ها، کافی است دیتابیس مورد نظر خود را از ستون سمت راست انتخاب کرده و وارد تب Fork Database شوید. لیست نسخه‌های بکاپ دیتابیس شامل ۴۸ فول بکاپِ ساعتی از ۴۸ ساعت گذشته و همچنین ۲۸ فول بکاپِ روزانه از ۳۰ روز گذشته است.

pancake DBaaS backup

برای برگرداندن هر کدام از بکاپ‌ها کافی است روی آیکون کنار ردیف مورد نظر کلیک کرده تا در کمتر از یک دقیقه دیتابیس مورد نظر روی سرور عملیاتی ریستور شود. بک آپ گیری اتوماتیک از دیتابیس و بازگردانی آن در دیتابیس‌های ابری پنکیک منحصر به پایگاه داده ی خاصی نیست و به صورت پیش‌فرض برای همه‌ی دیتابیس‌های پنکیک شامل MySQL، PostgreSQL، MongoDB و SQL Server فعال است.

چگونه دیتابیس خود را مدیریت کنیم؟

مارکت کلود در سال ۲۰۲۰، ۱۷ درصد رشد داشته و هم اکنون به ۲۶۶.۴ میلیارد دلار رسیده است و در این بین سریع‌ترین سرویس ابری در حال رشد در حوزه دیتابیس که همه توجهات را به خودش جلب کرده است، سرویس پایگاه داده یا همان DBaaS‌ است که به نظر می‌رسد تا سال ۲۰۲۵ به تنهایی ۳۲۰ میلیارد دلار از این مارکت را در اختیار داشته باشد. در ایران اما آمار دقیقی از مارکت کلود در اختیار نیست اما امروزه تا ۶۰ درصد از صنعت ICT‌ کشور تحت تاثیر کلود قرار دارد و پیش بینی می‌شود تا پنج سال آینده مارکت کلود تا ۲۰۰ هزار میلیارد تومان نیز گسترده شود. یکی از دلایلی که سرویس‌های مدیریت دیتابیس که تحت عنوان DBaaS شناخته می‌شوند، بیشتر از سرویس های دیگر مورد استقبال قرار گرفته‌اند، انفجار داده های کاربران است. مزایایی که خدمات ابری و به خصوص سرویس پایگاه داده را برای مشتریان جذاب می‌کنند به طور کلی چند دسته هستند: چابکی و سادگی، بهره وری بالاتر و خریدن زمان برای توسعه دهنده سیستم. چرا که توسعه دهندگان دیگر مجبور نیستند هفته ها برای فرآیندهای مدیریتی پایگاه‌های داده صبر کنند. و از آن جا که نیاز به دیتابیس‌های متنوع، سریع‌تر از هر نیاز دیگری در حال افزایش است، واضح است که فضای ابری راهی است برای رسیدن به سرعت و چابکی در این حوزه. حال بیایید مثالی را بررسی کنیم که نشان می‌دهد چگونه برون سپاری دیتابیس، به توسعه دهندگان کمک می‌کند چابکی و سرعت مورد نیاز خودشان را بیابند.
حال بیایید یک سناریو که در اکثر شرکت ها اتفاق می‌افتد را بررسی کنیم. هرچند که به طور واضحی در هر شرکت ممکن است جریان‌های کاری و ساختارهای متفاوتی وجود داشته باشند ولی سناریویی که ما در مورد آن توضیح می‌دهیم نمونه‌ای از پیچیدگی در تهیه و اجرای یک دیتابیس و تحویل آن به برنامه نویس است.
تصور کنید که یک سناریوی معمول به این صورت است که برنامه نویس بک‌اند کار خود را برای نوشتن یک اپلیکیشن شروع کرده و نیاز به یک پایگاه داده پست‌گرس برای توسعه دارد. بیایید به نقش افرادی که در این پروسه دخیل می‌شوند نگاه کنیم.

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

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

راه حل سریع تر

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

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

پایگاه داده به عنوان سرویس که بیشتر با عنوان سرویس دیتابیس یا پایگاه داده مدیریت شده نیز شناخته می‌شود اولین بار در سال ۲۰۰۹ با معرفی یکی از سرویس های 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‌ است.

MongoDB یا MySQL؟

در جامعه‌ی الکترونیکی امروز که ذخیره‌سازی داده‌ها اهمیت زیادی دارند، جدال میان MongoDB و MySQL بیشتر از هر زمان دیگری شدت پیدا کرده است. در یک طرف یک دیتابیس رابطه‌ای و در سمت دیگر یک دیتابیس غیر رابطه‌ای یا همان NoSQL ایستاده است. هر دو دیتابیس متن‌باز هستند و تحت لایسنس GNU GPL توزیع یافته‌اند. هر دو نیز به صورت نسخه‌های تجاری در دسترس هستند و ویژگی‌های بسیاری را ارائه می‌دهند.

بررسی اجمالی

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

سیستم مدیریت دیتابیس رابطه‌ای (RDMS)

RDBMS زبان استاندارد برای مدیریت دیتابیس‌های رابطه‌ای است. در RDBMS داده‌ها به شکل ردیف و ستون ذخیره می‌شوند. روابط بین جداول نیز توسط Table SQL ذخیره می‌شوند. SQL یک زبان برنامه نویسی است که برای اموری مثل بازیابی داده‌ها در یک پایگاه داده و به روز رسانی داده‌ها در یک پایگاه داده استفاده می‌شود. برخی از سیستم‌های مشهور رابطه‌ای که از SQL استفاده می‌کنند عبارت‌اند از: Oracle، Sybase، Microsoft SQL، Server،Access .

ویژگی‎‏های RDBMS

1. دیتابیس‌های SQL بر پایه جداول هستند.
2. داده‌ها بر روی ردیف‌ها و ستون‌ها ذخیره می‌شوند.
3. هر سطر شامل نمونه‌ای منحصر به فرد از داده‌ها، برای دسته‌های تعریف شده از ستون‌ها است.
4. برای شناسایی منحصر به فرد ردیف‌ها می‌توانید از Primary Key استفاده کنید.

محدودیت‌های دیتابیس‌های بر پایه SQL

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

دیتابیس‌های محبوب بر پایه SQL

• MySQL: محبوب‌ترین پایگاه داده منبع‌باز و مناسب برای برنامه‌های سازمانی.

• Oracle: یک سیستم مدیریت دیتابیس رابطه‌ای که بر پایه زبان C++ نوشته شده است. Oracle همچنین یک سیستم دیتابیس No-SQL نیز روانه بازار کرده است.

• IMB DB2: خانواده‌ای از محصولات سرور پایگاه داده که IBM برای تجزیه و تحلیل کلان داده (Big Data) آن را معرفی کرده است.

• Sybase: یک سرور پایگاه داده که در ابتدا در سطح سیستم‌عامل لینوکس استفاده می‌شد و اولین DBMS سازمانی برای سیستم‌عامل لینوکس بود.

• MS SQL Server: سیستم مدیریت پایگاه داده که توسط مایکروسافت توسعه یافته است و عمدتا برای پایگاه داده‌های سازمانی که از معماری SQL و No-SQL تشکیل شده‌اند، استفاده می‌شود.

NoSQL:

NoSQL در واقع مخففی برای عبارت «Not only SQL» است. با استفاده از NoSQL می‌توان داده‌ها را در مجموعه‌هایی گرد هم آورد و دیگر نیازی به ساختار جداول نیست. از کوئری join استفاده می‌کند و می‌توانیم آن را مقیاس‌گذاری کنیم.

مزایای NoSQL:

• مقیاس پذیری آسان: در پایگاه داده‌های RDBMS با افزایش بار در دیتابیس، دیتابیس به صورت vertical مقیاس گذاری می‌شود و در نتیجه نیاز به سرور های گران قیمت‌تر و قدرتمند‌تر داریم. در NoSQL دیتابیس‌ها به صورتی طراحی شده‌اند که به صورت افقی (Horizontal) گسترش پیدا کنند و در نتیجه با افزایش منابع می‌توانیم مقیاس گذاری را انجام دهیم.

• نگهداری سرورها ارزان است: نگهداری از دیتابیس‌های RDBMS هزینه‌بر بوده و برای آن به نیروی انسانی متخصص نیاز داریم. در سوی دیگر دیتابیس‌های NoSQL به مدیریت و نظارت کمتری احتیاج دارند و از ویژگی‌های بسیاری مانند ترمیم اتوماتیک (automatic repair)، توزیع آسان داده‌ها، مدل‌های ساده‌ی داده و ویژگی‌های از این قبیل، نیازهای مدیریتی را کمتر خواهد کرد.

• هزینه پایین سرورها و متن‌باز بودن: دیتابیس‌های NoSQL ارزان و Open-Source هستند. پیاده‌سازی این دیتابیس‌ها آسان بوده و به طور معمول هزینه چندانی برای سرور دیتابیس‌ها پرداخت نخواهید کرد. این در حالی است که در RDBMS ها بایستی از سرورهای بزرگ و گران قیمت استفاده کنید. بنابراین هزینه ذخیره و پردازش داده‌ها در NoSQL بسیار کمتر از سیستم‌های RDBMS است.

• عدم وجود Schema یا مدل داده‌ای ثابت: NoSQL از مدل داده‌ای خاصی استفاده نمی‌کند بنابراین داده‌ها بدون تعریف طرح یا الگوی قبلی در دیتابیس قرار می‌گیرند. در نتیجه می‌توانید فرمت داده‌ها را هر زمان که خواستید تغییر دهید.

محدودیت ها و معایب NoSQL:

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

دیتابیس های NoSQL محبوب در بازار:

• MongoDB: محبوب‌ترین پایگاه داده که از NoSQL استفاده می‌کند. یک پایگاه داده بر پایه اسناد.
• Apache’s Couch DB: دیتابیسی مناسب برای وب که از داده‌های با فرمت JSON برای ذخیره اطلاعات و از جاوااسکریپت برای indexing و از HTTP برای API خود استفاده می‌کند.

SQL یا NoSQL: MySQL یا MongoDB

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

MySQL چیست؟

MySQL یکی از محبوب‌ترین RDBMS های موجود در بازار است که توسط شرکت Oracle توسعه داده شده و پشتیبانی می‌شود. همانند دیگر سیستم‌های رابطه‌ای، MySQL با استفاده از زبان SQL داده‌ها را در جداول ذخیره می‌کند. در MySQL طرح اولیه دیتابیس توسط شما و بر اساس نیازتان تعیین شده و از آن برای تعیین قواعد بین جداول استفاده می‌شود. برای هر تغییری در این طرح‌واره (schema) نیازمند تغییرات در دیتابیس خواهید بود و ممکن است برای لحظاتی دیتابیس خود را از دست بدهید.

مزایای MySQL:

• سازگاری: MySQL برای تمام پلتفرم‌های معروف مثل لینوکس، ویندوز، مک، BSD و سولاریس موجود است. هم چنین با زبان‌های Ruby، Node.js، Perl، Java، C++، Python و Php ارتباط برقرار می‌کند و فقط به SQL محدود نیست.

• همانندسازی (افزونگی): دیتابیس MySQL می‌تواند بر روی چندین Node مختلف همانندسازی شوند، این به این معنی است که مقیاس پذیری دیتابیس را می‌توان به راحتی تغییر داد.

MongoDB چیست؟

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

در زیر به بعضی از مزایای MongoDB اشاره می‌کنیم:
• مقیاس‌پذیری: MongoDB به صورت افقی مقیاس پذیر بوده و به شما کمک می‌کند از حجم workload خود بکاهید و کسب و کار خود را به راحتی افزایش مقیاس دهید.

• مدیریت: MongoDB به ادمین سیستم نیازی ندارد و به خاطر سهولت استفاده و یوزر فرندلی بودن، هم توسط توسعه دهندگان و هم ادمین ها قابل مدیریت است.

• انعطاف پذیری: می‌توانید بدون تاثیرگذاری بر روی عملکرد برنامه و یا ردیف‌های موجود، ستون‌ها و ردیف‌های مختلفی را اضافه کنید.

چه زمان از دیتابیس NoSQL استفاده کنیم؟

برای جلوگیری از تبدیل شدن نقاطی از دیتابیس به bottleneck، خصوصا در فضاهای با حجم بالا، دیتابیس‌های NoSQL مزیت‌هایی دارند که در دیتابیس‌های رابطه‌ای وجود ندارند:
1. ذخیره‌سازی مقادیر حجیمی از دیتا بدون نیاز به یک ساختار ویژه: دیتابیس NoSQL ذخیره سازی انواع مختلف داده را محدود نمی‌کند، به علاوه با بروز تغییرات در ساختار کسب و کار شما، می‌توانید تغییرات را به راحتی در دیتابیس اعمال کنید.

2. استفاده از Cloud Computing: استفاده از فضای ذخیره‌سازی مبتنی بر Cloud یک راه حل عالی است. استفاده از سخت افزار مقرون به صرفه برای گسترش داده های این فضا، همان چیزی است که دیتابیس‌های NoSQL برای آن طراحی شده‌اند.

در پایان برای جواب دادن به این سوال که «چه زمان از MongoDB به جای MySQL استفاده کنیم؟» باید بگوییم که بایستی اهداف بلندمدت و نیازمندی‌های پروژه را مد نظر قرار دهید.

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

سرویس دیتابیس

SQL یا NoSQL

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

ساختار داده‌ها

اولین و اصلی‌ترین عامل در تصمیم‌گیری بین این ۲ پایگاه داده، شکل داده‌های شماست. اگر داده‌های شما در درجه اول ساختار یافته باشند احتمالاً SQL انتخاب مناسبی است.

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

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

ACID مخفف ویژگی‌های زیر است:

  • Atomicity یا تجزیه ناپذیری: هر تراکنش یا کاملاً موفق می‌شود یا کاملاً شکست می‌خورد.
  • Consistency یا همخوانی (سازگاری) : داده‌هایی که به یک پایگاه داده نوشته می‌شوند باید طبق کلیه قوانین تعریف شده معتبر باشند.
  • Isolation یا انزوا: هنگامی که تراکنش‌ها به طور همزمان انجام می‌شوند، با یکدیگرتقابل نداشته و به صورت پی در پی انجام می‌شوند و عمل می‌کنند.
  • Durability یا پایایی: پس از انجام تراکنش در بانک اطلاعاتی، حتی در صورت خرابی سیستم، دائمی تلقی می‌شود.

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

بنابراین اگر داده‌های شما ساختار یافته‌اند و رعایت ACID ضروری است، SQL یک انتخاب عالی است.

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

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

با NoSQL می‌توانید:

  • مستندات بسیاری درست کنید بدون اینکه ساختار دقیق آن‌ها را از قبل تعیین کنید.

  • بدون تغییر فیلدهای مستندات موجود، فیلدهای جدیدی به دیتابیس خود اضافه کنید.

  • اسناد و مدارکی را ذخیره کنید که ساختار منحصر به فرد خود را دارند.

  • چندین پایگاه داده با ساختار و سینتکس مختلف داشته باشید.

پایگاه داده‌های NoSQL انتخاب بهتری برای ذخیره داده‌های محتوایی، پست ها، داده‌های سنسوری و دیگر داده‌های بدون ساختاری که داخل جدول نمی‌گنجند، هستند. دیتابیس های بدون ساختار با فرض انعطاف پذیری و مقیاس پذیری طراحی شده اند، به طوری که با مدل پایه همخوانی (Consistency) سازگار باشند. این مدل دارای ویژگی‌های زیر است:

دسترسی پایه:

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

حالت نرم:

حالت پایگاه داده ممکن است به مرور زمان تغییر کند.

سازگاری نهایی:

در نهایت، پایگاه داده سازگاری خود را بازیافته و داده‌ها در آینده در دسترس خواهند بود.

گرچه مدل پایه برای انعطاف پذیری بالا طراحی شده اند، بعضی پایگاه داده های NoSQL هم وجود دارند که با ACID سازگاری کامل دارند.

قابلیت جستجوی (کوئری) داده‌ها

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

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

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

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

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

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

شما هرچند وقت از داده‌ها کوئری می‌گیرید؟ چه کسی این درخواست‌ها را اجرا می‌کند؟ پاسخ این سؤالات بر انتخاب شما بین SQL و NoSQL تأثیر خواهد گذاشت!

مقیاس‌پذیری

همیشه باید میزان رشد اطلاعات خود را در نظر داشته باشید، چرا که مقیاس‌پذیری SQL و NoSQL متفاوت است.

دیتابیس‌های بر پایه SQL رشد اصطلاحاً عمودی دارند،‌ به این معنی که شما برای افزایش مقیاس پایگاه داده بایستی منابع سرور (رم، پردازشگر یا SSD) را افزایش دهید. دیتابیس‌های SQL برای پیاده‌سازی روی یک سرور طراحی شده‌اند تا بتوانند یکپارچگی داده‌ها را حفظ کنند، لذا به مقیاس‌پذیری راحتی ندارند.

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

یک مثال جالب برای مقایسه بین SQL وNoSQL کیک عروسی است، در SQL برای آنکه بتوانید به افراد بیشتری کیک بدهید باید لایه‌های بیشتری به کیک اضافه کنید اما در NoSQL می‌توانید هرچه می‌خواهید کاپ‌کیک درست کنید!

همینطور که کسب و کارتان رشد می‌کند باید به فکر دیتابیس بزرگ‌تر هم باشید، پس مقیاس‌پذیری فراموش نکنید!

مشترکات

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

به عنوان مثال MySQL که معروف‌ترین پایگاه‌داده‌ی رابطه‌ای متن باز است، MYSQL Document Store را ارائه داده است، که ساختار یک دیتابیس MySQL را به همراه قابلیت انعطاف‌پذیری و در دسترس بودن NoSQL پوشش می‌دهد، بدون اینکه نیاز به پیاده‌سازی یک NoSQL به صورت جداگانه داشته باشید.

MongoDB هم به عنوان معروف‌ترین دیتابیس NoSQL، تراکنش های multi-document با قابلیت های ACID ارائه می‌کند. پایگاه داده NoSql مدیریت شده ی AWS، به نام DynamoDB هم ویژگی های ACID را ارائه می‌دهد.

با راه اندازی آسان پایگاه داده‌های پنکیک، که دیتابیس‌ها را به صورت سرویس ارایه می‌دهد، شما می‌توانید از ۲ پایگاه داده ی SQL و NoSQL در معماری اپلیکیشن خود بهره بگیرید تا نیازهای ذخیره داده‌های خود را برآورده سازید.

حالا شما انعطاف پذیری بیشتری خواهید داشت، چه از SQL استفاده کنید یا NoSQL و حتماً قابلیت‌های بیشتری هم در آینده اضافه خواهند شد.

پایگاه‌داده‌های پنکیک

چه از SQL استفاده کنید یا NoSQL پنکیک آپشن‌های زیر را برای انتخاب ارائه می‌کند:

  • MYSQL – همانطور که اشاره شد وسیع‌ترین و محبوب‌ترین پایگاه داده رابطه‌ای.

  •  PostgreSQL – پایگاه داده متن باز در سطح سازمانی و مبتنی بر توسعه پذیری

  •  MongoDB – محبوب‌ترین نرم‌افزار پایگاه داده ی NOSQL.

نتیجه‌گیری

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

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

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

در عوض بانک‌های اطلاعاتی NoSQL انعطاف‌پذیری و مقیاس‌پذیری بسیار بیشتری را ارائه می‌دهند و این خود باعث توسعه سریع و مکرر آن می‌شود.

 امیدواریم این مطب راه تصمیم‌گیری را هنگام انتخاب دیتابیس و آپشن‌هایی که با آن‌ها رو به رو هستید، آسان‌تر کرده باشد.