content top
האם יועצי הביצועים יהפכו למיותרים?

האם יועצי הביצועים יהפכו למיותרים?

 

פעמים רבות חשבתי לפתוח בלוג משל עצמי, אך חששתי שלא אעמוד בהתחייבות שאקח על עצמי לכתוב לעיתים מזומנות. עד שעלה על דעתי הרעיון כיצד אפשר ליהנות משני העולמות: אפשר להתארח בבלוג אחר, אורח ולא שותף, האחריות על עדכונים לא תחול עלי, ומצד שני אוכל לכתוב רעיונות שעולים במוחי (הקודח).

מאז שהייתי ילד קטן אהבתי לפרק דברים על מנת לתקנם, אולי לכן אחד הנושאים אותם אהבתי היה תיקון ופתרון בעיות ביצועים, מה שמוכר בשם performance and tuning . בעיות ביצועים במערכת עלולות להשפיע על תפעול המערכת כולה, להשפיע על אופן העבודה של משתמשי המערכת ועל שביעות רצונם מן המערכת ובשורה התחתונה לעלות לארגון במשאבים רבים.

לכשעצמי פיתחתי מתודולוגיה שלמה של גישה לבחינת ביצועים, מתודולוגיה שהתבססה על ניסיון שנרכש בהרבה מערכות ואנסה לתמצת את עיקרה:

השלב הראשון – קבל בהבנה את כל מה שאומר הלקוח אך אל תאמין מבלי לבדוק את מסקנותיו.

השלב השני – נסה להבין מה עושה המערכת שלו ומה הם הדרישות מהמערכת ובדוק האם דרישות אלו מציאותיות?

שלב שלישי – החל לבדוק את כל סביבת העבודה, החומרה והתוכנה.

שלב רביעי – חפש בעיות הנובעות מתכנון לקוי של אינדקסים או כתיבה לא נכונה של קוד SQL.

החלק האחרון הוא החלק הדורש את מירב המאמצים, לנתח את רישומי ה profiler, לעקוב אחרי ביצועים, לזהות מרכיבים בעיתיים וכן הלאה. הכלים הנפוצים בשוק אומנם עוזרים בכך שהם מצביעים על אותן שאילתות הצורכות משאבים יקרים, אך הם חסרי המלצות כיצד ניתן לתקן את אותן שאילתות. הכלים המנתחים אינדקסים לא מודעים לכתיבה לא נכונה של קוד השאילתא.

ומעבר לכך ישנו גם השלב הבעייתי: כאשר אני כיועץ מחליט לבצע תיקון כל שהוא, כיצד אני אוסף את המידע איזה שאילתות עלי לבחון לאחר השינוי? וזאת על מנת לוודא שבאמת השינוי לא פגע, או כמו שאני נוהג לומר "יועץ טוב צריך לדעת להסביר פעמיים, בפעם הראשונה הוא מסביר מה היא הבעיה וכיצד ניתן לפותרה, ובפעם השניה הוא מסביר מדוע הפתרון עליו המליץ לא הצליח".

מדוע בכלל יש שאילתות שאינן כתובות כהלכה? נקודת המוצא שלי אומרת ש[כמעט] כולנו כותבים קוד מושלם, אך במחזור חיים של מערכת יתכנו שינויים: יתכן והמערכת יצאה לדרכה כשהיא במיטבה אך במהלך חייה השתנה היחס הכמותי שבין הטבלאות או שנוספו למערכת רכיבים נוספים הגורמים לתלות בין משאבים או לחיסרון באינדקסים.

דברים אלו קשים לבדיקה שכן מי שבא לבדוק את המערכת כשהיא כבר פעילה לא תמיד יצליח להבין מה היו שיקולי המתכנן בקביעת האינדקסים ולכן יחשוש לשנותם (בבחינת אם זה עובד – אל תיגע! אף על פי שבפועל זה לא בדיוק עובד כנדרש).

