SQL یا No-SQL مسئله اینست!

ابتدا بایدتوضیح بدم که ضمن نوشتن یک مقاله در مورد “بهینه سازی بانکهای اطلاعاتی SQL” که در آینده نزدیک منتشرخواهم کرد به این نتیجه رسیدم که این دو رو از هم جداکنم ،پس در ادامه به موارد استفاده از SQL و No-SQL میپردازیم.

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

موارد غیر مجاز استفاده از بانکهای اطلاعاتی رابطه‌ای:

  • صف:
    هرگونه ثبت داده برای ایجاد ترتیب پرادزش مثل ساختن یک جدول که داده ها پس از ثبت توسط یک یا چندین ورکر پردازش میشوند و بعد از انجام داده ها آپدیت میشوند مثل صف ارسال پیام ، SMS ، انجام کارهایی از این قبیل که بعد از انجام کار وضعیت انجام اونها ثبت میشود. زیرا پردازشهای موازی بهمراه خواندن و نوشتن همزمان باعث ازثبات خارج شدن/لگ شدن دیتابیس میشود و همچنین انباشت داده های قدیمیتری که پردازش شده اند کندی و افزایش سربار رو بهمراه خواهد داشت.
  • ذخیره‌ی داده‌های باینری حجیم:
    دیتابیسهای رابطه‌ای(Relational) برای ذخیره سازی داده های متنی/عددی مناسبتر میباشند و نقطه قوتشان در اصل رابطه ها و اتصالات سریع و منطقی بین مدلهای داده ای یا همان جداول است و از این رو برای نگهداری مستندات(Document) های حجیم (مثل تصاویر و ویدیوها و…) مناسب نیستند و برای این مدل از داده ها میبایست آنهارا در دیسک یا دیتابیس No-SQL ذخیره کرده و آدرس آنرا در بانک اطلاعاتی رابطه‌ای ذخیره نمایید.
  • ذخیره‌ی گراف:
    هر نوع شبکه‌ی پیچیده و اتصالات تو با خصیصه هایی که یال آن ارتباطات میباشند و انواع پیاده سازی تودر تو به صورت گراف بعلت انجام JOIN زیاد به شدت کل منابع سیستم رو قورت خواهد داد و کل دیسک را درگیر خواهدکرد (مثل دیتابیس یک شبکه اجتماعی/ارتباطی) که باید برای این نوع کاربرد از گراف دیتابیسها(Graph Databases) استفاده کنید مثل GraphQL , Neo4j…
  • الگوهای خواندن بیش از نوشتن:
    زمانیکه عملیات خواندن ردیفی یا همان واکشی داده ها کاربرد زیادی دارد و در کارکرد برنامه‌ی ما نوشتن بسیار ناچیزتر از خواندن است.
  • استفاده بعنوان key-value:
    هرگونه ذخیره سازی داده ها بدون نیاز به امکاناتSQL مانند ذخیره سازی داده های ساده شامل یک کلید و یک مقدار را روی SQL ذخیره نکنید(Redis چه بدی داشت که امتحان نکردی!)
  • ذخیره‌سازی انبوه (بالک):
    بالک ایمپورت (صرفاً خواندن و نوشتن) روی حجمهای چند ده میلیونی داده ها به شدت در بانکهای رابطه ای اختلال و لگ ایجاد خواهد کرد،و اگر نیازمند امکاناتSQLی و رابطه ای نیستیم مجاز به استفاده از بانکهای رابطه‌ای نیستیم ولی گاهی اوقات ممکن است که نیازمند این باشیم که یک بانک اطلاعاتی رابطه‌ای حجیم داشته باشیم که در آنصورت عملیات خلاصه سازی داده‌ها و پارتیشن بندی و… مطرح خواهد شد.


موارد مجاز استفاده از پایگاه‌های داده رابطه‌ای:

به طور خلاصه میتوان گفت:پایگاه‌های رابطه ای بعلت امکاناتی که در اختیار میگذارند گلوگاه‌های زیادی ایجاد میکنند و به نسبت No-SQLهای غیر رابطه ای کندتر عمل میکنند ویا همان مصرف منابع بیشتری دارند و هرگاه ما دلیل موجه و قدرتمندی برای استفاده از اونها نداریم نباید از اونها استفاده کنیم.

تراکنشها:

هر سیستمی که نیازمند تراکنشهای متعدد و انبوه میباشد. (تراکنش: به کوچکترین عملی که در سیستم انجام میشود و قابل تقسیم نمیباشد گویند مثل انتقال اعتبار از حساب یک مشتری به یک مشتری دیگر در بانک و…)

گزارشات پیشرفته داده ها برحسب کلیدهای خارجی:

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

*داده‌های غیر حجیم:

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

به طور کلی اگر اپلیکیشن شما نیاز به کوئریهای بسیار پیشرفته یا نسبتا پیشرفته دارد و نیاز به تجزیه و تحلیل روزمره دارد و تمرکز کلی سیستم شما روی اجرای صحیح و ۱۰۰% مطمئن تراکنشهاست. یعنی نیازمند ACID هستید (مجموعه ای از کارکردها/خواص که یکپارچگی و ثبات و صحت تراکنشهای شمارا تضمین کند) میبایست در انتخاب پایگاه رابطه‌ای تردید نداشته باشید.

به طور کلی اگر چیزی مزید بر این موارد بر خوردم که فراموش کرده بودم به این مقاله اضافه خواهم کرد و اگر نکته ویا ایرادی در این خردمقاله میبینید ممنون خواهم شد که تذکر بدهید.

نوشته SQL یا No-SQL مسئله اینست! اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *