جنگولرن

⚠️خواهشا ردیس را به عنوان Primary Database استفاده نکنید!

از لینکدین Hasan Arab borzo
✔️کامنت هاشم بخونید. لینک این مطلب

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

🤔 هر کلید ما حاوی حدود ۱-۲ کیلوبایت JSON بود و مجبور بودیم که هر محصول را بدون TTL در Redis نگه داریم، زیرا Round Trip ما به Redis در لحظه به حدود ۳۰K می‌رسید و Redis ۴۰ گیگابایتی را مصرف می‌کرد. هیچ اپلیکیشنی نمی‌توانست این حجم Request را با منابع پایین و زمان پاسخ‌دهی ۱۰ میلی‌ثانیه انجام دهد!
در ادامه، وقتی وارد فضای حل مسئله شدم:

💡 پاک‌سازی داده‌های اضافی: اولین قدم ما حذف کلی داده‌های غیرضروری بود که هر کلید را به حدوداً ۵۰۰ بایت تبدیل کرد.

💡 استفاده از Protobuf: به این فکر کردم که چرا از JSON استفاده کنیم؟ با استفاده از deserializer و serializer قدرتمندی مثل Protobuf، می‌توانستیم حجم داده‌ها را به طور چشمگیری کاهش دهیم. با تبدیل داده‌ها به باینری و ذخیره آن، حجم هر کلید به حدود ۳۰۰ بایت کاهش یافت، که به معنای کاهش ۸۰ درصدی مصرف رم بود. با این حال، کیفیت و سرعت بالا در اکالا برای ما بسیار مهم بود.

💡 شکستن کلیدها: کلیدها را به دو بخش تقسیم کردم:
اطلاعات محصول (شامل نام، بارکد، آدرس عکس و...) در یک کلید با حجم تقریباً ۲۰۰ بایت.
موجودی هر محصول در فروشگاه‌ها در کلیدی دیگر با حجم حدود ۱۰۰ بایت.
در روش قبلی، اگر یک میلیون کالا داشتیم، مصرف حدود ۲۸۶ مگابایت بود. اما در روش جدید، فرض کنیم از یک میلیون تا 2000 محصول داریم و برای یک میلیون کالا موجودی در استور های مختلف، حدود ۹۵ مگابایت مصرف می‌شد!

💡 کش کردن محصولات: همچنین، کالاهای اضافه‌شده به سبد خرید مشتریان را به مدت ۴ روز کش کردم. به جای استفاده از Redis به عنوان Primary Database و بدون TTL، هرگاه داده‌ای نداشتیم، از منبع اصلی اطلاعات را می‌گرفتیم و دوباره به مدت ۴ روز کش می‌کردیم. اگر کاربری همان کالا را دوباره به سبد خرید اضافه می‌کرد، TTL آن به صورت Sliding افزایش می‌یافت.

در نهایت، با همین ۴۰۰ مگابایت، همه چیز به خوبی به هم رسید و ما توانستیم پرفورمنس و سرعت را بدون هیچ افت کیفیتی حفظ کنیم!

👍11❤6👏1

www.tgoop.com/djangolearn_ir/932

2.98K viewsNov 5, 2024 at 08:21

⚠️خواهشا ردیس را به عنوان Primary Database استفاده نکنید!

از لینکدین Hasan Arab borzo
✔️کامنت هاشم بخونید. لینک این مطلب

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

🤔 هر کلید ما حاوی حدود ۱-۲ کیلوبایت JSON بود و مجبور بودیم که هر محصول را بدون TTL در Redis نگه داریم، زیرا Round Trip ما به Redis در لحظه به حدود ۳۰K می‌رسید و Redis ۴۰ گیگابایتی را مصرف می‌کرد. هیچ اپلیکیشنی نمی‌توانست این حجم Request را با منابع پایین و زمان پاسخ‌دهی ۱۰ میلی‌ثانیه انجام دهد!
در ادامه، وقتی وارد فضای حل مسئله شدم:

💡 پاک‌سازی داده‌های اضافی: اولین قدم ما حذف کلی داده‌های غیرضروری بود که هر کلید را به حدوداً ۵۰۰ بایت تبدیل کرد.

💡 استفاده از Protobuf: به این فکر کردم که چرا از JSON استفاده کنیم؟ با استفاده از deserializer و serializer قدرتمندی مثل Protobuf، می‌توانستیم حجم داده‌ها را به طور چشمگیری کاهش دهیم. با تبدیل داده‌ها به باینری و ذخیره آن، حجم هر کلید به حدود ۳۰۰ بایت کاهش یافت، که به معنای کاهش ۸۰ درصدی مصرف رم بود. با این حال، کیفیت و سرعت بالا در اکالا برای ما بسیار مهم بود.

💡 شکستن کلیدها: کلیدها را به دو بخش تقسیم کردم:
اطلاعات محصول (شامل نام، بارکد، آدرس عکس و...) در یک کلید با حجم تقریباً ۲۰۰ بایت.
موجودی هر محصول در فروشگاه‌ها در کلیدی دیگر با حجم حدود ۱۰۰ بایت.
در روش قبلی، اگر یک میلیون کالا داشتیم، مصرف حدود ۲۸۶ مگابایت بود. اما در روش جدید، فرض کنیم از یک میلیون تا 2000 محصول داریم و برای یک میلیون کالا موجودی در استور های مختلف، حدود ۹۵ مگابایت مصرف می‌شد!

💡 کش کردن محصولات: همچنین، کالاهای اضافه‌شده به سبد خرید مشتریان را به مدت ۴ روز کش کردم. به جای استفاده از Redis به عنوان Primary Database و بدون TTL، هرگاه داده‌ای نداشتیم، از منبع اصلی اطلاعات را می‌گرفتیم و دوباره به مدت ۴ روز کش می‌کردیم. اگر کاربری همان کالا را دوباره به سبد خرید اضافه می‌کرد، TTL آن به صورت Sliding افزایش می‌یافت.

در نهایت، با همین ۴۰۰ مگابایت، همه چیز به خوبی به هم رسید و ما توانستیم پرفورمنس و سرعت را بدون هیچ افت کیفیتی حفظ کنیم!

BY جنگولرن