תכונות של עיצוב מודל נתונים עבור NoSQL

מבוא

"אתה צריך לרוץ הכי מהר שאתה יכול רק כדי להישאר במקום,
וכדי להגיע למקום, אתה צריך לרוץ לפחות פי שניים מהר יותר!"
(ג) עליסה בארץ הפלאות

לפני זמן מה התבקשתי לתת הרצאה אנליסטים החברה שלנו בנושא עיצוב מודלים של נתונים, כי כשיושבים על פרויקטים במשך זמן רב (לפעמים מספר שנים) אנחנו מאבדים את המתרחש סביבנו בעולם טכנולוגיות ה-IT. בחברה שלנו (זה קורה) הרבה פרויקטים לא משתמשים במסדי נתונים של NoSQL (לפחות בינתיים), אז בהרצאה שלי הקדשתי להם תשומת לב בנפרד באמצעות הדוגמה של HBase וניסיתי לכוון את הצגת החומר לאלו שמעולם לא השתמשו בהם עבדו. במיוחד, הדגמתי כמה מהתכונות של עיצוב מודל נתונים באמצעות דוגמה שקראתי לפני מספר שנים במאמר "מבוא ל-HB ase Schema Design" מאת Amandeep Khurana. בעת ניתוח דוגמאות, השוויתי מספר אפשרויות לפתרון אותה בעיה על מנת להעביר טוב יותר את הרעיונות המרכזיים לקהל.

לאחרונה, "יש מה לעשות", שאלתי את עצמי את השאלה (סוף השבוע הארוך של מאי בהסגר תורם לכך במיוחד), עד כמה יתאימו חישובים תיאורטיים לפרקטיקה? למעשה, כך נולד הרעיון למאמר זה. מפתח שעובד עם NoSQL כבר מספר ימים עלול שלא ללמוד ממנו שום דבר חדש (ולכן עלול לדלג מיד על חצי המאמר). אלא בשביל אנליסטיםעבור אלה שעדיין לא עבדו בשיתוף פעולה הדוק עם NoSQL, אני חושב שזה יהיה שימושי להשגת הבנה בסיסית של התכונות של עיצוב מודלים של נתונים עבור HBase.

ניתוח דוגמה

לדעתי, לפני שמתחילים להשתמש בבסיסי נתונים של NoSQL, צריך לחשוב היטב ולשקול את היתרונות והחסרונות. לעתים קרובות ניתן לפתור את הבעיה באמצעות DBMS יחסים מסורתיים. לכן, עדיף לא להשתמש ב-NoSQL ללא סיבות משמעותיות. אם בכל זאת החלטתם להשתמש במסד נתונים NoSQL, אז כדאי לקחת בחשבון שגישות העיצוב כאן שונות במקצת. במיוחד חלקם עשויים להיות יוצאי דופן עבור מי שעסק בעבר רק ב-DBMSs יחסי (לפי התצפיות שלי). לכן, בעולם ה"יחסי", אנחנו בדרך כלל מתחילים במודלים של תחום הבעיה, ורק אז, במידת הצורך, מנטרלים את המודל. ב-NoSQL אנחנו צריך לקחת בחשבון מיד את התרחישים הצפויים לעבודה עם נתונים ובהתחלה לבטל את הנתונים. בנוסף, ישנם מספר הבדלים נוספים, עליהם יידונו להלן.

הבה נשקול את הבעיה ה"סינטטית" הבאה, איתה נמשיך לעבוד:

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

• ענה על השאלה האם משתמש א' קורא את משתמש ב' (דפוס קריאה)
• אפשר הוספה/הסרה של חיבורים במקרה של הרשמה/ביטול מנוי של משתמש א' ממשתמש ב' (תבנית שינוי נתונים)

