نکات کلیدی ZDNET
تقریباً همه هنوز از برنامه‌های پایگاه داده منسوخ استفاده می‌کنند.
هزینه، دلیل اصلی عدم ارتقاء شرکت‌ها است.
نرم‌افزارهای بدون پشتیبانی، مشکلات امنیتی زیادی به همراه دارند.
همه ما از نرم‌افزارهای قدیمی استفاده می‌کنیم. گاهی اوقات از روی تنبلی، گاهی به دلیل هزینه بالای ارتقاء و گاهی هم چون کار می‌کند و نمی‌خواهیم آن را جایگزین کنیم.
با این حال، زمانی که پرکونا، شرکت پشتیبانی سیستم‌های مدیریت پایگاه داده (DBMS) متن‌باز، در گزارش «وضعیت مدیریت پایگاه داده متن‌باز ۲۰۲۶» خود فاش کرد که ۹۷ درصد از مدیران پایگاه داده (DBA) مستقر در ایالات متحده هنوز از برنامه‌های DBMS منسوخ استفاده می‌کنند، بسیار متعجب شدم. واقعاً؟! این رقم بسیار بالایی است و DBMSها برای همه شرکت‌ها حیاتی هستند.
چرا همچنان از DBMSهای قدیمی استفاده می‌کنیم؟
به گفته پرکونا، شرکت‌ها به استفاده از DBMSها فراتر از پایان عمر رسمی آن‌ها ادامه می‌دهند، عمدتاً به این دلیل که ارتقاء یک پروژه مهاجرت پرخطر و چندلایه است، نه یک به‌روزرسانی ساده نرم‌افزاری. وابستگی‌های برنامه‌های قدیمی، ویژگی‌های منسوخ شده، سازگاری با کلاینت‌ها، تغییر پیش‌فرض‌ها، نیاز به آزمایش و لزوم جلوگیری از اختلال در تولید، همگی می‌توانند به تعویق انداختن ارتقاء را در کوتاه‌مدت ایمن‌تر یا ارزان‌تر جلوه دهند. به عبارت دیگر، آن‌ها ترجیح می‌دهند محتاط باشند تا پشیمان.
البته، این فرض بر این است که آن‌ها می‌توانند از نقض‌های امنیتی ناشی از ادامه استفاده از نرم‌افزارهای پایان عمر جلوگیری کنند. در این روزها که هوش مصنوعی می‌تواند حفره‌های امنیتی را سریع‌تر از ما پیدا کند، این شرط‌بندی خوبی نیست.
دلایل دیگر، به گفته پرکونا، شامل این است که ارتقاء پایگاه داده به ندرت صرفاً تغییر نسخه است، زیرا می‌تواند وابستگی‌ها را در سراسر پشته برنامه آشکار کند. برنامه‌های قدیمی ممکن است به ویژگی‌های منسوخ یا حذف شده پایگاه داده متکی باشند، که نیاز به شناسایی این وابستگی‌ها و بازبینی کدهای مربوطه توسط تیم‌ها دارد. به عنوان مثال، روش احراز هویت پیش‌فرض caching_sha2_password در MySQL 8.0 می‌تواند برای کلاینت‌های قدیمی مشکل‌ساز باشد و ممکن است نیاز به تغییرات پیکربندی داشته باشد.
تغییرات دیگر نیاز به بررسی دقیق در سطح برنامه دارند. به عنوان مثال، تغییر در مجموعه‌های کاراکتر پیش‌فرض – از latin1 به utf8mb4 – نمی‌تواند به طور ایمن برای برنامه‌های موجود یا روال‌های مدیریت داده شفاف فرض شود. پرکونا همچنین به سازمان‌ها توصیه می‌کند که کل محیط، از جمله برنامه‌ها، سیستم‌عامل‌ها، کتابخانه‌ها و فایل‌های پیکربندی را ارزیابی کنند، زیرا مهاجرت پایگاه اس ام اس داده اغلب بر چیزی فراتر از خود سرور پایگاه داده تأثیر می‌گذارد.
این پیچیدگی، هزینه و خطر انتقال به یک نسخه پشتیبانی شده را افزایش می‌دهد. تیم‌ها باید بررسی‌های پیش از ارتقاء را انجام دهند، مهاجرت را در محیط تست اعتبارسنجی کنند و کار تولید را با دقت برنامه‌ریزی کنند تا اختلال را محدود کنند – وظایفی که نیاز به تخصص متخصص، زمان مهندسی و پنجره‌های نگهداری دارند.
انتقال نسخه‌های اصلی می‌تواند دشواری بیشتری ایجاد کند. پرکونا ارتقاء از MySQL 5.7 به 8.0 را مثال می‌زند که شامل بازطراحی قابل توجه دیکشنری داده و حذف کش کوئری بود، به عنوان نمونه‌ای از اینکه چرا «فقط ارتقاء» به ندرت یک برنامه کافی است.
در پس‌زمینه گسترده‌تر، پرکونا دریافت که تیم‌های پایگاه داده با افزایش هزینه‌های ابری، مشکلات عملکرد، اتلاف زمان مهندسی، نگرانی‌های مربوط به خرابی، پیچیدگی مقیاس‌پذیری، سیاست‌های پراکنده و کمبود مهارت‌ها محدود شده‌اند. این فشارها ظرفیت سازمانی موجود برای کارهای چرخه عمر مانند ارتقاء پایگاه داده را کاهش می‌دهد.
پول، پول، پول
فشارهای هزینه، بیشترین مانع ذکر شده در نظرسنجی برای کاهش کل هزینه مالکیت و ارتقاء پایگاه داده بود.
یافته‌ها، هزینه‌های مصرف ابری (۳۱%) را جلوتر از مجوزها (۲۳%) به عنوان مانع اصلی گزارش شده قرار دادند. این مهم است زیرا انتقال به پلتفرم‌های پایگاه داده مدیریت شده می‌تواند برخی از کارهای عملیاتی را حذف کند، در حالی که صورت‌حساب‌های کمتر قابل پیش‌بینی را نیز ایجاد می‌کند، زیرا نیازهای ذخیره‌سازی، محاسبات، ترافیک شبکه، دسترسی بالا و انتقال داده افزایش می‌یابد.
پیتر فارکاس، مدیرعامل پرکونا، در اطلاعیه شرکت گفت: «اقتصاد ابری در حال تغییر است، هوش مصنوعی الگوهای کاری جدیدی را معرفی می‌کند، مقررات پیچیده‌تر می‌شوند و سازمان‌ها به طور فزاینده‌ای از اینکه داده‌ها و فناوری آن‌ها کجا کنترل می‌شود، آگاه هستند. سازمان‌هایی که بهترین آمادگی را خواهند داشت، لزوماً آن‌هایی نیستند که می‌توانند پیش‌بینی کنند چه اتفاقی خواهد افتاد. آن‌ها کسانی هستند که آزادی سازگاری را هنگام وقوع آن حفظ می‌کنند.»
شکاف‌های عملکرد و سیاست
این گزارش همچنین عملیات پایگاه داده را به عنوان یک مشکل کارایی مهندسی و تاب‌آوری، نه صرفاً یک مسئله تأخیر کوئری، به تصویر می‌کشد:
- ۴۲% ناکارآمدی یا توان عملیاتی پایین را به عنوان یک چالش عملکردی ذکر کردند.
- ۴۱% اتلاف زمان مهندسی را ذکر کردند.
- ۴۰% خرابی را ذکر کردند.
- ۳۷% دشواری در مقیاس‌پذیری را ذکر کردند.
در مورد حاکمیت، ۵۴% گفتند که قفل شدن در فروشنده، سازگاری با الزامات نظارتی در حال تغییر را دشوارتر می‌کند. بیش از نیمی از آن‌ها ابزارها یا سیاست‌های پراکنده را گزارش کردند، در حالی که ۴۶% هم قابلیت ردیابی زنجیره تأمین نرم‌افزار و هم وضعیت امنیتی واکنشی را به عنوان نگرانی شناسایی کردند.
این نتایج، مسئله نسخه قدیمی را به چالش‌های مدیریتی گسترده‌تر مرتبط می‌کند. نرم‌افزارهای بدون پشتیبانی می‌توانند مدیریت آسیب‌پذیری و الزامات ممیزی را پیچیده کنند، در حالی که کنترل‌های پراکنده و گسترش پایگاه داده، برنامه‌ریزی ارتقاء و مهاجرت را دشوارتر می‌کنند.
هوش مصنوعی عمدتاً یک شکاف ویژگی نیست
برای آمادگی در برابر هوش مصنوعی، پاسخ‌دهندگان بیشتر موانع سازمانی اساسی را شناسایی کردند تا کمبود ویژگی‌های پایگاه داده. معماری داده پراکنده و کمبود مهارت‌ها به ترتیب با ۲۳% به عنوان موانع اصلی شناخته شدند.
این نتیجه یک اصلاح مفید برای عجله فعلی برای افزودن جستجوی وکتور، ذخیره‌سازی جاسازی و قابلیت‌های عامل‌محور به پیشنهادات پایگاه داده است. این قابلیت‌ها ممکن است مفید باشند، اما پاسخ‌دهندگان پرکونا نشان می‌دهند که داده‌های جدا از هم و عدم تخصص لازم کارکنان، موانع فوری‌تری هستند.
فارکاس گفت: «رهبران پایگاه داده باید برای تغییر برنامه‌ریزی کنند، نه برای یک نسخه واحد از آینده. کنترل و انعطاف‌پذیری باید الزامات باشند، نه ملاحظات بعدی.» هیچ‌کس نمی‌داند انقلاب هوش مصنوعی ما را به کجا خواهد برد. به همین دلیل، به لطف انعطاف‌پذیری متن‌باز، شرکت‌های هوشمند هنوز منابع DBMS خود را در DBMSهای متن‌باز سرمایه‌گذاری می‌کنند.