Sid Knopp, Maya-Tech
עבור מערכות הדורשות אספקת נתונים מהירה, הפתרון טמון ביישומי האצת ניצול ארכיטקטורת, ioMemory, על ידי שילוב של VSL ו-ioMemory לפלטפורמת ioMemory אפשר לקחת את היישומים הארגוניים ומסדי הנתונים לשלב הבא.
לוח יחיד יכול לספק 2.4TB או יותר
מ-ioMemory ל-x4 ו-x חריץ PCI Express, להבטיח את היישומים בצורה חלקה, להתמודד עם מוקשי תנועה גדולים יותר.
לוחות אלו פותרים בעיות I/O עבור יישומים צבאיים הדורשים פענוח מהיר במיוחד של מידע, עבור יישומים תעשייתיים הדורשים מהירות, ועבור מערכות ה-IT המבקשים לזרז את העומס.
המלחמה הסייבירית שמתרחשת היום דומה מאוד למלחמה הפיזית הקלאסית.
האזנה, צפייה, איסוף מידע ממקורות שונים וניתוחו.
הבעיה היא שברמה הסייברית ישנו TB שמהירותו רבה מבן אדם..
אז כדי לאסוף מידע, לבצע תיאום מידע, לנתחו, לשלוח אזהרה במקרה של חשד, נצטרך DB גדול או מנוע מתאם (נתונים גדולים).
כך שאם הם ינסו להוציא דיווחים המבוססים על הקורולציה של טרה בייטים של נתונים, זה יכול לקחת שעות אם לא ימים.
למה? בגלל מסע החקירות של האפליקציות שיאטו את הגישה של הקלט/פלט.
ניתן להשקיע בהרחבת הזיכרון על ידי דיסקים קשיחים או SSDs אך הדבר לא יעזור, וגם אם כן, רק לתקופה קצרה ביותר.
Fusion-io מציעה את ההשהיה הנמוכה ביותר. במילים אחרות, תהליך החקירות הוא מינימאלי. כך תהליך הקריאה/כתיבה יכול לקחת עד 1.1M IOPS.
באופן פרגמטי, ניתן לראות שכאשר מתרחשות פעילויות חשודות הן יכולות להשפיע באופן מיידי על חייהם של אנשים רבים, להתראה של שניות או שעות יש השלכה משמעותית.
לדוגמא: טרוריסט יכול להתקשר כל יום, לשלוח מיילים ולהעלות את דעותיו באתרים ספציפיים, אך יום אחד לשנות משהוא מסדריו, להשתמש בסמנטיקה שונה לדוגמא, שינוי זה יכול להופיע אצל כל אלה שהיה איתם בקשר יום יומי עד עתה.
במקרה כזה הודעה אחת, הערה אחת יכולה להצביע על תקיפה, הבדל בין שעתיים לנתח את ההודעה לבין כמה שניות, הוא הבדל משמעותי, הבדל של חיים ומוות.
אם מטוס מבצע צילום איזור לצרכים בטחוניים, כמה אימג’ים יעברו סינון עד שניתוח התמונות יתבצע?? וכמה זמן ניתוח זה ייקח?
מערכת Fusion-io יכולה לחלק את הזמן לניתוח ואת זמן הניתוח עצמו פי-3, פי-10, או אפילו פי-100 יותר מהר.
פלאש הופך את
Big Data ליעיל יותר
ב-Big Data, לפלאש אין משמעות של ביצועים בלבד, המטרה היא יעילות. ביצועים טובים הם יעילים במערכות קריטיות (מצילות חיים).
ארכיטקטורות המבוססות על ביצועי DRAM לבד, יסבלו מחסכים בכל הקשור ממחסור בהתערבות להעברת Data ביניהם.
פלטפורמות של Big Data מבוססי זיכרון פלאש יכולים להחליף לחלוטין את הכוננים הקשיחים המכניים ובכך יפחיתו את כמות ה-DRAM footprints או שיהוו תוספת טובה לאחסון מידע וישמשו גם כ-Cache Layer.
שתי האפשרויות יביאו לשיפור ביעילות תפקוד המערכת ואף יפחיתו את ההוצאות התפעוליות.
רבות מיישומי ה-NoSQL database נשענים בעיקר על ביצועי DRAM. הבעיה היא שנפח ה-DRAM, אינו מספק עבור Active Data Sets ברוב היישומים של NoSQL Deployments.
ככל שהצפיפות ב-DRAM Module, גבוהה יותר, כך המחיר גבוה יותר, הדבר מוביל לכך שמודולי זיכרון של 32GB מצטרפים למשחק. בשל סיבה זו ניתן להבין למה מהנדסים מגדירים שרתים עם מודולי זיכרון של
8GB & 16GB.
הדבר עדיין מגביל שרתים לנפח זיכרון DRAM מקסימלי 128GB & 256GB.
ioMemory מאפשר למשתמש להתקין פלאש בנפחים של טרבייטס, במקום כונן קשיח מכאני, ולהסיר את הצורך בשימוש יתר ב-DRAM Provisioning בשימוש כ-Cache.
שימוש ב-ioMemory כאחסון ראשוני, יביא לשיפור דרמטי בביצועים עד כדי פי 10 מהביצועים במקור. עם ioMemory, המערכת מבטלת את הצורך המסורתי של מגירות דיסקים, התופסים נפח גדול (בנוסך חום וצריכת הספק), כאן ניתן להגיע לאותה רמת ביצועים ולהרבה יותר על ידי שימוש במספר כרטיסים בודד. ורק חשבו על השינוי המשמעותי ב-Footprint, כאשר המערכת דורשת 50,000 טרנזקציות לשנייה.
אין צורך בהרבה כוח עיבוד (Horse Power)! מה שבאמת נחוץ זה אחסון מהיר.
עבור יישומים של Big Data, המותקנים כמערך Hybrid Storage, הצירוף בין הדיסק הקשיח ל-SSD, יכול לגרום ל”פקק” ב-SAN, שיגרום בתורו לירידה משמעותית במהירות הביצועים בהתקן האחסון של הפלאש, שיוביל להפחתה בהחזר ההשקעה על הפלאש.
נתיב מהיר יעניק עדיפות גבוהה עבור עומסים כבדים במשימות קריטיות, על ידי מתן הזדמנויות להעברת מידע, על ידי תיוג ה- (Logical Unit Number), כך שזיכרון ההבזק יקבל העדפה בטרנזקציה.