כמובן, ישנן אפשרויות רבות לפתרון הבעיה. במסד נתונים רלציוני רגיל, סביר להניח שהיינו פשוט מכינים טבלת מערכות יחסים (אולי מאופיינת אם, למשל, עלינו לאחסן קבוצת משתמשים: משפחה, עבודה וכו', הכוללת את ה"חבר") הזה, וכדי לבצע אופטימיזציה מהירות הגישה תוסיף אינדקסים/חלוקה למחיצות. סביר להניח שהשולחן הגמר ייראה בערך כך:

USER_ID
חבר_מזהה

וסיה
פטיה

וסיה
Оля

להלן, לצורך הבהירות והבנה טובה יותר, אציין שמות במקום תעודות זהות

במקרה של HBase, אנו יודעים ש:

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

לכן, אנו נאלצים להשתמש במזהה המשתמש כמפתח. והמחשבה הראשונה שלי על הנושא "היכן ואיך לאחסן תעודות זהות של חברים?" אולי רעיון לאחסן אותם בטורים. האפשרות הברורה וה"נאיבית" הזו תיראה משהו כזה (בוא נקרא לזה אפשרות 1 (ברירת מחדל)לעיון נוסף):

RowKey
רמקולים

וסיה
1: פטיה
2: אוליה
3: דאשה

פטיה
1: מאשה
2: ואסיה

כאן, כל שורה מתאימה למשתמש רשת אחד. לעמודות יש שמות: 1, 2, ... - לפי מספר החברים, ובעמודות שמורים תעודות הזהות של החברים. חשוב לציין שלכל שורה יהיה מספר שונה של עמודות. בדוגמה באיור למעלה, בשורה אחת יש שלוש עמודות (1, 2 ו-3), ובשנייה יש רק שתיים (1 ו-2) - כאן השתמשנו בעצמנו בשני מאפייני HBase שאין לבסיסי נתונים יחסיים:

• היכולת לשנות באופן דינמי את הרכב העמודות (הוסף חבר -> הוסף עמודה, הסרת חבר -> מחיקת עמודה)
• לשורות שונות עשויות להיות הרכב עמודות שונה

בואו נבדוק את המבנה שלנו לעמידה בדרישות המשימה:

• קריאת נתונים: כדי להבין אם Vasya מנוי לאוליה, נצטרך להחסיר את כל הקו על ידי המפתח RowKey = "Vasya" וממיין את ערכי העמודות עד ש"נפגוש" בהם Olya. או לחזור על הערכים של כל העמודות, "לא לפגוש" את אוליה ולהחזיר את התשובה False;
• עריכת נתונים: הוספת חבר: עבור משימה דומה אנחנו צריכים גם להחסיר את כל הקו באמצעות המקש RowKey = "Vasya" כדי לחשב את המספר הכולל של חבריו. אנחנו צריכים את המספר הכולל הזה של חברים כדי לקבוע את מספר העמודה שבה אנחנו צריכים לרשום את תעודת הזהות של החבר החדש.
• שינוי נתונים: מחיקת חבר:
  • צריך להחסיר את כל הקו על ידי המקש RowKey = "Vasya" ומיון בין העמודות על מנת למצוא את זו שבה רשום החבר שיימחק;
  • לאחר מכן, לאחר מחיקת חבר, עלינו "להעביר" את כל הנתונים לעמודה אחת כדי לא לקבל "פערים" במספור שלהם.

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

• קריאת נתונים: יש צורך להחסיר את כל השורה ולחזור על כל העמודות שלה בגבול. המשמעות היא שהאומדן העליון של העלויות יהיה בערך O(n)
• עריכת נתונים: הוספת חבר: כדי לקבוע את מספר החברים, עליך לעבור על כל העמודות של השורה, ולאחר מכן להוסיף עמודה חדשה => O(n)
• שינוי נתונים: מחיקת חבר:
  • בדומה להוספה - צריך לעבור על כל העמודות בגבול => O(n)
  • לאחר הסרת העמודות, עלינו "להזיז" אותם. אם אתה מיישם את ה"חזית", אז במגבלה תצטרך עד (n-1) פעולות. אבל כאן ובהמשך בחלק המעשי נשתמש בגישה אחרת, שתטמיע "פסאודו-שיפט" למספר קבוע של פעולות - כלומר, יושקע בה זמן קבוע, ללא קשר ל-n. ניתן להזניח את הזמן הקבוע הזה (O(2) ליתר דיוק) בהשוואה ל-O(n). הגישה מומחשת באיור שלהלן: אנו פשוט מעתיקים את הנתונים מהעמודה "האחרונה" לזו שממנה אנו רוצים למחוק נתונים, ולאחר מכן מוחקים את העמודה האחרונה:
    

בסך הכל, בכל התרחישים קיבלנו מורכבות חישובית אסימפטוטית של O(n).
בטח כבר שמתם לב שכמעט תמיד אנחנו צריכים לקרוא את כל השורה מהמאגר, ובשני מקרים מתוך שלושה, רק כדי לעבור על כל העמודות ולחשב את סך החברים. לכן, כניסיון לאופטימיזציה, ניתן להוסיף עמודת "ספירה", המאחסנת את מספר החברים הכולל של כל משתמש ברשת. במקרה זה, איננו יכולים לקרוא את כל השורה כדי לחשב את המספר הכולל של חברים, אלא לקרוא רק עמודת "ספירה" אחת. העיקר לא לשכוח לעדכן "ספירה" בעת מניפולציה של נתונים. זֶה. אנחנו משתפרים אפשרות 2 (ספירה):

RowKey
רמקולים

וסיה
1: פטיה
2: אוליה
3: דאשה
ספירה: 3

פטיה
1: מאשה
2: ואסיה

ספירה: 2

בהשוואה לאופציה הראשונה:

• קריאת נתונים: כדי לקבל תשובה לשאלה "האם ואסיה קורא את אוליה?" שום דבר לא השתנה => O(n)
• עריכת נתונים: הוספת חבר: פישטנו את הכנסת חבר חדש, מכיוון שכעת אין צורך לקרוא את כל השורה ולחזור על העמודות שלה, אלא רק לקבל את הערך של העמודה "ספירה" וכו'. קבע מיד את מספר העמודה כדי להוסיף חבר חדש. זה מוביל להפחתה במורכבות החישובית ל-O(1)
• שינוי נתונים: מחיקת חבר: בעת מחיקת חבר, נוכל להשתמש בעמודה זו גם כדי להפחית את מספר פעולות ה-I/O בעת "הזזת" הנתונים תא אחד שמאלה. אבל הצורך לחזור על העמודות כדי למצוא את זה שצריך למחוק עדיין נשאר, אז => O(n)
• מצד שני, עכשיו כשמעדכנים נתונים אנחנו צריכים לעדכן את עמודת ה"ספירה" כל פעם, אבל זה לוקח זמן קבוע, שניתן להזניח במסגרת של סמלי O

באופן כללי, אפשרות 2 נראית קצת יותר אופטימלית, אבל היא יותר כמו "אבולוציה במקום מהפכה". כדי לעשות "מהפכה" נצטרך אפשרות 3 (קול).
בואו נהפוך הכל "על הפוך": אנחנו נמנה שם עמודה מזהה משתמש! מה שיכתוב בעמודה עצמה כבר לא חשוב לנו, שיהיה המספר 1 (באופן כללי אפשר לאחסן שם דברים שימושיים, למשל קבוצת "משפחה/חברים/וכו'"). גישה זו עשויה להפתיע את "הדיוט" הלא מוכן, שאין לו ניסיון קודם בעבודה עם מסדי נתונים של NoSQL, אבל דווקא הגישה הזו מאפשרת לך להשתמש בפוטנציאל של HBase במשימה הזו בצורה הרבה יותר יעילה:

RowKey
רמקולים

וסיה
פטיה: 1
אוליה: 1
דאשה: 1

פטיה
מאשה: 1
ואסיה: 1

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

• קריאת נתונים: כדי לענות על השאלה אם ואסיה מנוי לאוליה, מספיק לקרוא טור אחד "אוליה": אם הוא קיים, אז התשובה היא אמת, אם לא - לא נכון => O(1)
• עריכת נתונים: הוספת חבר: הוספת חבר: פשוט הוסף עמודה חדשה "מזהה חבר" => O(1)
• שינוי נתונים: מחיקת חבר: פשוט הסר את העמודה מזהה חבר => O(1)

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

אתה יכול להיות מבולבל וללכת עוד קצת בדרך של אופטימיזציה של ביצועים והפחתת פעולות I/O בעת גישה למסד הנתונים. מה אם אחסנו את פרטי הקשר המלא ישירות במקש השורה עצמו? כלומר, להפוך את המפתח לרכב כמו userID.friendID? במקרה זה, אנחנו אפילו לא צריכים לקרוא את עמודות השורה בכלל (אפשרות 4 (שורה)):

RowKey
רמקולים

Vasya.Petya
פטיה: 1

Vasya.Olya
אוליה: 1

ואסיה.דאשה
דאשה: 1

פטיה.מאשה
מאשה: 1

Petya.Vasya
ואסיה: 1

ברור שההערכה של כל תרחישי מניפולציית הנתונים במבנה כזה, כמו בגרסה הקודמת, תהיה O(1). ההבדל עם אפשרות 3 יהיה אך ורק ביעילות פעולות ה-I/O במסד הנתונים.

ובכן, ה"קידה" האחרונה. קל לראות שבאופציה 4, למפתח השורה יהיה אורך משתנה, מה שעשוי להשפיע על הביצועים (כאן אנו זוכרים ש-HBase מאחסן נתונים כסט של בתים ושורות בטבלאות ממוינות לפי מפתח). בנוסף יש לנו מפריד שאולי צריך לטפל בו בתרחישים מסוימים. כדי לבטל את ההשפעה הזו, אתה יכול להשתמש ב-hash מ-userID ו-friendID, ומכיוון שלשני הגיבובים יהיה אורך קבוע, אתה יכול פשוט לשרשר אותם, ללא מפריד. ואז הנתונים בטבלה ייראו כך (אפשרות 5 (hash)):

RowKey
רמקולים

dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
פטיה: 1

dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
אוליה: 1

dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
דאשה: 1

1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
מאשה: 1

1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
ואסיה: 1

ברור שהמורכבות האלגוריתמית של עבודה עם מבנה כזה בתרחישים שאנו שוקלים תהיה זהה לזו של אפשרות 4 - כלומר O(1).
בסך הכל, בואו נסכם את כל ההערכות שלנו לגבי מורכבות חישובית בטבלה אחת:

הוספת חבר
בודק חבר
הסרת חבר

אפשרות 1 (ברירת מחדל)
O (n)
O (n)
O (n)

אפשרות 2 (ספירה)
O (1)
O (n)
O (n)

אפשרות 3 (עמודה)
O (1)
O (1)
O (1)

אפשרות 4 (שורה)
O (1)
O (1)
O (1)

אפשרות 5 (hash)
O (1)
O (1)
O (1)

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

הכנת הניסוי

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

• הוספת חבר חדש אחד
• בדיקה אם משתמש א' הוא חבר של משתמש ב'
• הסרת חבר אחד

לפיכך, בהתחשב בדרישות המפורטות בהצהרה הראשונית, תרחיש האימות מופיע כדלקמן:

• רישום נתונים. צור באופן אקראי רשת ראשונית בגודל n. כדי להתקרב ל"עולם האמיתי", מספר החברים שיש לכל משתמש הוא גם משתנה אקראי. מדוד את הזמן שבמהלכו "האפליקציה המותנית" שלנו כותבת את כל הנתונים שנוצרו ל-HBase. לאחר מכן חלקו את הזמן המתקבל במספר הכולל של חברים שנוספו - כך נקבל את הזמן הממוצע עבור "פעולה עסקית" אחת
• קריאת נתונים. עבור כל משתמש, צור רשימה של "אישים" עבורם אתה צריך לקבל תשובה אם המשתמש מנוי אליהם או לא. אורך הרשימה = בערך מספר החברים של המשתמש, ולמחצית מהחברים המסומנים התשובה צריכה להיות "כן", ולחצי השני - "לא". הבדיקה מתבצעת בסדר כזה שהתשובות "כן" ו"לא" מתחלפות (כלומר, בכל מקרה שני נצטרך לעבור על כל עמודות השורה לאפשרויות 1 ו-2). לאחר מכן, זמן ההקרנה הכולל מחולק במספר החברים שנבדקו כדי לקבל את זמן ההקרנה הממוצע לכל נבדק.
• מחיקת נתונים. הסר את כל החברים מהמשתמש. יתרה מכך, סדר המחיקה הוא אקראי (כלומר, אנו "מערבבים" את הרשימה המקורית ששימשה לרישום הנתונים). לאחר מכן, זמן ההמחאה הכולל מחולק במספר החברים שהוסרו כדי לקבל את הזמן הממוצע לכל צ'ק.

יש להפעיל את התרחישים עבור כל אחת מ-5 אפשרויות מודל הנתונים ועבור גדלים שונים של הרשת החברתית כדי לראות כיצד הזמן משתנה ככל שהוא גדל. בתוך n אחת, החיבורים ברשת ורשימת המשתמשים לבדיקה חייבים, כמובן, להיות זהים עבור כל 5 האפשרויות.
להבנה טובה יותר, להלן דוגמה לנתונים שנוצרו עבור n=5. ה"מחולל" הכתוב מייצר שלושה מילוני מזהה כפלט:

• הראשון מיועד להכנסה
• השני הוא לבדיקה
• שלישית - למחיקה

{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей

{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов

{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей

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

הניסוי בוצע על מחשב נייד שבו פועל Windows 10, כאשר HBase פעל במיכל אחד של Docker, ו-Python עם Jupyter Notebook פעל בשני. ל-Docker הוקצו 2 ליבות CPU ו-2 GB של זיכרון RAM. כל ההיגיון, כמו האמולציה של "האפליקציה המותנית" וה"צנרת" להפקת נתוני בדיקה ומדידה של זמן, נכתבה בפייתון. הספרייה שימשה לעבודה עם HBase happybase, כדי לחשב hashes (MD5) עבור אפשרות 5 - hashlib

בהתחשב בכוח המחשוב של מחשב נייד מסוים, השקה עבור n = 10, 30, … נבחרה בניסוי. 170 - כאשר זמן הפעולה הכולל של מחזור הבדיקה המלא (כל התרחישים עבור כל האפשרויות עבור כל n) היה אפילו פחות או יותר סביר והולם במהלך מסיבת תה אחת (בממוצע 15 דקות).

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

תוצאת הניסוי

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

אפשרויות 3-5, כצפוי, מציגות זמן כמעט קבוע של "עסקה עסקית", שאינה תלויה בצמיחת גודל הרשת ובהבדל בלתי מובחן בביצועים.
אפשרות 2 מציגה גם ביצועים קבועים, אך מעט גרועים יותר, כמעט בדיוק פי 2 ביחס לאפשרויות 3-5. וזה לא יכול אלא לשמוח, מכיוון שזה מתאם עם התיאוריה - בגרסה זו מספר פעולות ה-I/O מ/אל HBase גדול בדיוק פי 2. זה יכול לשמש ראיה עקיפה לכך שספסל הבדיקה שלנו, באופן עקרוני, מספק דיוק טוב.
גם אפשרות 1, כצפוי, מתבררת כאיטית ביותר ומדגימה עלייה ליניארית בזמן המושקע בהוספת זה לגודל הרשת.
כעת נסתכל על תוצאות הבדיקה השנייה.

אפשרויות 3-5 שוב מתנהגות כמצופה - זמן קבוע, ללא תלות בגודל הרשת. אפשרויות 1 ו-2 מדגימות עלייה ליניארית בזמן ככל שגודל הרשת גדל וביצועים דומים. יתרה מכך, אפשרות 2 מתבררת כמעט איטית יותר - ככל הנראה בשל הצורך בהגהה ועיבוד של עמודת ה"ספירה" הנוספת, אשר הופכת בולטת יותר ככל ש-n גדל. אבל עדיין אמנע מהסקת מסקנות כלשהן, שכן הדיוק של השוואה זו נמוך יחסית. בנוסף, היחסים הללו (איזו אפשרות, 1 או 2, מהירה יותר) השתנו מריצה לריצה (תוך שמירה על אופי התלות ו"הולכת צוואר וצוואר").

ובכן, הגרף האחרון הוא תוצאה של בדיקת הסרה.

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

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

מסקנות כלליות של הניסוי:

• אפשרויות 3-5 מדגימות יעילות רבה יותר כשהן מנצלות את היתרונות של HBase; יתר על כן, הביצועים שלהם שונים זה מזה בקבוע ואינם תלויים בגודל הרשת.
• ההבדל בין אפשרויות 4 ו-5 לא נרשם. אבל זה לא אומר שאסור להשתמש באפשרות 5. סביר להניח שהתרחיש הניסוי בו נעשה שימוש, תוך התחשבות במאפייני הביצועים של ספסל הבדיקה, לא אפשר את זיהויו.
• אופי הגידול בזמן הדרוש לביצוע "פעולות עסקיות" עם נתונים אישר בדרך כלל את החישובים התיאורטיים שהושגו קודם לכן עבור כל האפשרויות.

אפילוג

אין לראות בניסויים הגסים שבוצעו כאמת מוחלטת. ישנם גורמים רבים שלא נלקחו בחשבון ועיוותו את התוצאות (תנודות אלו ניכרות במיוחד בגרפים עם גודל רשת קטן). למשל, מהירות החסכון, המשמשת את happybase, נפח ושיטת יישום ההיגיון שכתבתי ב-Python (איני יכול לטעון שהקוד נכתב בצורה אופטימלית וביעילות השתמש ביכולות של כל הרכיבים), אולי התכונות של מטמון HBase, פעילות ברקע של Windows 10 במחשב הנייד שלי וכו'. באופן כללי, אנו יכולים להניח שכל החישובים התיאורטיים הוכיחו בניסוי את תקפותם. ובכן, או לפחות לא ניתן היה להפריך אותם ב"מתקפה חזיתית" כזו.

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

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

מקור: www.habr.com