כשמנמ"רים או מנהלי תשתיות נשאלים מהוא רכיב החומרה החשוב יותר מבחינתם במערכת מחשב גדולה (מעבד, זיכרון או I/O) הם מייד מצביעים על המעבד או מערך האחסון. לחלק חשוב יותר סוג המעבד וכמות המעבדים במערכת. השאר מייחסים חשיבות רבה למנגנון ה-I/O ודואגים לרפד אותו במערך אחסון משובח ויקר. מעטים האנשים שמייחסים לזיכרון ה-RAM במערכת את החשיבות המגיעה לו.
הסיבות לכך: הסיבה הראשונה - מגבלות ארכיטקטורה. רוב יצרני המחשוב הציעו בעבר מארזים מקובעים שבהם מספר המעבדים וכמות הזיכרון מוגבל וידוע מראש. למעשה רוב היצרנים עדיין מציעים מערכות מאוד מקובעות. "אם יש לך צורך עד 128GB המערכת של 4 מעבדים תתאים לך - אבל אם יש צורך לגדול עד 256GB, יש צורך לעבוד לדגם עם 8 מעבדים ...." . ומה קורה אם יש לי צורך במערכת עם 4 מעבדים בלבד ו 192 GB RAM ? ....
הסיבה השנייה - מחירי הזיכרון. בעבר הלא רחוק מחיר הזיכרון בשרתים היה יקר מאוד - עד כדי אלפי דולרים לכל גיגהבייט של זיכרון. בחשבון הכולל רכיב הזיכרון המערכת עם כמות זיכרון נכבדה יכול היה להגיע למאות אלפי דולרים.
לסיבות שציינתי לעיל לא צריך להיות מקום בשיקולים עכשוויים. מגבלות הארכיטקטורה הן שריד היסטורי. לצערי רוב היצרנים עדיין מקובעים על מגבלות אלו - אך אין זה אומר שאנו צריכים להסכים לכך. SGI בונה את מערכות המחשב שלה בארכיטקטורה המאפשרת לה לשים כמויות עתק של זיכרון כמעט ללא תלות במספר המעבדים - זוהי ארכיטקטורת NUMAFLEX. גם הסיבה השנייה כבר לא רלוונטית. יצרן שהשכיל לעבור לרכיבי זיכרון סטנדרטיים יכול להציע אותם בשבריר מהמחיר שהיה נהוג בעבר.
למה צריך כל כך הרבה זיכרון אז מדוע בעצם אנחנו צריכים כל כך הרבה זיכרון? 100GB של זיכרון נשמע המון, מי צריך יותר? (זוכרים, מישהו חשוב אמר בשנת 1981 כי 640 קילובייט של זיכרון צריכים להספיק לכל דבר....).
הסיפור הוא פשוט: ניקח לדוגמה מסד נתונים גדול במערכת DataWarehouse. במערכות קונבנציונאליות כשרצות שאילתות שסורקות טבלאות שלמות - רק שבריר מהנתונים נמצא ברגע נתון בזיכרון. המערכת תביא לזיכרון העבודה כל פעם חלק קטן יחסית של הטבלה ותזרוק אותו מהזיכרון כשנצטרך את החלק הבא. אם נריץ כמה שאילתות, אפילו במקביל, שעוברות על אותן נתונים נאלץ לגשת למערך האחסון פעם אחר פעם להביא את אותם הנתונים - כך נאבד זמן יקר. אם יהיה ברשותנו זיכרון גדול נקטין משמעותית את הצורך לגשת אל מערך האחסון - במיוחד אם נדאג להעלות את האינדקסים באופן קבוע לזיכרון. כך נאפשר למערכת הדטהבייס להתרכז בעבודה האמיתית - ולא להשקיע חלק נכבד מזמנה בפעולות קלט פלט. כמובן, אנחנו לא מוותרים על מערך האחסון - הזיכרון כבודו במקומו מונח, אך יש צורך לכתוב את הנתונים בסופו של דבר לזיכרון שאינו נדיף.
SGI ביצעה לא מעט בדיקות ישימות של מערכות DataWarehouse עם זיכרון גדול והאצת הביצועים היא משמעותית - עד כדי סדר גודל ויותר. הדבר המעניין הוא שהכוונון הנדרש למערכת כזו הינו מועט ביותר. בדומה ל-DataWarehouse ניתן למצוא יישומים נוספים שירוויחו משמעותית מהעלאת חלקים משמעותיים של הנתונים באופן קבוע לזיכרון. אני משאיר לדמיונו של הקורא/ת את החיפוש אחר יישומים אלו.
הנושא של זיכרון גדול תופס יותר ויותר תאוצה בעולם וההכרה בתועלת שניתן להפיק מעבודה עם זיכרון גדול תופסת תאוצה מרשימה. לא מן הנמנע שבקרוב נראה מערכות שמעלות מסדי נתונים בגודל של כמה טרה-בייט לזיכרון. ל-SGI יש מערכות לינוקס העובדות עם טרה-בייטים רבים של זיכרון משותף (לא, אין כאן שגיאת דפוס - טרה-בייטים של זיכרון RAM משותף!). המושג IMDB - שפירושו In Memory Data Base - תופס גם הוא תאוצה ומתפשט מכוון המערכות הייעודיות אל מערכות המיינסטרים. דוגמה מעניינת לכך היא חברת TimesTen שנקנתה לפני כשנתיים על-ידי חברת Oracle. TimesTen מתמחה ב-IMDB - דטהבייס שכולו בזיכרון. TimesTen מסוגל לעבוד כדטהבייס עצמאי או כ-FrontEnd לדטהבייס קונבנציונאלי כגון Oracle. במערכת כזו - שתוכננה מראש לעבודה בזיכרון - ניתן להגיע להאצה של פי מאות מונים!
לסיכום אפשר לומר: המטמון נמצא בזיכרון!