מאת יובל מלחי,מנהל פעילות SYBASE, נס טכנולוגיות
מיוחד לאתר dwh.co.il
נניח שהחלטת לסעוד במסעדה מפוארת. ונניח שהחלטת לפתוח במרק. המלצר לוקח את ההזמנה שלך ומביא לך מרק, אבל לא בקערת מרק אלא בצלחת שטוחה וגדולה. המרק נשפך עליך אבל אתה מחליט לנסות ולאכול אותו בכל זאת. אתה לא יכול להשתמש בכף, המרק כבר קר וכולם צוחקים עליך. אתה מחליט להישאר רגוע כדי לטעום את הסטייק המפורסם שלהם. ואז מגיע הסטייק שלך - בכוס יין. אתה מתעצבן, נשבע שרגלך לא תדרוך במסעדה זו שוב ובורח החוצה בתסכול.
למרות זאת, הדבר המצחיק הוא שאנחנו מוכנים לקבל את זה על בסיס יומיומי במערכות ניהול הנתונים שלנו; בסיסי נתונים גדולים מדי, שאילתות שמסתיימות אחרי שעזבת את המשרד, עדכונים למחסן הנתונים שלוקחים לילה שלם, שיחות בהולות בסופי שבוע, מערכות שקורסות וכו' וכו' וכו' ...אז למה בעצם המקרה הראשון מרתיח אותך בעוד עם השני אתה בוחר לחיות (בנוחות?).
בואו ונעשה הכרה עם בסיסי נתונים טוריים (Column Oriented databases), או בשם אחר - מחסני נתונים אנליטיים סופר מהירים.
בסיסי נתונים טוריים = מחסני נתונים אנליטיים סופר מהירים
בשנתיים האחרונות אנו רואים פריחה בכמות בסיסי נתונים המתמחים בניתוח אנליטי שנועדו לפתור בעיה שכל ארגון נתקל בה: איך אני מאפשר לעשרות ומאות משתמשים גישה מהירה לכמויות אדירות של מידע?
לפי דעת האנליסטים, קצב גדילת המידע לא הולך לדעוך בזמן הקרוב. כמות המידע גדלה היום בקצב של כ- 20-50 אחוז בשנה כמעט בכל ארגון. בסיסי נתונים שנבנו במקור לכתיבת מידע במהירות, לא עומדים בקצב האחזור הנדרש לארגונים עם טרה-בייטים של מידע. אנחנו יכולים לכופף לבסיסי הנתונים את היד ולבנות מערכות צדדיות, להוסיף כמויות של אינדקסים ולהפעיל חמישה DBA-ים אך באיזה מחיר? והאם אנחנו מרוצים לגמרי מהתוצאות? אז זהו, שלא. לפי המחקרים האחרונים ולפי קביעות האנליסטים ומנהלי מערכות מידע דרוש פתרון אחר, פתרון מובנה ויעיל המותאם למשימה. קערת מרק למרק וצלחת לסטייק.
שוב נשאלת השאלה, האם נוכל ליצר דו"ח על מערכת של 60 טרה-בייטים באותה מהירות בה נוכל ליצר דו"ח ממערכת של 60 מגה-בייטים? התשובה בגוף השאלה. וזו בדיוק הסיבה שהמגמה החדשה בקרב בסיסי נתונים היא בסיסי\מחסני נתונים אנליטיים, המסוגלים לטעון מידע ולאחזר שאילתות בזמן אפסי ללא תלות בכמות המידע של הארגון. נשמע דמיוני?
בסיסי הנתונים האנליטיים דומים יותר למחסני נתונים מהירים במיוחד, הם רלציונים, מדברים ספרדית (סתם, SQL) והם מהירים יותר מכלב בתאילנד. המהירויות מושגות ע"י שינוי שיטת החשיבה המסורתית: המידע מאוחסן פיזית בטורים ולוגית בשורות בעוד במבנה בסיס הנתונים הקלאסי ההפך הוא הנכון. דבר זה מאפשר לבנות לפחות אינדקס אחד על כל עמודה, להקים טבלאות רחבות ככל העולה על הדעת ולטעון נתונים בקצבים מטורפים.
כיוון נוסף שבסיסי נתונים טוריים נוטים אליו הוא פתרון out of the box - מחסן נתונים אנליטי מוכן לשימוש שכולל כל מה שדרוש לפריסת מחסן נתונים ארגוני, לדוגמא "IBM's Analytical Appliance" הכולל חומרה מסוג IBM p-Series, Sybase IQ וMicrostrategy. ישנם גם חברות המשתמשות במחסן הנתונים האנליטי בצורה מוטמעת כגון חברת אריקסון וחברת TTI Telecom, המיישמות מוצרים על בסיסי נתונים אלו למטרת איסוף ודיווח בתחום ה- CDR.
השחקנים החדשים בתחום בסיסי הנתונים הטוריים הם רבים, והכמות בלבד מעידה על עתידו המבטיח של התחום. ישנם כבר ארגונים גדולים העובדים עם בסיסי נתונים טוריים בתור מחסני נתונים ארגוניים ואם לשפוט לפי התגובות הנלהבות, חוקי המשחק משתנים לנו מול העיניים. בין השחקנים בתחום ניתן למצוא את Vertica, Exasol, InfoBright, ParAccel, Sand, CalPont ו Sybase IQ.
יתרונות משמעותיים של מחסני מידע אנליטיים
לבסיסי נתונים טוריים יש שני יתרונות בולטים, האחד הוא האצת שאילתות למהירויות שנחשבות לא חוקיות במספר מדינות בדרום אמריקה, בין פי 2 לפי 1000 מהר יותר מבסיסי נתונים "קלאסיים". היתרון השני הוא דחיסת וכיווץ המידע מכיוון שהנתונים הנשמרים ב"דף" זהים אחד לשני. ההפך הוא הנכון בבסיסי נתונים שורתיים בהם הנתונים הפיזיים הנשמרים ב"דף" אינם דומים זה לזה. זו הסיבה שדחיסה ברמת הטור יעילה בהרבה מדחיסה ברמת השורה. במקרים מסוימים מידע גולמי אשר "מתנפח" פי 3 עד 5 בבסיס נתונים שורתי, מתכווץ לחצי (מהמידע הגולמי!)בבסיס נתונים טורי.
במספרים - קח טרה-בייט גולמי, מזוג אותו לבסיס נתונים רגיל, תוסיף קורט אינדקסים, קמצוץ טבלאות אגרגציה, ליטר של MV ועוד, וקיבלת 4 TB. עכשיו תבנה מערכת DRP, תגבה את בסיס הנתונים ושמור עותקים מספר ימים אחורה, תוסיף מערכת צדדית לדוחות וקיבלת עשרות TB. אותו דבר בבסיס נתונים טורי וקיבלת מספר TB בודדים בלבד.יפה לא?
דחיסת המידע בעצם תורמת למהירות השאילתות הגבוהה - פחות קריאות וכתיבות לדיסק. לפני כשנתיים, ביצעתי POC עם בסיס נתונים אנליטי שבו אותה שאילתה-על אותה חומרה-עם אותו מידע לקחה 50 שניות במקום 4 שעות! זו הייתה ההתחלה בשבילי, הניצוץ, בכדי להבין על מה כל המהומה. אם אני עסק שיכול להריץ שאילתה ב4 שניות בזמן שהמתחרים שלי מריצים את אותה שאילתה ב4 דקות או 4 שעות, יש לי יתרון ברור שאני יכול לנצל לטובתי, נוסיף לזה את דחיסת המידע המשמעותית ואני לא רק מאחסן יותר מידע בפחות חומרה (כסף), אלא אני יכול לנתח את המידע מהר יותר וטוב יותר.
בסקר גרטנר האחרון, ישנו סעיף שלם המתייחס לבסיסי נתונים אנליטיים. דונלד פיינברג, סגן נשיא בגרטנר העולמית כותב ש"ספציפית, מערכות הDBMS מוכוונות הטורים כגון: ParAccel, Sand/DNA, Sybase IQ Analytics Server ו Vertica, הראו עליונות מוחלטת באפליקציות אנליטיות לעומת מערכות DBMS מסורתיות מבוססות שורות. במקרים מסוימים הם אף הראו ביצועים פי 100 טובים יותר" פיינברג הוסיף שחברות צריכות להתחיל לחשוב ברצינות על שילוב בסיסי נתונים אנליטיים בארגון בתור מחסן נתונים ארגוני או בתור data marts.
OLAP ומחסני נתונים אנליטיים
השימוש בכלי OLAP נועד לסייע בקבלת החלטות ע"י החזרת תוצאות בזמן אמת. תוצאות ב- OLAP מחושבות מראש ונשמרות במבנים רב מימדיים הנקראים קוביות. המידע בקוביות מוכן מראש וזמין למשתמשים מיידית. תוצאות משאילתות כמו "כמה מחשבים ניידים מכרתי בסין ב- 2008" יחזרו מיד. זהו פתרון מצוין למשתמשים המבקשים תוצאה סכומה ברמה גבוהה, אבל פתרון בעייתי למשתמשים אחרים. כמה ממגבלות של קוביות OLAP:
- קדיחה - שאילתות Drill through הניגשות למידע מחוץ לקובייה, רצות לאט ויכולות לגרום לבסיס הנתונים להאט בצורה משמעותית ואף לקרוס. אם יש צורך בנתונים אשר לא בקובייה, לדוגמא לא רק כמה מחשבים מכרתי בסין אלא גם איזה מודל, אני אצטרך לבצע "drill" מחוץ לקובייה. מה אם נרצה להציע קופון לכלל הלקוחות שרכשו מחשב? מעבר לזה, מה אם נרצה לראות אילו לקוחות השתמשו בקופון זה? לקבל את מידע זה יש צורך בשאילתת Drill through. שאילתות Drill through מכבידות על מחסן הנתונים ויכולות להפריע לכל משתמשי בסיס הנתונים לא רק למשתמשי ה- OLAP.
- השבתה - בזמן בניית הקוביות ישנו זמן השבתה שבו משתמשים אינם יכולים לגשת לנתונים.
- יצירה - יצירת קוביות הוא תהליך ארוך וכבד. אם המידע בקובייה הוא דינאמי יש לבנות מחדש את הקובייה בהתאם לשינויים.
• Ad-hoc - שאילתות Ad-hoc אינן אפשריות, רק מה שכבר נוצר וסוכם. לדוגמא, אם יש לי קוביית OLAP המתארת מכירות מוצר ללקוח, לא ניתן להוציא מקוביית ה- OLAP את הלקוחות אשר רכשו מוצר A ולא רכשו מוצר B. במילים אחרות, אין אפשרות לפלח את הנתונים מעבר למידע הסכום.
- רזולוציה - קוביות נבנות על בסיס חצי שעה או שעה ברמתן הנמוכה ביותר, אך מה אם בעל חנות מבקש לראות איך תפקדו הקופות בזמן הפסקת הצהריים על בסיס רבע שעה? גם את המידע הזה יש להשיג מחוץ לקובייה.
בעוד למערכות OLAP יתרון בעבודה עם מידע סכום מראש, כל שאילתה שסוטה אפילו במעט מהקובייה מכבידה על בסיס הנתונים. שילוב של כלי OLAP ובסיס נתונים מבוסס טורים הוא פתרון מוכח וארגונים אשר משתמשים בפתרון זה נמצאו שבעי רצון עד מאוד. שאילתות אשר אינם מתאימות לקובייה יחזרו במהירות במחסן נתונים אנליטי.
פתרון נוסף אשר נכלל במספר בסיסי נתונים אנליטיים הוא "On The Fly OLAP", תוספת לשפת הSQL המאפשרת לבנות מבנים רב-מימדיים בתוך מחסן הנתונים. שאילתות OLAP אלו לא דורשות את התקורה של מערכות OLAP, דבר היכול להתאים לארגונים מסוימים ולצרכים של אפליקציות אנליטיות דינאמיות.
למי ולהיכן זה מתאים
ישנן מספר אפשרויות היכן וכיצד ליישם מחסני נתונים אנליטיים. דוגמאות למקומות בהן בסיס נתונים אנליטי משרת היטב את הארגון אינן מוגבלות לסביבות בגודל טרה-בייטים בלבד. כל ארגון שיכול להרוויח משאילתות ad-hoc יכול להיעזר בבסיס נתונים אנליטי.
בסיסי הנתונים החדשים מאונדקסים בצורה מיוחדת השונה מהדרך בה מאונדקסים בסיסי נתונים "קלאסיים". חלק ממחסני הנתונים מכילים לפחות אינדקס אחד על כל עמודה ומאפשרים להוסיף אינדקסים נוספים לכל עמודה. משמעות האינדקסים היא שמשתמשים יכולים להריץ שאילתות בחופשיות,ad-hoc , ללא ידיעה מראש אילו שאילתות יורצו, ומבלי ש- DBA יצטרך לייעל כל שאילתה שרצה במערכת. זהו שינוי תפיסה לDBA-ים שמכירים רק בסיסי נתונים "קלאסיים". במערכת OLTP קלאסית, כמות האינדקסים מוגבלת בד"כ ל3-4 אינדקסים לכל טבלה. מה אם רוחב הטבלה הוא כ- 200 עמודות? מה עושים אז?
דוגמאות לשימוש במחסני נתונים אנליטיים אפשר למצוא כמעט בכל תחום - בנקים המריצים תוכנות לאיתור הונאות וחייבים להחזיר תוצאות מיידיות. חברות טלקום המאחסנות כמויות אדירות של מידע, ויכולות לטעון מאות גיגה-בייטים של מידע למחסן הנתונים ביום, ועדיין להריץ שאילתות במהירות שיא. ארגונים ממשלתיים וביטחוניים האוספים ומאחסנים כמויות מסיביות של מידע, וצריכים לנתח לעומק את המידע. כל אלה הם ארגוניים הקוצרים את פירות השימוש בטכנולוגיית בסיסי הנתונים האנליטיים.
ניקח לדוגמא את משרדי הIRS שירותי מס ההכנסה האמריקאי, שהחלו להשתמש במחסן נתונים טורי כבר ב- 1996 על בסיס Sybase IQ. בסיס הנתונים שלהם גדל מ2 טרה-בייטים ל- 158 טרה-בייטים, ושאילתות ad-hoc לדבריהם, לוקחות כעת שניות לעומת שעות בעבר. ה- IRS מוסיפים כארבע טרה-בייטים למערכת בכל שנה ומכנים את בסיס הנתונים שלהם "הנשק הסודי שלנו".
לא רק בIRS מתלהבים מיתרונות הטכנולוגיה, פחות או יותר כל משתמש בבסיסי נתונים טוריים נשאר פעור פה לנוכח המהירות הלא קונבנציונאלית . חלק מהלקוחות מספקים סיפורים יוצאי דופן:
"[השרת האנליטי] הוריד את זמן הטעינה ויצירת האינדקסים מחצי שעה ל2.5-3 דקות, מהירות השאילתות היו גבוהות פי 20 עד 50 מאשר בOracle".
- משרד סטטיסטיקות התחבורה האמריקאי
"עם [שם השרת האנליטי], שאילתות שלקחו שלוש עד ארבע שעות, רצות בשלוש עד ארבע דקות. אנו רואים ב[שם השרת האנליטי] סוג של נס"
- Vodafone
"במקור חשבנו ש[שם השרת האנליטי] יחסוך לנו כ150 אלף דולר בשנה. אך במשך 5 השנים האחרונות הוא חסך לנו כ5 מיליון דולר, בכך שעזר לנו לחשוף סוגי הונאות שלא ידענו שקיימות, ונתן לנו כלים להטמיע אמצעים להיפטר מהגורמים"
- American Airlines
אין פלא שישנם מספר כה רב של שחקנים חדשים בתחום מחסני הנתונים הטוריים ואין להקל בהם ראש. אם נקשיב לאנליסטים ולשחקנים מרכזיים בשוק, עלינו להתחיל ולהתכונן לדור הבא של פלטפורמת אחסון הנתונים - מחסני נתונים אנליטיים.