בעיה מסוג אחר יכולה להיות בארגונים בהם נקבעה מדיניות כתיבת קוד: זה יכול להיות מוצלח מאוד או מסוכן מאוד, תלוי כמה השקיעו בכך. לדוגמה, שימוש ב user define data type יכול לעזור בהתאמת טיפוסי משתנים, אך חוסר תשומת לב יגרום לכך שטיפוסים אלו לא יהיו קיימים במסדי נתונים (DB) שכנים. במקרה כזה אנו עלולים להגיע לשאילתות בהם מושווים טיפוסי נתונים שונים ולפגיעה בביצועים.

דוגמה אחרת שפגשתי היא יצירת תבנית מסודרת לכתיבת stored proc. בעבר פגשתי מערכת שבגלל העתקת התבנית הקבועה, בכל ה- SP היה הציווי SET FORCEPLAN ON, מה שגרם לתוצאות מאוד מעניינות.
שפת SQL היא שפה מאוד גמישה. את אותה שאילתא ניתן לנסח במספר צורות אשר יגרמו לאופטימייזר לבצעה בדרך שונה. דוגמה פשוטה לכך היא חיפוש ערך בין שני גבולות BETWEEN היכול גם להיכתב גם כך " <= and >= ". דוגמה יותר מסובכת היא חיתוך בין טבלאות – JOIN, יכול להיכתב גם כ nested query. התשובות לשאילתות אלו בדרכים השונות תהינה זהות, אך הביצועים יכולים להיות שונים לגמרי, האם כותבי הקוד תמיד מודעים לכללי הכתיבה היעילה?

