https://virgool.ir/backend-development/feedاینجا من سعی میکنم تجربیاتم در برنامه نویسی بک اند رو بنویسم.fa2026-11-11 04:34:37https://files.virgool.ir/upload/publication/jafx4njgvqol/esn6o2.pnghttps://virgool.ir/backend-developmenthttps://virgool.ir/backend-development/دیتابیس-کش-و-سرچ-انجین-هر-چیزی-جای-خودش-qxpudm9k4hujتوی دنیای برنامه نویسی بک اند(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 هر چیزی جای خودش در وبلاگ من(امین شجاعی) مطالعه کنید.توسعه بک اندامین شجاعیTue, 18 Feb 2020 17:50:21 +0330