چهار اصل مدیریت عملکرد پایگاه داده
خوانندگان معمولی می‌دانند که من به طور دوره‌ای در مورد مسائل مربوط به عملکرد پایگاه‌داده بحث می‌کنم و همیشه دوست دارم با تعریفی از عملکرد پایگاه داده شروع کنم، که در اینجا تکرار می‌کنم:
عملکرد پایگاه داده بهینه سازی استفاده از منابع برای افزایش توان عملیاتی و به حداقل رساندن اختلاف است که امکان پردازش بیشترین حجم کاری ممکن را فراهم می کند.
در این مقاله، می‌خواهم دیدگاهی در سطح بالاتری از مفاهیم عملکرد پایگاه داده داشته باشم و چند موضوع را معرفی کنم که احتمالاً شما را در طول کار شما در کار با سیستم‌ها و برنامه‌های پایگاه داده دنبال می‌کنند. این مضامین باید به عنوان اصول راهنما در نظر گرفته شوند که باید در هنگام مواجهه با مشکلات عملکرد پایگاه داده به خاطر داشته باشید.
یک: قانون پرتو:
اولین دستورالعمل اساسی درک قانون ۸۰/۲۰ است که به عنوان اصل پارتو نیز شناخته می شود. قانون ۲۰/۸۰ بیان می‌کند که ۸۰ درصد پیامدها ناشی از ۲۰ درصد از همه علل (یا ورودی‌ها) برای هر رویداد خاص است. این قانون به طور گسترده در بیشتر زمینه های کسب و کار، از جمله نرم افزار کامپیوتر و داده ها قابل اجرا است. در مورد عملکرد پایگاه داده، می توان آن را به چند روش مختلف بیان کرد. شاید رایج ترین آنها این باشد که ۸۰ درصد از نتایج تنظیم عملکرد شما از ۲۰ درصد تلاش شما حاصل می شود. یا به روش دیگری بیان کردید، ۲۰ درصد از برنامه های پایگاه داده شما باعث ۸۰ درصد مشکلات شما می شود. هنگام اعمال این قانون درگیر اجبار ۸۰% و ۲۰% دقیق نشوید. ایده کلی در اینجا جلوگیری از اتلاف وقت و تلاش است. با تمرکز تلاش‌های خود بر روی برنامه‌ها و فرآیندهایی که بیشترین بازده سرمایه‌گذاری را فراهم می‌کنند، از روح قانون ۸۰/۲۰ پیروی می‌کنید و همچنین از کار غیرمولد اجتناب می‌کنید.
دو: تنظیم فقط یک کار در یک زمان
دومین دستورالعمل اساسی رویکرد تنظیم به عنوان یک فرآیند تکراری است. به عبارت دیگر، به جای حمله به چندین موضوع در یک زمان، یک چیز را در یک زمان تنظیم کنید. و بعد از هر مرحله تنظیم موفقیت یا شکست تلاش را اندازه گیری کنید. اگر به تنظیم به این روش نزدیک نمی‌شوید، ممکن است تنظیمات و کدهای کمتر از حد بهینه را معرفی کنید زیرا نتوانستید هر تغییر را اندازه‌گیری کنید. در نظر بگیرید که اگر با یک پرس و جوی SQL با عملکرد کند مواجه شوید چه اتفاقی می افتد. در پاسخ، یک نمایه اضافه می‌کنید، آمار به‌روز شده جمع‌آوری می‌کنید، و برخی از تنظیمات بافرپول را تغییر می‌دهید، سپس پرس‌وجو را دوباره اجرا می‌کنید. اگر عملکرد بهتر است، کدام یک از آن تغییرات کمک کرد؟ فقط یکی از آنها بود یا ترکیبی؟ و اگر عملکرد اکنون بدتر باشد چه؟ کدام تغییر باعث آن شد؟ برای اینکه بتوانید به این سؤالات پاسخ دهید و به طور مؤثر تنظیم کنید، ضروری است که همیشه فقط یک چیز را در یک زمان تغییر دهید و قبل از انجام هر کار دیگری نتایج را بسنجید.
سه: اجتناب از همیشه و هرگز
ثالثاً، باید سعی کنید از استفاده از کلمات “همیشه” و “هرگز” خودداری کنید. به ندرت قوانینی وجود دارد که همیشه اعمال شوند. و به همین ترتیب، به ندرت مواردی وجود دارد که هرگز نباید انجام شوند. ذهن خود را باز نگه دارید و همه گزینه ها را در نظر بگیرید، حتی اگر آنها ممکن است گزینه هایی باشند که قبلاً هرگز امتحان نکرده اید (یا به شما گفته شده است که از آنها اجتناب کنید). همه چیز تغییر می کند و استانداردها و توصیه هایی که زمانی منطقی بودند ممکن است منسوخ شوند. بنابراین، یک DBA عاقل از گفتن «همیشه» و «هرگز» اجتناب می‌کند. نتیجه این قانون این است که به دلایل مشابه از گفتن “هیچ” و “همه” خودداری کنید.
چهار: طراحی عملکرد برنامه از ابتدا
در نهایت، بهتر است از همان ابتدا عملکرد را در برنامه‌ها و سیستم برنامه‌های کاربردی خود طراحی کنید، به‌جای اینکه سعی کنید تغییرات عملکرد را در زمان بعدی اصلاح کنید. هدف باید این باشد که توسعه دهندگان خود را برای نوشتن کدی آموزش دهید که نیازی به اصلاحات اصلاحی پس از واقعیت توسط تحلیلگران عملکرد نداشته باشد. اولین قدم برای تبدیل شدن به یک برنامه نویس موفق پایگاه داده که با در نظر گرفتن عملکرد کدنویسی می کند، ایجاد یک طرز فکر رابطه ای است. یک سیستم پایگاه داده رابطه ای با سایر انواع سنتی ذخیره سازی داده متفاوت است و برنامه نویسان برای نوشتن کد پایگاه داده کارآمد باید این را درک کنند. علاوه بر این، سیستم‌های رابطه‌ای برای تعیین بهترین راه برای دسترسی به داده‌ها بر فناوری بهینه‌سازی داخلی تکیه می‌کنند. برنامه نویسان باید از تلاش برای وادار کردن DBMS برای دسترسی به داده ها به روش های خاص اجتناب کنند و در عوض به بهینه ساز سیستم پایگاه داده تکیه کنند.
البته ملاحظات اضافی زیادی برای کدنویسی برنامه ها برای عملکرد از همان ابتدا وجود دارد. به عنوان مثال، دانش شاخص ها و خوشه بندی داده ها بسیار مهم است. دانستن و استفاده از توابع داخلی که در دسترس شما هستند نیز مهم است. و بیایید فراموش نکنیم که سعی کنیم تعداد دفعاتی که باید به داده های یکسان در یک برنامه دسترسی داشته باشیم را به حداقل برسانیم: هر چه دسترسی ها بیشتر باشد، کارایی برنامه کمتر است.
ملاحظات دیگر شامل کدنویسی برای همزمانی، آزمایش تغییرات متعدد SQL، اجتناب از تبدیل نوع داده و موارد دیگر است. DBA ها باید با توسعه دهندگان خود همکاری کنند تا به آنها کمک کنند تا این موارد را درک کنند، زیرا تلاش DBA مورد نیاز را در زمانی که برنامه عملیاتی می شود به حداقل می رساند.
نکته پایانی:
نکته اصلی این است که شما باید از همان ابتدا برای ایجاد عملکرد در برنامه های کاربردی خود تلاش کنید. هر چه بیشتر در فرآیند توسعه قرار بگیرید، ایجاد تغییرات دردناک تر می شود.
ترجمه: یاسینه پورابراهیم
توسط کریگ اس. مولینز