מה הביג-דיל ב Big Data? (או NoSQL)

הקדמה
אם הייתם עסוקים במיוחד בשנה-שנתיים האחרונות, ייתכן והרמתם את הראש ונוכחתם שהמושג Big Data מוזכר לעתים קרובות, מבלי שאתם מבינים בדיוק על מה מדובר.פעם (לפני כעשור), מערכות ה High Scale היו בעיקר מערכות ה Enterprise המיועדות לארגונים גדולים. לחברת Siemens יש 120,000 משתמשים (users)? וואהו – אתגר ארכיטקטוני מרשים. מערכת המסחר של וול סטריט מבצעת מאות פעולות (transactions) בשנייה אחת? – בלתי נתפס!
חברות ענק כמו SAP, Oracle ו IBM הן אלו שבד"כ התמודדו עם אותם scales , בעיקר בזכות העובדה שאותם לקוחות-ענק קנו מערכות מורכבות שיצרנים אלו סיפקו. יצרן קטן – scale קטן, יצרן גדול – scale גדול.

מאז שנת 2000 האינטרנט פרץ למיינסטרים. מוצרים כמו MySpace ו SecondLife ואח"כ Facebook ו Youtube עקפו בסיבוב את חברות הענק וטיפלו במיליוני משתמשים, petabytes של שטחי אחסון ואלפי (tps (transactions per second. בהדרגה, עוד ועוד חברות קטנות נאלצו להתמודד עם scales אדירים. הכלים להתמודד עם כמויות גדולות של נתונים (כמו פתרונות של Teradata וOracle) גם היו יקרים מדי עבור אותן חברות קטנות, וגם לעתים לא עמדו בקיבולת המבוקשת – וכך אותם ארגונים החלו לייצר חלופות זולות ויעילות להתמודדות עם scale ענק. לא סתם Facebook, Amazon או Twitter שרדו מבין חברות דומות (שלעולם לא שמענו או נשמע עליהן). מלבד הרעיון המגניב, היה צריך להתמודד עם אתגרים טכנולוגיים יוצאי-דופן. רעיון מגניב + ניהול נכון + מצוינות טכנולוגית הוא שילוב נדיר אשר היה דרוש להצלחה.
בסולם ה Scale הוגדר ערך חדש הגבוה מהערך הגבוה הקודם ("High Scale"). מעתה, אמרו "Internet Scale".

הבעיות
הערה:כמו שצוין למעלה, ב Big Data יש עניין מוצהר – טיפול בכמויות אדירות של נתונים, ועניין לא מוצהר, אך לא פחות חשוב – פתרון זול המתאים גם לחברות קטנות. עדיף Open Source, עדיף מאוד Commodity Hardware (שרתים במחיר של, נאמר, עד 10K$ כל אחד)

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

הגדילה בתעבורה של אתר Netflix כמו שדווח על ידם

כאשר יש לכם כמויות גדולות של נתונים, אתם צריכים:

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

למרות ש MySql (או כל בסיס נתונים רלציוני) הוא מוצלח, ישנו גבול של נתונים שהוא יכול לטפל בו. הגדילה הראשונה היא כנראה לקנות שרת יותר חזק (vertical scalability הקרוי גם scale-up). השרת יטפל בפי n כמויות מידע ויעלה לרוב משמעותית יותר מפי-n.
השלב הבא, ברוב בסיסי הנתונים, הוא ליצור cluster של בסיסי נתונים (horizontal scalability הקרוי גם scale-out), בחוות שרתים שלכם או ב Cloud.
איך מטפלים בכפילות מידע? דרך אחת היא ששרת אחד מוגדר לכתיבה בלבד (ומעדכן את השאר) ושאר השרתים רק מבצעים שאילתות קריאה ומשחררים עומס מהכותב. כמו שאתם מבינים זהו בסה"כ קצת אוויר לנשימה.
Partitioning של המידע: לאחסן על כל בסיס נתונים (או cluster כמתואר למעלה) פלח מידע שונה, לדוגמה: פילוח ע"פ מדינות, אות ראשונה בשם המשתמש וכו"
offloading to data warehouse – מדי כמה זמן להעביר את המידע שאליו ניגשים פחות (לרוב מידע ישן) לבסיס נתונים אחר ("מחסן") כדי לגרום לבסיס הנתונים עליו המידע החשוב להיות זמין יותר.

