Archive

Archive for מאי, 2010

מה צריך לשאול לפני תהליך מייגע של tuning ל-DB ולמשפטי SQL?

יש בעיות ביצועים עם database. מה עושים?

אם היה לי שקל על כל פעם ששמעתי את השאלה הזאת – הייתי יכול לקנות ג'יפ מרצדס. סתאאאם. מקסימום קורקינט חשמלי.

ובכל זאת – לפני שמתחילים לעשות Tuning או (כיוונון בעברית) למערכת צריך לשאול את השאלות הבאות:

  1. האם יש עוד אפליקציה שרצה על שרת ה-DB וזוללת משאבים?
  2. האם החומרה בכלל חזקה מספיק בשביל לסחוב מערכת עם X משתמשים שעושים Y טרנזקציות בדקה בזמן שיא ו-Z שאילתות קטלניות?
  3. האם נבדקה מהירות התקשורת בין שרת ה-DB ושרת האפליקציה או ה-clients?
  4. האם מישהו מקצועי קינפג את הפרמטרים והאופציות של ה-DB? מישהו בכלל עבר על ההגדרות ובדק את התאמתן?
  5. האם ה-DB מתוכנן נכון ליעוד שלו: OLTP או DWH?
  6. האם ישנם תהליכים מסויימים שכשהם רצים מורגשת בעיית הביצועים?
  7. האם מתכנני האפליקציה ומפתחיה לקחו בחשבון שאנשים רבים עובדים במקביל על המערכת (מה שנקרא concurrency) ועשויים לנעול איש את רעהו?

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

לא לשכוח להתקין TELNET על Windows

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

הדרך הקלה ביותר לבדוק את זה הוא באמצעות תוכנית השירות TELNET המגיעה בכל מערכת UNIX אבל משום מה היא אופציונלית על Windows. למרבה הצער – יש נטיה לשכוח להוסיף את TELNET להתקנה למרות שמישקלו הוא כמשקל אמבה תת ימית.

נו טוב… נצטרך עכשיו להתחיל לפשפש ב-ACL של ה-Firewall.

Firewall הוא כמו אישה – אי אפשר איתו ואי אפשר בלעדיו….

איך לבנות Data Access Layer כמו שצריך

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

בחברה אחת שכזו נעשית חשיבה כיצד נכון בשבילם לכתוב את ה-DAL.

האפשרויות הן:

  1. כתיבת משפטי SQL בתוך הקוד. לרוב נבנה הטקסט של המשפט והוא נשלח לביצוע ל-DB.
  2. קריאה ל- Stored Procedures מתוך הקוד והעברת פרמטרים אליהם ומהם.
  3. שימוש ב-ORM או Object Relational Mapping כמו Hibernate או Entity Framework.

אופציה מספר 1 (SQL בתוך הקוד) היא הגרועה שבהם וזאת מכמה סיבות ואלו העיקריות שבהן:

  1. משפטי ה-SQL שבקוד אינם נבדקים בזמן קומפילציה ועלולים "להתעופף" בזמן ריצה אם התחביר שגוי.
  2. שינויים בסכימה (הוספת/ביטול עמודות, שינוי טיפוס נתונים, שינוי בשמות טבלאות וכו') גוררים שינויים בקוד. קשה למצוא את כל המקומות שיש לשנותם. ה-deploy בסביבת היצור חייב יהיה לשנות את הקוד שמעל ה-DB.
  3. השאילתות שנוצרות בקוד הן לרוב – שאילתות דינאמיות עם כל המשמעויות המתבקשות של בעיות ביצועים.

לאופציה מספר 2 (Stored procedures)  יש גם כן מגרעות (אבל פחות מאשר לאופציה מס' 1):

  1. קריאה לפרוצדורות היא סוג של יציאה מעולם האובייקטים לעולם רלציוני – מה ששובר את עקרונות עיצוב מונחה עצמים.
  2. במערכת בינונית ומעלה אפשר למצוא מאות ואפילו אלפי פרוצדורות. אי אפשר למצוא את הידיים ואת הרגליים בהם והרבה פעמים קורה שמפתח כתב stored procedure ולא ידע שמישהו אחר כתב את אותה פרוצדורה לפניו – רק עם שם אחר.
  3. הרבה פעמים הלוגיקה העסקית "מתפזרת" לתוך פרוצדורה ואז היא מצוייה גם בשכבת BLL וגם בשכבת ה-DAL.
  4. לא כל כך נוח לתכנת כל פעולת SQL בשני שלבים – פיתוח קריאה לפרוצדורה בשפה עילית ופיתוח הפרוצדורה בשפת ה-DB (כמו PL/SQL או T-SQL).

לאופציה מספר 3 (ORM) יש גם מגרעות:

  1. קוד ה-SQL שמחולל ע"י ORM עלול להיות לא יעיל בעליל. ככל שרמה הסיבוכיות עולה – הסיכוי שה-SQL שנוצר יהיה איטי גובר.
  2. עבודה עם ORM דורשת לימוד מעמיק של היכולות והמגבלות.
  3. קשה לנסח שאילתות מורכבות בממשק כמו LINQ או HQL. מה שהולך בקלות ב-SQL, הולך קשה ב-LINQ.

מה עושים?

לדעתי – יש לנסות לקחת את הטוב משתי האופציות 2 ו-3. כלומר – כן ליישם ORM – אבל לשלב אותו עם Stored procedure אותם יש לכתוב בשביל משימות שה-ORM מתקשה ליישם בצורה אופטימלית.

עיבוד טרנזקציות? נוח מאד ב-ORM. שאילתות מורכבות? לך על Stored Procedures וחבר אותם ל-ORM.

אשמח לשמוע על רעיונות נוספים.

המצגת והסקריפטים מסמינר SQL Server Service Broker

אפשר להוריד את המצגת ואת הסקריפטים מסמינר SQL Server Service Broker פה:

http://www.f2h.co.il/2902701473795