چرا memcached هنوز از Redis بهتره
خلاصهٔ کاملتر
نویسنده تو این پست از تجربهش میگه که چطور تیمها معمولاً وقتی نیاز به کش دارن، مستقیم میرن سراغ Redis، چون بهش عادت دارن و امکانات زیادی داره. اما به گفتهٔ اون، مشکل از یه جای دیگه شروع میشه: چون استفاده از Redis با یه دستور ساده مثل cache.set("key", "value") خیلی راحتتر از نوشتن کوئری SQLـه، خیلی از توسعهدهندهها بدون اینکه بفهمن، شروع میکنن به رفتار کردن با Redis مثل یه دیتابیس واقعی و پایدار، نه یه کش موقت.
این سوءتفاهم معمولاً تا وقتی که بلایی سر Redis نیاد، معلوم نمیشه؛ مثلاً یه آپگرید، جابهجایی سرور، یا هر اتفاق دیگهای که باعث از دست رفتن دیتا بشه. نویسنده میگه مشکل از خود Redis نیست، بلکه از اینه که همه فرض میکنن چون Redis اسمش کشه، پس بقیه هم باهاش مثل یه چیز موقتی رفتار میکنن؛ در حالی که اینطور نیست و تا وقتی بفهمی، Redis اونقدر تو استک قاطی شده که دیگه نمیشه راحت جاش رو عوض کرد.
اینجاست که نویسنده memcached رو معرفی میکنه، یه سیستم کش متنباز و ساده که هدفش فقط کم کردن فشار روی دیتابیسه. با اینکه امکاناتش خیلی کمتر از Redisـه، نویسنده میگه این روزها همیشه اونو به Redis ترجیح میده.
اولین دلیل، رفتار memcached موقع قطعیـه: کتابخونههای کلاینتش معمولاً خطای اتصال رو نادیده میگیرن و فقط مقدار پیشفرض یا خالی برمیگردونن، به جای اینکه کل اپ رو بترکونن. دومین دلیل، کلاسترینگـه؛ memcached اصلاً کلاسترینگ داخلی نداره و همین باعث سادگیش میشه: کافیه چند آدرس سرور رو به کتابخونهٔ کلاینت بدی، و خودش بر اساس هش کردن کلید، درخواستها رو بین سرورها پخش میکنه. اگه یه نود از کار بیفته، کلاینت خودش تشخیص میده و بعد از یه مدت دوباره امتحانش میکنه.
دلیل سوم هم دقیقاً همون چیزیه که خیلیا فکر میکنن ایرادشه: memcached هیچوقت دیتا رو روی دیسک ذخیره نمیکنه. نویسنده این رو یه مزیت میدونه، چون یعنی میشه memcached رو مثل یه workload کاملاً stateless هر جا خواستی اجرا کنی، بدون نگرانی بابت پایداری دیتا.
نویسنده تأکید میکنه هیچکدوم از اینها کاری نیست که Redis نتونه انجام بده؛ فقط معماری memcached ذاتاً به این سمت متمایله و همین از نظر عملیاتی خیلی راحتترش میکنه. چون memcached برنامهٔ نسبتاً سادهایه و میشه دهها نمونه ازش رو با حدود ۶۴ مگابایت حافظه و سربار خیلی کم اجرا کرد، نویسنده میگه معمولاً اول سراغ همینو میره.
در آخر هم یه نکته میده که خیلی از مشکلات «دیتابیس کنده» اصلاً ربطی به نبود کش نداره، بلکه از کوئریهای کند یا نبود ایندکس میاد؛ پس بهتره اول همونها رو بهینه کرد.
نکات کلیدی:
- Redis اغلب اشتباهی مثل یه دیتابیس دائمی استفاده میشه، در حالی که فقط یه کشه
- memcached موقع قطعی رفتار امنتری داره چون کلاینتها خطای اتصال رو نادیده میگیرن
- کلاسترینگ memcached با هش کردن کلید در سمت کلاینت انجام میشه، بدون نیاز به تنظیمات پیچیده
- نبود persistence در memcached یه ویژگیه، نه یه نقص، و اجرای stateless رو ساده میکنه
- خیلی از مشکلات کندی دیتابیس اصلاً به کش ربطی نداره و از کوئری بهینهنشده میاد