מכאן אני מגיע לנושא עליו רציתי לספר, מזה כשנתיים אני שומע מידידי עמי לוין על נפלאות מערכת Qure שהם בנו בחברת DBSophic (http://www.dbsophic.com/ ). עד שלאחרונה, בגלל שזמני התפנה, קמתי ועליתי לעיר הקודש ירושלים, על מנת לבדוק האם יש אמת בדבר.

ובכן, "באתי, ראיתי והתפעלתי". הרצתי את המערכת על בסיסי נתונים אמיתיים ובעזרת קבצי profiler שנאספו בזמן עבודת אמת, רציתי לבחון האם המערכת תצליח לבצע עבודה יותר טובה ממני?

מערכת Qure היא סוג חדש של מערכת לנושא P&T העובדת בשונה מכלי ה P&T הקיימים בשוק, ובעצם מדמה את דרך החשיבה של יועץ אך במבט הרבה יותר רחב. היא לא מתעסקת רק בשאילתא הבודדת שצרכה את מירב המשאבים, היא בוחן תהליכי עבודה במערכת על פני מגוון שלם של שאילתות ופניות לשרת. זה לא רק שהמערכת יודעת לבדוק בעיות פשוטות של התאמת טיפוסי משתנים או החלפת תחביר (Syntax) לתחביר יעיל יותר. המערכת יודעת גם לבחון את ההשלכות על כל הפעילות, היא תיתן המלצות גם על מצב האינדקסים (Defrag) ועל שינויים נדרשים באינדקסים, ובנוסף לכך מערכת הקשרים הסמנטית אותה בונה Qure בין האובייקטים השונים במערכת מאפשר לראות מיד כל המלצה והמלצה על איזה אובייקטים היא תשפיע. הפעלת המערכת בסביבת בדיקות סטרילית בה ניתן למערכת לבצע שינויים ולמדוד את השפעתם, מאפשרת לתת הערכה טובה של אחוזי השיפורים כתוצאה מכל שינוי ושינוי.

אני לא רוצה להפוך את הבלוג הזה לפרסומת ל Qure. אבל אני חייב לומר שמזמן לא התלהבתי כל כך ממוצר שנראה שיודע מה הוא צריך לספק ואף מספק את הסחורה. ככה זה כשעמי, האדריכל של המערכת, הוא גם אחד היועצים הטובים בנושא שיפור ביצועים. אם הייתי צריך להעריך את החיסכון בשעות עבודה של מערכת כזו מול עבודה אנושית הייתי אומר ששעת Qure שקולה לפחות ליום עבודה של יועץ P&T בכיר.

כאן מיד מתעוררת השאלה האם היועץ הפך למיותר? לא, עדין נשאר לו תפקיד חשוב מישהו עדיין צריך לעבור על ההמלצות ולבחון האם לקבלן, מישהו עדיין צריך לקבל החלטה האם שינוי העוזר במקום מסוים ופוגע במקום אחר הוא שינוי שכדאי לבצעו, ומישהו עדיין צריך לתת תשומת לב לשלבים הראשונים של מתודולוגית בדיקת הביצועים. האם הדרישות אפשריות? האם החומרה מתאימה? האם הסימפטומים עליהם מצביעים המשתמשים אכן קיימים? כלומר נשארת מספיק עבודה ליועצים. אני חושב שעם כלי שכזה ניתן להגיע להרבה יותר מערכות ולהציע תהליך של בחינת ביצועים מהיר וזול יותר.

האם DBSophic ישכילו לתת לנו כיועצים מודל תמחיר שיאפשר לגשת לארגונים קטנים שאינם משופעים בתקציבים ולתת להם הצעה לבחינת ושיפור ביצועי המערכות שלהם?

לצערי יש מערכות שגם כלי כזה לא יעזור להם: למשל מערכת שאני מכיר בה כל הלוגיקה נמצאת בתוך triggers – הרי זו שגיאה תכנונית, ההשלכות על נושאי הנעילות הן הרסניות. באותה מערכת איש אינו מעז לתקן, ובכלל בדרך כלל ליועץ אין מנדט לביצוע שינויים גדולים בארכיטקטורה או בסכמה של מסד הנתונים. אך כיום עדיין אין כלי שיכול להחליף ראיה ארכיטקטונית של יועץ.

באחד הפוסטים בעתיד אסביר מה נדרש מיועץ על מנת להפוך לארכיטקט, ומהי בעצם ראית המערכת הארכיטקטונית שאין לכל אחד.

שלכם, דובי
(Dubi or Not To Be)

Dubi.lebel@gmail.com


3 תגובות על “האם יועצי הביצועים יהפכו למיותרים?”

  1. מאת גרי רשף:

    תודה דובי,
    בהצלחה עם הטור,
    וגם בדרך החדשה מחוץ למיקרוסופט..

  2. מאת שחר בר:

    היי דובי,
    אני חושב שרבים מאיתנו לוקים כבר בשלב הראשון – מקבלים את דברי הלקוח כנכונים ומובנים מעליהם ומורידים מאיתנו את חובת הבדיקה…
    הדבר הראשון שאני עושה זה – רוצה לראות את הבעייה במו עיני (אם זה ניתן, כמובן….)
    אני גם לא בטוח לגבי סדר השלבים השלישי והרביעי שהעלת באופן פתרונות בעיות ביצועים.
    בוא נסכים שעושים אותם במקביל….

    חוץ מזה רציתי לציין שאנחנו ב-valinor משווקים את המוצר של DBSophic, ואכן, גם אנחנו רואים בו מוצר חדשני שיתרום תרומה גדולה ללקוחותינו.

    אנחנו מיישמים אותו כבר אצל כמה מהם.

    שבת שלום,
    שחר

  3. מאת יניב אתרוגי:

    דובי,
    אני שותף להתלהבות.

    מקורח תפקידי כאחראי על סביבות Production גיליתי עניין והחלטתי לבדוק את המוצר.

    עבדתי עם המוצר על 20 בסיסי נתונים שונים והתוצאות היו מעל הציפיות שלי כ DBA שמכיר את התוכנות הקיימות בשוק והנושא של שיפור ביצועים קרוב לליבי.

    הזמן ש Qure חסך לא ניתן למדידה וזאת דעתי מאחר ואני לא מכיר שום DBA שהייה מסוגל לשבת ימים שלמים ולהריץ סטים שלמים של בדיקות ברצף, לעבד לנתח את התוצאות. זאת תכולת עבודה שאם לא מתבצעת באופן אוטומטי ושיטתי על ידי תוכנה – לעולם לא תבוצע על ידי בן אנוש.

    יניב

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים

14 − eleven =