בשיטת ה Partitioning יש שתי בעיות עקרוניות:
א. אם מפצלים נתונים לשרתים שונים, יש להתפשר או על זמינות (availability) או על עקביות הנתונים (consistency) – עקרון הידוע כ CAP Theorem (כלומר – ללא ACID).
ב. שאילתות הכוללות מספר בסיסי נתונים אחד הן מורכבות למימוש ואיטיות במיוחד (במיוחד אם דורשות נעילות). למרות שלספקי בסיסי הנתונים היו שנים רבות ללא תחרות קשה בתחום – הם לא פיתחו את התחום בצורה משמעותית.

Big Data
אותן חברות סטארט-אפ שלא יכלו לשלם על פתרונות יקרים ונזקקו לכלים לטפל בכמויות אדירות של נתונים פיתחו כמה מהפלטפורמות הבאות שרובן הגדול זמין כיום כ Open Source (מסודר ע"פ תחום):

CPU – לרוב אין צורך בפתרון מיוחד. מקימים Cluster עם שרתים זהים ובעזרת Load Balancer מחלקים לכל אחד מנה מהתעבורה. פתרון שקיים כבר שנים.
אחסון פיזי: S3 של אמזון, GFS של גוגל או HDFS* של אפאצ'י (היחידי שזמין לקהל הרחב).
אחסון לוגי: אלו בסיסי הנתונים המפורסמים (הסבר בהמשך) השייכים לאחת מארבע קטגוריות:
- Document Oriented
- Columnar DB
- Graph Database
- Key-Value DB
יכולת לבצע שאילתות מבוזרות: Hive, Hadoop Map-Reduce, Cascading, MrJob ועוד.

בסיסי נתונים NoSQL

פירוש השם NoSql התחיל כ "לא צריך SQL", אולם עם הזמן התפכחו הדוברים והבינו שאין כאן Silver Bulltet – לרוב המקרים בסיס נתונים רלציוני עדיין מתאים. היום ההסבר השגור לשם הוא: "Not Only SQL".

הרעיון פשוט למדי: בסיסי הנתונים הרלציונים הם עשירים ומורכבים: הם מאפשרים שאילתות SQL מורכבות (שאילתות מקוננות, סיכומים סטטיסטים ועוד), הבטחת פעולות ACID**, אכיפה של constraints, טריגרים ו Stored Procedures ועוד. מה היה קורה אם היינו מוותרים על רוב היכולות ומתמקדים רק במערכת היכולה לטפל ב Scale מרבי למקרה הספציפי?

Disclaimer: ההסברים הבאים הם קצת פשטניים, אבל עדיין יכולים להסביר הרעיון העיקרי עליו מבוססת כל קטגוריה של בסיס נתונים NoSql-י.

Document(-Oriented) DB

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

אם נלך לפי העיקרון האקדמי של בסיס נתונים רלציוני ומנורמל תהיה לנו כנראה טבלת סניפים (נאמר 20) המקושרת לטבלת עסקאות (נאמר מיליון בשנה, עשר שנים = 10 מיליון), המקושרת לטבלת פריטים בעסקה (Line Item), נאמר 20 בממוצע בעסקה.

טבלת הפריטים של כל המערכת תהיה בגודל של 4 מיליארד רשומות. כלל האצבע בבסיסי נתונים הוא שמעל 10 מיליון רשומות בטבלה – בסיס הנתונים מתחיל להגיב לאט. כלומר- לא מעשי. בנוסף הכנסה מקבילית של הרבה קופאיות לאותן טבלאות (מקושרות) ייצור רצף נעילות שיגביל מאוד את המערכת (עוד קצת על מקביליות ונעילות – בתחתית הפוסט) מצד שני אנחנו יכולים לקחת את ההנחות המקלות:

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

פיתרון קיים (יצא לי פעם להתנסות בו) הוא במקום טבלת הפריטים – לייצר בטבלת העסקאות עמודה מסוג "string" המכילה XML או JSON עם פרטי העסקה. זהו שיפור משמעותי ב scale, מכיוון שיש לנו פחות rows, פחות אינדקסים לתחזק ופחות joins להריץ. מצד שני יש יותר custom code שצריך לכתוב – עבור דברים שהיינו מקבלים קודם בשאילתה. יתרונות אחרים של גישת ה Document Oriented DB הן שניתן לשנות את הסכמה מבלי לבצע Alter table יקר ואם ישנן עמודות דלילות ב DB – לא נבזבז עליהן מקום מיותר (מה שנקרא Semi-structured data).

בסיסי נתונים Document Oriented נותנים פיתרון מובנה לעקרון זה שכולל לרוב API פשוט לשימוש וכלי שאילתות מבוזר נוסח Map-Reduce. דוגמאות הן MongoDB ו CouchDB. במקום להמציא את הגלגל – קחו Open Source.

Columnar DB

קטגוריה זו, הידועה גם כ Vertical DB פותרת בעיקר בעיות של Data Warehousing: איך לבצע שאילתות יעילות על מחסני נתונים. דמיינו טבלת ענק עם 10 עמודות בגודל x בתים (bytes) כל אחת.
לרוב בשליפות ה SQL אנו שולפים עמודות בודדות. אם הרצתי שאילתה על 3 עמודות, בסיס הנתונים עדיין צריך לקרוא מהדיסק לזיכרון את כל עשרת העמודות – כלומר פי 3 מידע ממה שנדרש. הקריאה מהדיסק היא הפעולה היקרה. אם הייתי מאחסן כל עמודה בקובץ נפרד בדיסק, אולי הייתי מוגבל בשאילתות מורכבות מאוד, אולם השאילתות הפשוטות היו דורשות משמעותית פחות עבודה של הדיסק.
במחסני נתונים, לעתים קרובות, רוצים לבצע חישוב ממוצע / התפלגות ערכים / whatever על עמודה בודדת (ומספרית) מתוך טבלה הכוללת הרבה עמודות שחלקן הגדול הוא מחרוזות (התופסות נפח גדול בהרבה). היכולת לטעון מהדיסק עמודה בודדת יכולה להאיץ את ביצוע השאילתה בעשרות מונים.

דוגמאות בולטות הן Vertica או InfoBright. חברת SAP זכתה לתשואות כאשר באופן מפתיע הצטרפה לחגיגה עם HANA – גרסה In-Memory של בסיס נתונים columnar. כולם פתרונות שאינם open source.

Graph DB

בסיסי נתונים רלציונים הם גרועים במיוחד בתיאור גרפים. נניח שהייתם מפתחים אפליקציה כמו LinkedIn והייתם רוצים לדעת מה הקשר בין שני אנשים, מתוך מאגר של 100 מיליון משתמשים.
ישנו כלל מקל האומר שכל שני אנשים מקושרים ע"י שרשרת של 6 הכרויות. מה נעשה? Join משושה של 100 מיליון משתמשים?? קחו טיול חצי שנה לדרום אמריקה לפני שהשאילתה תסתיים***.

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

Key-Value DB

האם הייתם רוצים להשתמש ב HashTable בגודל של מיליארדי רשומות – שגם יאפשר מקביליות גבוהה? כמה נוח. Key-Value DB יספקו זאת, רק אל תבנו על (O(1 בזיכרון. זוהי פרדיגמה פופולרית במיוחד בקרב חברות אינטרנט:

גוגל יצרה את BigTable ושחררה מסמך מפורסם החושף ארכיטקטורה מהפכנית, אמזון יצרה את Dynamo ושחררה מסמך מפורסם אחר – לא פחות מרשים.

פרויקט Hadoop מימש את התכנון של גוגל ויצר את HBase ו LinkedIn מימשו את התכנון של אמזון ויצרו את Voldemort (כן, הנבל מהארי פוטר).

פייסבוק ערבבה רעיונות של גוגל ואמזון ויצרה את Cassandra שזוכה להצלחה רבה. יש גם את Redis שהוא In-Memory Database המבוסס על אותה פרדיגמה.

סיכום

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

עדכון 1: תודה ליקיר שהזכיר את RavenDB, בסיס נתונים Document עבור פלטפורמת .NET שפותח בארץ ע"י אורן עיני – מפתח ישראלי בולט.

עדכון 2: ripper234 העיר ובצדק (בפרסום ב newsgeek): "מה שהייתי שם בפתיחה למאמר כזה שאסור להתאהב בטכנולוגיות וב-"Big data". פגשתי יותר מדי אנשים שהחלום הרטוב שלהם זה Big Data / NoSql / Technology Buzzwords, אבל שוכחים בדרך את האג'יליות ואת העבודה שבסטארט-אפ עובדים בשביל ליצור value אמיתי, כמה שיותר מהר, ולא מערכת מטורפת שתחזיק 100 מיליון יוזרים 5 שנים קדימה אבל תיקח שנתיים לפתח."

במאמר זה ניסיתי להתמקד בטעות נפוצה אחרת: המחשבה ש Big Data הוא Silver Bullet, שהוספת בסיס נתונים NoSQL תפתור תכנון בסיסי לקוי. ניסיתי להציג את אותם בסיסי נתונים ולהסביר "מה הטריק שלהם", כי לפעמים בצורה מאוד נקודתית ניתן לממש את הטריק הזה לבד ללא מעבר full-fledged לבסיס נתונים שכזה.

* Hadoop Distributed File System השייך לפרויקט העל Hadoop. השם Hadoop הוא שמו של פיל-הצעצוע האהוב של בנו הקטן של מפתח הפרויקט – ומכאן לוגו הפילון.** ACID – Atomic, Consistent, Isolated and Durable הרי הן ה transactions.

*** סתם. ה DB יקרוס אחרי כמה עשרות דקות.

Performance: דחיינות = מקצוענות?

הפוסט עודכן ב 16/10

שאלה: כיצד כותבים קוד שבנוי לביצועים גבוהים?
תשובה: בדיוק אותו הדבר.

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

הקדמה

פעם, עבדתי עם מתכנתת שקיבלה הערות על מסמך Design שכתבה ונראתה פגועה: \"כתבו לי שה-Design שלי ילדותי\". מה?? שאלתי – תראי לי. קראתי את ההערה והיא הייתה: \"premature optimization\".

Premature Optimization

\"Premature Optimization\" למי שלא הבין אינה קשורה לילדותיות, אלא לאופטימיזציה שלא הגיעה זמנה. הזקנים שביננו שלמדו פיתוח בשפת C יכולים עוד לזכור את הסנסיי (במקרה זה מרצה מזדקן למדעי המחשב שעסק במקור במתמטיקה) סופר לנו כל ביט וכל פעולת if. \"מה?, כתבת x/4? ברור ש x*0.25 זה מהיר יותר. בכלל הייתי מצפה ל x>>2\" – הם הכו בנו תורה (סלחו לי אם השיפט הוא לכיוון ההפוך, מרגיז אותי בכלל לבדוק).

בשנות השבעים, שהמחשב ביצע מאות פעולות בשנייה – הייתה לאופטימיזציה כזו חשיבות. טראומת הקוד-הלא-אופטימלי היה כ\"כ קשה שעד היום יש זכר לצלקות (במיוחד באקדמיה).

כיום, מחשב ביתי ממוצע מכיל 2 או 4 ליבות, בקצב של לפחות 2 מיליארד פעולות בשנייה (Ghz), עם instruction-set (כגון MMX או SSE – אליהם ניתן לגשת בעזרת ספריות מיוחדות בשפת C) שמבצעים פעולות ארוכות ומסובכות בצורה יעילה יותר. רק אזכיר שהיום לכל מחשב חדש יש גם (GPU – Graphical Processing Unit) אותו כרטיס גרפי שמובנה בלוח האם, בתוך ה CPU או על לוח נפרד. יחידות עיבוד אלה בנויות לביצוע פעולות מתמטיות פשוטות במקביליות גבוהה ויכולים להציג כח חישוב מפחיד.

דוגמא טובה לשימוש אינטנסיבי במעבד היא פיצוח ססמאות. הרי ממשלות, משטרות (וארגוני פשע) בונים מחשבי על בכדי לפצח מסרים מוצפנים של אוייביהם. בימנו המאיצים הגרפיים (GPU) התקדמו כ\"כ עד שהם מאפשרים פיצוח סיסמאות בקצב מהיר פי 20 – בעזרת חומרה במחיר זהה. בשל הכניסה של תכנות ל GPU לשימוש**, המליצו כבר גופי אבטחה לחייב את המשתמשים בסיסמא מינימלית באורך 12 תווים. אויי לא!

למה לעשות אופיטמיזציה?

אז מה ניתן להסיק? שחשיבה על יעילות היא לא חשובה? כן – ולא.

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

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

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

תחום הדפדפנים החל ברצינות באמצע שנות התשעים – כלומר, ידע רב הצטבר בתחום בחמש עשר השנים האחרונות.
אני זוכר מקרה שבו אפליקציית web שכתבנו הייתה איטית להחריד. לדף מלא לקח 56 שניות (!) לעלות על reference client hardware, שהיתה מכונה חלשה מהרגיל כדי לייצג את המשתמש עם המחשב שמיושן. המעבר מ explorer 6 ל explorer 7(שאז היה חדש) שיפר את טעינת הדף לפחות מ 12 שניות. מקור הבעיה היה קובץ javascript גדול במיוחד. ניתוח מקיף הראה שאספלורר 6 ביזבז יותר מ 40 שניות על פיענוח (parsing) של הקובץ בעוד מנוע פיענוח חדש באספלורר 7 הוריד את הזמן לשניות בודדות (הנה דוגמא לסדרי גודל).

\"כיצד יכול להיות שיפור כ\"כ גדול בגירסה מס\' 7 של מוצר?\" תהיתי זמן רב. האם הדפדפנים הגיעו לקצה גבול היכולת? עם כל אופטימזציה אפשרית? (צחוק גדול ברקע)

הנה התבוננו במספרים מתוך מבחני ביצועים של האתר הראוי Tomshardware. המבחן בחן דפדפנים שונים על חומרה זהה שבבסיסה מעבד i7-750.

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

הנה פיירפוקס 3.6 וכרום 10 ו אקספלורר 9 (מרס 2011) מול פיירפוקס 7, כרום 14 ואקספלורר 9 עם מספר עדכונים (ספטמבר 2011). מוצרים לא לגמרי חדשים, שנוצרו ע\"י טובי המהנדסים:

הרצת JavaScript במבחן Kraken 1.1

מהההה???

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

הנה עוד מבט, כמה אפשר עוד לשפר ממוצר קיים ובוגר את זמן העלייה (startup time)?

בחצי השנה הזו Chrome הצליח להוריד את זמן העליה מ6 ל2 שניות – שליש מהזמן המקורי (תוך כדי שיפורים בזמן טעינת הדף) וגם Opera הותיק הציג שיפור חסר תקדים. שאר הדפדפנים נותרו עם 4 עד 5 שניות (בחומרה הנ\"ל).

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

http://www.tomshardware.com/reviews/internet-explorer-9-chrome-10-opera-11,2897-5.html

http://www.tomshardware.com/reviews/firefox-7-web-browser,3037-5.html

והשיפורים לא הגיעו למיצוי: לאחרונה הבחנו בעבודה ש chrome 14 התחיל להשתמש באופטימיזציה של פרוטוקול SSL שקיימת כ10 שנים בתאוריה אך אף דפדפן לא השתמש בה עד עכשיו. להלן חשיבה על ביצועים בארכיטקטורה.

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

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

האם ה Software Design מוכיח את עצמו? אם השקעתי יום בשיפור הקוד והדזיין לא טוב – זהו יום מבוזבז. האם המוצר בכלל מעניין לקוחות ומצליח להמכר? אם שיפרתי ביצועי קוד עשרות פעמים עד השחרור כדי לגלות שייצרתי מוצר לא מעניין (אך מהיר) – אלו עשרות ימים שהלכו לפח. גישת האג\'ייל מפרטת את הנושא הזה בצורה יסודית.

עוד נקודה היא קריאות הקוד: קוד אופטימלי הוא לרוב פחות קריא. נקודה זו רק מחזקת את הנקודה הקודמת – לא ארצה להשקיע בקריאת קוד קשה לקריאה במשך זמן פיתוח רק בכדי לגלות שהמוצר לא מעניין.
נקודה חשובה אחרונה היא עקרון פארטו שמתאר יפה מאוד את תחום הביצועים התוכנה: 80 אחוז מהשיפורים יושגו ב 20 אחוז מאזורי הקוד. אולי אפילו יותר. להשקיע ולהקשות את הקוד לקריאה ב 100% מהאזורים של הקוד – זו פשוט השקעה לא משתלמת. וב Performance כמו ב Performance יש תמיד הפתעות. שיפור במקום אחד יכול לפתוח מספר צווארי בקבוק ולהשיג שיפור משמעותי מאוד בעוד ששיפור אחר שנראה נהדר על הנייר לא ישפיע כ\"כ בפועל כי הקוד ייתקע במקום אחר. חשוב מאוד לבצע pilots של שיפורים ולעשות profiling שוב ושוב בתצורות שונות בכדי להבין את התנהגות ביצועי המערכת.

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

** כדי להשתמש ביחידות אלה יש לכתוב קוד ל instruction-set מיוחד, כגון CUDA. עקרון זה של כתיבת קוד כללי ל GPU נקרא GPGPU.

*** במקור המילה Hacker הייתה תיאור כבוד יקר-ערך. האקרים היו אותם מומחי מחשבים, יחידים במינם, שהבינו לעומק את ה Linux Kernel, דקויות של פרוטוקולי תקשורת וידעו לכתוב קוד יעיל שמתקיים על כמעט-אפס זיכרון או פעולות מעבד. מאז מחולקים באינטרנט כלים אוטומטים לפירוק אתרי-ענק לגורמים, שלא דורשים יותר מהקלדת כתובת ה IP של הקורבן. ההאקרים קראו למשתמשים אלו Script Kiddies בקול מלא בוז – אך השם לא כ\"כ תפס. על כל האקר אמיתי שמפצח פירצה וכותב ספרייה לנצל אותה, יש עשרות אלפי Script Kiddies שזכו בתהילה. טננבאום, ה\"אנלייזר\", הוא דוגמא טובה. עצוב.