אפליקציות ודרישות
יישומים יכולים לטפל בנתונים בדרכים רבות. אפליקציות מסוימות משמשות כמערכות אחסון ואחזור של נתונים. הם עשויים לאחסן נתונים בארכיון ממגוון סיבות. תוכנת גיבוי מאחסנת נתוני משתמש בארכיון באופן תמונה, ומאפשרת למשתמש לשחזר את מצב המחשב והקבצים שלו במקרה של כשל חומרה או מחיקה בשוגג. אתרי אינטרנט גדולים כגון archive.org פופולריות סורקים אתרי אינטרנט פופולריים ושומרים תמונה המאפשרת למשתמשים להציג את הגירסאות הקודמות. ייתכן ממשווק שתרצה לאחסן מידע בנוגע לכל עסקה בודדת למטרות חשבונאות ומיסוי.
יישומים אחרים מאחזרים נתונים כדי לאפשר קבלת החלטות. דוגמה אחת לכך היא מערכות בינה עסקית. מערכת בינה עסקית יכולה לעבד מיליוני עסקאות ולהסיק מגמות מכירות. ניתן להשתמש במידע זה כדי לאפשר למשווק לקבל החלטות לגבי מלאי ושיווק.
אפליקציות יכולות גם לחלץ ידע לצורך ניתוח. לדוגמה, Google1 גילה כי מגמות חיפוש של מילות מפתח מסוימות הם מאוד תואם עם ביקורים רופאים עבור סימפטומים כמו שפעת.
נתונים יכולים גם להפוך שירות לזמין. כמעט כל סוג של שירות אינטרנט דינאמי המגיב לבקשות משתמשים הוא דוגמה לכך. מופעים ספציפיים כוללים תוכנת מיפוי וניווט. על-ידי איסוף מידע אודות רשתות כבישים וכתובות, מערכת (כגון Google Maps) יכולה להגיב לשאילתות הקשורות לכיוון.
דרישות יישום
לאפליקציות שונות יש דרישות שונות של מערכות אחסון. Netflix, לדוגמה, צריך לשרת וידאו ברוחב פס גבוה למיליוני משתמשים במדינות/אזורים שבהם הוא פועל. חיפוש Bing, מאידך, חייב לנתח שאילתה ולאחזר תוצאות מדויקות עבור שאילתה זו בתוך פרק זמן קצר מאוד. בסעיף זה נבחן בקצרה את הדרישות השונות שנכפו על-ידי אפליקציות במערכות אחסון:
קיבולת: מערכות אחסון חייבות להיות מסוגלות לטפל בדרישות הקיבולת עבור יישום. מערכת אחסון אמורה להיות היכולת לטפל בכל נפח הנתונים הנדרש על-ידי היישום, ועליה להיות מדרגית גם באופן צורה מסוימת כדי לעמוד בדרישות של היישום לטווח הקרוב ובעתיד.
הביצועים: מערכות אחסון אמורות להיות מסוגלות לטפל בציפיות של היישומים לגבי הביצועים. ניתן ל חלק זאת באופן נרחב לדרישות הבאות:
- השהיה: המערכת אמורה להגיב לבקשות במסגרת זמן צפויה מסוימת. במערכות בקנה מידה של אינטרנט, דרישה זו חשובה למדי כפי שהיא מתייחסת ישירות לחוויה של המשתמש.
- רוחב: המערכת אמורה להיות היכולת להעביר נתונים בקצב מסוים. עבור אפליקציות שמקורן בהזנות רצינות של נתונים (כגון וידאו), זהו מדד חיוני.
Access: ניתן להשתמש בתבניות המסוימת שבהן יישום ניגש לנתונים כדי לעצב וליישם מערכות אחסון יעילות. באופן ספציפי, התבניות הבאות מעניינות מעצבי מערכת אחסון:
- הצפיפות של: מתייחס לכמות הקטנה ביותר של נתונים שאוחזרו בפעולה אופיינית. טווח זה יכול להיות בין כמה בתים למגה-בתים מרובים, בהתאם לסוג היישום.
- תדירות הגישה: מתייחס לתדירות הגישה לנתונים מהמערכת. אם יש רכיבים מסוימים שניתן לגשת אליהם ללא הרף, הם מספקים דרכים למיטוב באמצעות טכניקות כגון אחסון במטמון.
- אזור הגישה: מתייחס למקומיות מרחבית ורכבית. דוגמה למקומיות היא המראה של רכיבי נתונים רחוקים כאשר הם מאוחזרים עבור היישום. ניתן לשקול את הרמה המיקרו-מקומית (כמה רחוקה ההפחתה באינדקס מערך במהלך כפל מטריצה) וברמת המאקרו (איזה מרכז נתונים ברחבי העולם אמור להגיב לבקשה של משתמש מסוים זה).
עמידות: פעולה זו מתייחסת לציפיות היישום לגבי האופן בו הנתונים במערכת צריכים להיות עקביים.
עמידות בפני תקלות: עמידות בפני תקלות היא מונח כללי המציין כמה תכונות של מערכת. ניתן לתאר אותם בתנאי הדרישות הבאות:
- מהימנות: אם פריט נתונים מסוים מדווח כפריט שנכתב על-ידי מערכת, האם ניתן תמיד לאחזר אותו בחזרה מהמערכת?
- זמינות: האם קיימת פרק זמן מסוים שבו המערכת אינה מגיבה לבקשות? באיזו תדירות זה קורה? האם האפליקציה שלי מושפעת מזה, ומה ניתן לעשות כדי למזער את ההשפעה של זמן ההקשה הזה?
- דיוק: עד כמה מדויקות התוצאות שהמערכת החזירה? זו עשויה להיראות שאלה טריוויאלית עבור מערכת פשוטה המורכבת מאחסון נתונים יחיד בלבד, אך אם מערכת מופצת עם עותקים מרובים של אותם נתונים, זו עשויה להיות בעיה משמעותית מאוד. אפליקציות מסוימות יכולות לטפל בנתונים מעט מיושים, אך אפליקציות אחרות דורשות תשובה מדויקת בכל פעם.
אבטחה: עד כמה הנתונים צריכים להיות מאובטחים כאשר הם מאוחסנים ולגשת אליהם על-ידי היישום? האם הוא מוגן מפני גישה בשוגג או זדונית ו/או שינוי ומחיקה? אילו סוגים של הגבלות גישה ניתן לכפות על משתמשים ויישומים הלגשת למערכת זו?
מוכחת: התהליך שבו ניתן לעקוב אחר מקור הנתונים ולתעד אותו, וכן את התנועה בין מערכות האחסון. עבור יישום, האם הפונקציונליות של היכולת לעקוב אחר כל המידע הדרוש? עבור יישומים מסוימים העוסקים בנתונים רגישים ו/או סודיים, זו דרישה.
דרישות אלה מכתיבות את עיצוב האפליקציות. אפליקציות הדורשות קיבולת גדולה או זקוקות למדרגיות לטווח הקרוב או לטווח הארוך צריכים להיות ארכיטקטים בהתאם. כפי שתראה במודול זה, מערכות אחסון הטפלות בכמויות גדולות של נתונים בדרך כלל איטיות או יקרות מדי מכדי להיכלל במערכת מונוליתית. מחשבים אלה מפוזרים בדרך כלל במחשבים מרובים.
דרישות ביצועים מחמירות מתורגמות בדרך כלל לבחירות עיצוב הכוללות אחסון במטמון או שכפול. מערכות כאלה מיועדות להשתמש בדפוסי הגישה כדי לקבוע אסטרטגיות מיטביות לשיפור הביצועים. עבור יישומים המשמשים לקוחות דרך האינטרנט, מרכזי נתונים מרובים עשויים להיות מעורבים כדי לספק ביצועים מהירים יותר חוויית משתמש טובה יותר על-ידי ניתוב מחדש של משתמשים לשרת הזמין הקרוב ביותר הכולל את הנתונים הדרושים.
כדי להשתמש בטכניקות מסוימות של שכפול או אחסון במטמון, על היישום להחליט איזו רמה או דיוק או רענן הוא זקוק עבור הנתונים שאוחזרו מהמערכת. יישומים מסוימים עשויים להיות בסדר אם הם מקבלים נתונים מיושים, אך יישומים אחרים דורשים את הנתונים המדויקים up-to-date. פעולה זו משפיעה על רמת העקביות שמערכת האחסון חייבת לספק ליישום.
הפניות
- גינסברג, ג'רמי ומובי, מתיו H ופטאל, ראג'אן S ו ברמר, ליאנט וסמוליןסקי, מארק ס' ו'מבריק', לארי (2009). זיהוי מגיפת שפעת באמצעות נתוני שאילתה של מנוע חיפוש טבע