دیتابیس، کش و سرچ انجین، هر چیزی جای خودش

توی دنیای برنامه نویسی بک اند(Backend) بعیده که کسی اسم این ابزار هارو نشنیده باشه. احتمالا میدونید که تمام این ابزار ها به نوعی محلی برای ذخیره داده ها هستند. توی این مطلب درباره این صحبت می کنیم که هر داده رو کجا ذخیره کنیم و کجا ذخیره نکنیم.

این مقاله جهت رسیدن به ویژگی های زیر در وب سرویس، نوشته شده:

• پاسخ دهی بسیار سریع API (کمتر از ۳۰ms)
• استفاده حداقلی از Ram, CPU و Disk
• کاهش بار و حجم دیتابیس

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

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

دیتابیس

دیتابیس برای نگهداری دائم یا طولانی مدت اطلاعات، تضمین ماندگاری و انجام سریع عملیات روی داده های عظیم و بازیابی این داده ها به کار میره. ( میتونیم به چشم یک انبار سازماندهی شده به دیتابیس نگاه کنیم )

کش

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

موتور جستجو

وظیفه اولیه Search engine اینه که بتونه داده های قابل جستجو در نگهداری کنه و مرتبط ترین نتایج رو برای جستجو های کاربران رو با سرعت خیلی بالا فراهم کنه. البته موتور های جستجو ظرفیت های خیلی بیشتری دارند، اما برای شروع همین کافیه. (گزینه پیشنهادی من برای شروع ElasticSearch هست)

با توجه به توضیحات بالا، با رعایت چند اصل زیر میتونیم به ارزش های ذکر شده در ابتدای متن نزدیک بشیم.

از ذخیره داده های که لزومی بر ذخیره در دیتابیس ندارند پرهیز کنیم

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

این کار تبعات مختفی داره، از جمله اینکه

• باعث حجیم شدم دیتابیس و سخت تر شدن پشتیبان گیری میشه.
• سرعت دیتابیس رو کاهش میده و منابع بیشتری میطلبه.
• Replicate کردن دیتابیس رو سخت تر میکنه.

از In-Memory-Storage ها به عنوان بافر(Buffer) برای دیتابیس بهره ببریم

از این طریق میتونیم وابستگی endpoint ها به دیسک رو کاهش بدیم. (یکی از بهترین  In-Memory-Storage ها Redis هست). 
این کار برای سرویس های RealTime کاملا ضروریه، وگرنه هزینه سخت افزار رو به شدت افزایش میده.

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

با کمک صف ها(Queue) پردازش های غیر فوری رو از روند اجرای EndPoint حذف کنیم

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

وظیفه جستجو رو به Search Engine ها محول کنیم

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

این مطلب رو میتونید با عنوان SearchEngine ،DataBase و Cache هر چیزی جای خودش در وبلاگ من(امین شجاعی) مطالعه کنید.