ארכיטקטורת זיכרון לשירותי אינטרנט: יסודות ועקרונות טכנולוגיים

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

הודות לארכיטקטורה שלו, In-Memory מאיץ את הגישה לנתונים פי כמה, ולפעמים אפילו בסדרי גודל, מהר יותר. לדוגמה, אנליסטים של בנקים רוצים לראות באפליקציה אנליטית דוח על הלוואות שהונפקו בדינמיקה לפי יום עבור השנה האחרונה. תהליך זה ייקח דקות ב-DBMS קלאסי, אך עם In-Memory הוא יופיע כמעט מיד. הסיבה לכך היא שהגישה מאפשרת לך לשמור הרבה יותר מידע במטמון והוא מאוחסן ב-RAM "בהישג יד". האפליקציה אינה צריכה לבקש נתונים מהכונן הקשיח, שזמינותם מוגבלת על ידי מהירות הרשת והדיסק.

אילו אפשרויות נוספות זמינות עם In-Memory ואיזו סוג של גישה זו? ולדימיר פליגין - מהנדס ב-GridGain. חומר סקירה זה יהיה שימושי למפתחי קצה עורפי של אפליקציות אינטרנט שלא עבדו עם In-Memory ורוצים לנסות, או מתעניינים במגמות מודרניות בפיתוח תוכנה ועיצוב ארכיטקטורה.

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

מי משתמש ב-In-Memory וכיצד

In-Memory משמש לרוב כאשר נדרשת אינטראקציה מהירה של המשתמש או עיבוד של כמויות גדולות של נתונים.

• בנקים השתמש ב-In-Memory, למשל, כדי לצמצם עיכובים כאשר לקוחות משתמשים ביישומים או כדי לנתח את הלקוח לפני הנפקת הלוואה.
• פינטק משתמש ב-In-Memory כדי לשפר את הביצועים של שירותים ויישומים עבור בנקים המבצעים מיקור חוץ של עיבוד וניתוח נתונים. 
• חברות ביטוח: לחישוב סיכונים, למשל, על ידי ניתוח נתוני לקוחות לאורך מספר שנים.
• חברות לוגיסטיקה. הם מעבדים נתונים רבים, למשל, כדי לחשב מסלולים אופטימליים להובלת מטענים ונוסעים עם אלפי פרמטרים, ולעקוב אחר מצב המשלוחים.
• קמעונאות. פתרונות In-Memory עוזרים לתת שירות מהיר יותר ללקוחות ולעבד כמויות גדולות של מידע: משלוחים, חשבוניות, עסקאות, נוכחות של אלפי סחורות במחסנים והכנת דוחות אנליטיים.
• В IOT In-Memory מחליף מסדי נתונים מסורתיים.
• תרופות חברות משתמשות ב-In-Memory, למשל, כדי למיין שילובים של הרכבי תרופות. 

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

In-Memory כאחסון ראשי

אחד מלקוחותינו הוא ספק גדול של ציוד מדעי רפואי מארה"ב. הם משתמשים בפתרון In-Memory כאחסון הנתונים העיקרי שלהם. כל הנתונים מאוחסנים בדיסק, וקבוצת המשנה של הנתונים שנמצאת בשימוש פעיל נשמרת ב-RAM. שיטות הגישה לאחסון הן סטנדרטיות - GDBC (Generic Database Connector) ושפת שאילתות SQL.

ביחד זה נקרא מסד נתונים בזיכרון (IMDB) או אחסון ממוקד זיכרון. לסוג זה של פתרונות יש שמות רבים, אלה אינם היחידים. 

תכונות IMDB:

• הנתונים המאוחסנים ב-In-Memory והגישה אליהם מתבצעת באמצעות SQL זהים לגישות אחרות. הם מסונכרנים, רק דרך ההצגה, דרך ההתייחסות אליהם שונה. טרנזקציונליות עובדת בין נתונים.

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

IMDBs תומכים חלקית ב-ACID: Atomicity, Consistency, and Isolation. אבל הם לא תומכים ב"עמידות" - כשהחשמל כבוי, כל הנתונים אובדים. כדי לפתור את הבעיה, אתה יכול להשתמש בתמונות - "תצלום" של מסד הנתונים, בדומה לגיבוי מסד הנתונים בכונן קשיח, או להקליט עסקאות (יומנים) כדי לשחזר נתונים לאחר אתחול מחדש.

ליצירת יישומים חסיני תקלות

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

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

מה קורה כשאחד השרתים נכשל?

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

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

ניתן לפתור בעיה זו כמו לקוח אחר שלנו, ספק PASS גדול מארה"ב. הוא משתמש ב-In-Memory כדי לאסוף הפעלות אינטרנט. לשם כך, הוא מאחסן אותם לא מקומית, אלא מרכזית - באשכול In-Memory. במקרה זה, הפעלות זמינות הרבה יותר מהר מכיוון שהן כבר נמצאות ב-RAM.

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

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

עיבוד אנליטי עסקאות היברידי (HTAP)

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

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

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

שילוב פתרונות In-Memory

דרך פשוטה (יחסית) - לפתח הכל מאפס. אנו מאחסנים נתונים בדיסק ומאחסנים נתונים חמים בזיכרון. זה עוזר לשרוד אתחולים או הפסקות שרת.

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

אם לא ניתן לבנות הכל מאפס, אפשר לשלב In-Memory ב-כבר ארכיטקטורה קיימת. אבל לא כל פתרונות ה-In-Memory מתאימים לכך. ישנם שלושה תנאים מחייבים. פתרון ה-In-Memory חייב לתמוך ב:

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

אם כל שלושת התנאים מתקיימים, שילוב אפשרי. אנו מציבים את In-Memory Data Grid בין האפליקציה למסד הנתונים. כעת בקשות כתיבה יואצלו למסד הנתונים הבסיסי, ובקשות קריאה יואצלו למסד הנתונים הבסיסי אם הנתונים לא נמצאים במטמון.

אם גישה מהירה לנתונים ועיבודם חשובה לך, למשל, עבור ניתוח עסקי, תוכל לחשוב על הטמעת In-Memory. וליישום, אתה יכול להשתמש בשתי השיטות בעת תכנון ארכיטקטורה חדשה.

מקור: www.habr.com