چرا وب‌سایت‌های بزرگ با جاوا تولید نمی‌شوند؟

در دنیای تولیدکننده نرم‌افزارهای کاربردی تحت وب با جاوا، همیشه سوال فوق به عنوان یک پارادوکس مطرح بوده‌ است.

در مجموعه مقالات نرم‌افزارهای کاربردی (Enterprise application) که در شماره‌های گذشته به آن پرداخته شده، تعریف جامعی از این گونه نرم‌افزارها و دلایل مناسب بودن مجموعه تکنولوژی‌های جاوا برای آن عنوان شده است.

در اینجا نگاهی خاص به وب‌سایت‌های بزرگ همچون Flicker، You Tube، Wikipedia و حتی گوگل خواهیم داشت. در مورد سایت‌های بزرگ وب، نکته‌ای که در نظر اول جلب توجه می‌کند، تعداد بالای کاربران آنها در سطح جهان و نیز میزان مراجعه بالای کاربران به قسمت‌های مختلف آن سایت‌ها می‌باشد.

شاید حجم بسیار بالای پهنای باند و ذخیره‌سازی اطلاعات، به خصوص در مواردی که نوع کار سایت مرتبط با داده‌های چند رسانه‌ای همانند ویدئو یا تصویر است مشخصه اصلی آنها باشد.

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

با کمی دقت مشاهده می‌شود که بیشتر وب‌سایت‌های بزرگ، حجم عملیات کنترل منطقی – مالی بسیار کوچک‌تری نسبت به نرم‌افزارهای کاربردی دارند، و در ازای آن کارائی (Performance) نقش موثرتری را در حیات آنها بازی می‌کند.

در توازن قوا بین کنترل منطقی – مالی و کارائی، نرم‌افزارهای کاربردی در قسمت اول و وب‌سایت‌های بزرگ در قسمت دوم تمرکز بالاتری دارند. نکته بسیار مهم دیگر، حجم نرم‌افزار و بحث تولیدپذیری(Productivity) آن است. در وب‌سایت‌های بزرگ بر حسب نوع کارشان، تعداد صفحات رابط کاربری بسیار محدود است و ممکن است در محدوده‌ای بین 10 تا 100 صفحه تعریف شوند و هدف اصلی افزایش کارایی تعدادی محدود از صفحات سایت است به طوری که بتوان از عملکرد آن در رویارویی با ترافیک بالا اطمینان حاصل نمود.

در صورتی که که در نرم‌افزارهای کاربردی تحت وب ممکن است تعداد صفحات یک برنامه مالی اداری جامع به هزاران صفحه با درجه بالایی از پیچیدگی برسد و جاوا به عنوان یک تکنولوژی منحصر به فرد در کارائی و تولیدپذیری بالا به عنوان تنها گزینه قابل انتخاب مطرح است.

در جدول زیر سیستم‌عامل، تکنولوژی وب، زبان، بانک اطلاعاتی و استفاده یا عدم استفاده از Memcached در مورد چند وب‌سایت بزرگ که در گزارش سایت Pingdom گردآوری شده، نمایش داده می‌شود:

با کمی بررسی به نظر می‌رسد که بیشتر وب‌سایت‌های بررسی شده در فوق، ترکیب LAMP (ترکیبی شامل از Linux/Apache/Mysql/PHP) را به عنوان تکنولوژی مرکزی زمان اجرای خود برگزیده‌اند.

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

به عنوان مثال گوگل فایل سیستم (Google File System)، تکنولوژی انحصاری گوگل برای خواندن و نوشتن فایل‌ها به گونه‌ای نیاز به استفاده از بانک‌های اطلاعاتی رابطه‌ای حجیم در موتور جست‌وجوی آن را منتفی کرده‌ است.

در این گونه موارد، نیازمندی‌های خاص صاحبان سایت را مجبور به تولید تکنولوژی‌ای منحصربفرد و دقیقاً مطابق با مصرف خود کرده که این امر معمولا‌ با هزینه‌های بالا نیز همراه است. تبادل داده در وب‌سایت‌های بزرگ با برنامه‌های مالی اداری که از جاوا در آنها استفاده می‌شود، تفاوت بسیاری دارد. در دنیای نرم‌افزاری‌های مالی اداری جاوا و تکنولوژی‌های مرتبط همانند J2EE در سطح بسیار وسیعی به کار برده‌شده‌اند.

در سال‌های اخیر رشد سریع در بازار سرمایه بکارگیری تکنولوژی‌های جدید میان‌افزارها را برای افزایش کارائی در منابع پردازشی و حافظه موجب شده‌است. نیازی واحد که راه‌حل‌های متفاوتی را در هر یک از دو دسته از نرم‌افزارهای فوق می‌طلبد. در نرم‌افزارهای کاربردی با گسترش تکنولوژی‌هایی همانند Compute Grid، Data Grid و Spring و در وب‌سایت‌های بزرگ با تغییر و تولید پیاده‌سازی‌های خاص خود از LAMP سعی در حل مشکل شده‌است.

در یک جمع‌بندی کلی شباهت‌هایی در راه‌حل‌های هر دو دسته دیده می‌شود. به عنوان مثال در قسمت دسترسی داده همانطور که در فوق ذکر شد استفاده از تکنولوژی‌های cache یا استفاده از Partitioning به جای بهره بردن از بانک اطلاعاتی مرکزی را می‌توان نام برد.

در قسمت عملیات منطقی/ مالی نیز اضافه نمودن تکنولوژی‌های موازی سازی پردازش همانند MapReduce (http://labs.google.com/papers/mapreduce.html)، استفاده از مدل‌های مقیاس‌پذیر در معماری برای افزودن قابلیت رشد خطی در نرم‌افزار یا بکارگیری تکنولوژی‌های جدید ارتباط با سرور همانند Ajax به‌ جای استفاده از مدل سنتی درخواست/پاسخ را نام برد.

در یک جمع‌بندی نهایی شاید موارد زیر پاسخی به پرسش مطرح شده در عنوان این نوشتار باشد:

- راه‌حل‌های مبتنی بر LAMP راه‌حل‌هایی کم هزینه و قابل سفارشی‌سازی هستند (به علت سورس آزاد بودن جمیع آنها)

- جاوا همچنان در خیلی از موارد استفاده می‌شود، اما در سایت‌های بزرگ به عنوان تکنولوژی حاشیه‌ای یا پشت صحنه در نظر گرفته شده‌است، همانند استفاده از سرویس‌های Servlet در Flicker.