انتخاب محل ذخیره سازی تصاویر: فایل سیستم یا پایگاه داده؟

تصمیم گیری در مورد بهترین راه برای ذخیره سازی تصاویر بین Blob (Binary Large Object)در پایگاه داده و فایل سیستم (مانند S3) همیشه بحث برانگیز بوده.

پایگاه داده یا فایل سیستم؟ کدوم بهتره؟

اول از همه، بریم سراغ مزایای هر کدوم:

پایگاه داده:

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

فایل سیستم (مانند S3):

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

پس کدوم رو انتخاب کنیم؟

خب، بستگی به نیاز شما داره!

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

در نهایت...

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

#Database #General
@Code_Crafters

رویه ذخیره شده Stored Procedure ناجی برنامه های تحت فشار:
در دنیای برنامه‌نویسی(منظور ما سمت Back-End است Front-End 🥸)، بهینه‌سازی و عملکرد روان برنامه‌ها از اهمیت بالایی برخوردار است. در این میان، پایگاه‌های داده نقش حیاتی در ذخیره‌سازی و بازیابی اطلاعات ایفا می‌کنند.

رویه ذخیره‌شده یا Stored Procedure چیست ؟
به صورت خلاصه Stored Procedure یک مجموعه از دستورات SQL است که کار خاصی را انجام میدهد و ما برای آن یک نام مرتبط میگذاریم و در هر جایی که نیاز داشته باشیم آن را فراخوانی میکنیم (اگر پارامتر خاصی نیاز داشته باشد هم میتوانیم به آن پاس بدهیم )

به صورت معمول برنامه نویس ها از ORM هایی مخصوص زبان برنامه نویسی که با آن کار میکنند برای ایجاد کوئری بر روی دیتابیس استفاده میکنند ولی ORM (منظورم هر ORM است حتی اگر معجزه برنامه نویسی قرن باشد!!!) چندین ایراد مهم و اساسی دارند که در ادامه به آن ها اشاره میشود:

۱. شما باید هزینه تبدیل کد هایتان را به SQL پرداخت کنید(با کاهش قدرت برنامه) در نهایت پایگاه داده شما با SQL کار میکند نه زبان برنامه نویسی شما !!!

۲.وقتی از ORM ها استفاده میکنید اگر نیاز به کوئری پیچیده و یا خیلی خاصی داشته باشید قدرت زیادی برای مدیریت این چالش با استفاده از ORM نخواهید داشت.

۳. معمولا برای فراخوانی یک مقدار از پایگاه داده به چندین روش مختلف میتوان این کار را انجام داد که یه سری از این روش ها دارای پرفومنس خوب و بعضی از روش ها دارای پرفومنس وحشتناک هستند (این مورد مربوط به افزایش پرفومنس در SQL است که توضیح طولانی دارد که در اینجا جای نمیگیرد ولی برای آشنایی بیشتر ساده ترین مورد را اشاره میکنم :
تصور کنید جدولی به نام کارکنان و با ۱۵ ردیف داریم و میخواهید مقدار نام از جدول کارکنان خود را بخوانید با استفاده از ORM خود در نهایت به این کوئری خواهید رسید :

select * from employee;

در حالی که شما فقط به نام کارکنان در این جدول نیاز دارید و این جدول دارای ۱۵ ردیف است که فراخوانی ۱۴ ردیف دیگر بیهوده و هزینه برخواهد بود
و این کوئری نیاز شما را برطرف میکرد :

select name from employee;

که دارای پرفومنس بهتری خواهد بود
{شاید بتوانید جلوی استفاده از * بگیرید و ORM را مجبور به فرخوانی تنها name کنید ولی در موارد دیگر همچنین ساده هم نخواهد بود }

) وقتی از ORM خود استفاده میکنید شما کنترل زیادی برای اینکه از چه روشی استفاده کند نخواهید داشت و صرفا کد های ORM خود را خواهید دید

۴. گاها پیش میآید که شما برای فراخوانی مقدار در پایگاه داده با استفاده از ORM کوئری میسازید ولی ORM کوئری عجیبی تولید میکند که فشار فوق العاده ای بر روی برنامه شما وارد میکند.(برای جلوگیری این مورد اگر اصرار به استفاده از ORM دارید باید به موارد پیشرفته ORM خود مراجعه کنید که نیاز به تمرین و زمان است)

از معایب استفاده از Stored Procedure میتوان به این موارد اشاره کرد:

۱. نیاز به دانش خوبی از SQL دارد

۲. در صورت تغییر پایگاه داده نیاز به بازنویسی خواهند داشت

۳.نوشتن برنامه با سرعت خیلی پایین تری پیش خواهد رفت.

مقایسه Stored Procedure با ORM:

در واقع ORMها (Object-Relational Mapping) ابزاری برای نگاشت اشیاء برنامه به ساختارهای پایگاه داده هستند. ORMها به طور خودکار وظایف مربوط به ترجمه کوئری‌ها از زبان برنامه‌نویسی به زبان SQL را انجام می‌دهند.

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

در نتیجه :اگر برنامه شما دارای فشار زیادی بر روی پایگاه داده است و همین طور برنامه شما دارای بار زیادی است میتوانید برای مدیریت آن از Stored Procedure ها در پایگاه داده تان استفاده کنید
یا اینکه میتوانید استفاده نکنید و به زیبایی کد های خود با استفاده از ORM به خود افتخار کنید و بگذارید پایگاه داده تحت فشار کد های SQL عجیب شما تبدیل به نفت شود
این مورد کاملا بستگی به برنامه و نیاز شما بستگی دارد.

#Database #General
@Code_Crafters