גלובלים הם חרבות אוצר לאחסון נתונים. עצים. חלק 2

התחלה - ראה חלק 1.

3. גרסאות של מבנים בעת שימוש בגלובלים

למבנה כמו עץ ​​מסודר יש מקרים מיוחדים שונים. בואו ניקח בחשבון את אלה שיש להם ערך מעשי בעבודה עם גלובלים.

3.1 מקרה מיוחד 1. צומת אחד ללא ענפים

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

Set ^counter = 0  ; установка счётчика
Set id=$Increment(^counter) ;  атомарное инкрементирование

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

3.2 מקרה מיוחד 2. צומת אחד וענפים רבים

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

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

1. תווים מפרידים.

   Set ^t(id1) = "col11/col21/col31"
   Set ^t(id2) = "col12/col22/col32"

2. סכימה קשיחה, לפיה כל שדה תופס מספר קבוע מראש של בתים. כמו גם הופך ב-DB יחסי.
3. פונקציה מיוחדת של $LB (זמינה ב-Cache) המרכיבה מחרוזת ערכים.

   Set ^t(id1) = $LB("col11", "col21", "col31")
   Set ^t(id2) = $LB("col12", "col22", "col32")

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

בואו ניצור אינדקס גלובלי בעמודה הראשונה.

Set ^i("col11", id1) = 1
Set ^i("col12", id2) = 1

כעת, לחיפוש מהיר אחר מידע על העמודה הראשונה, עלינו להסתכל על הגלובלי ^i ומצא את המפתחות הראשיים (id) המתאימים לערך הרצוי של העמודה הראשונה.

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

TSTART
Set ^t(id1) = $LB("col11", "col21", "col31")
Set ^i("col11", id1) = 1
TCOMMIT

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

טבלאות כאלה יעבדו מהר כמו בבסיסי נתונים מסורתיים (או אפילו מהר יותר) אם הפונקציות של הוספת/עדכון/מחיקת שורות נכתבות ב-COS/M ומקובלות.בדקתי את ההצהרה הזו עם בדיקות עבור INSERT ו-SELECT בכמות גדולה בטבלה אחת בת שתי עמודות, כולל שימוש בפקודות TSTART ו-TCOMMIT (עסקאות).

לא בדקתי תרחישים מורכבים יותר עם גישה במקביל ועסקאות מקבילות.

ללא שימוש בעסקאות, שיעור ההוספה עמד על מיליון ערכים של 778 הוספות/שנייה.
ב-300 מיליון ערכים, 422 הוספות/שנייה.

בעת שימוש בטרנזקציות - 572 הוספות / שנייה עבור 082 מיליון הוספות. כל הפעולות בוצעו מקוד M מהידור.
כוננים קשיחים הם רגילים, לא SSD. RAID5 עם כתיבה חזרה. מעבד Phenom II 1100T.

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

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

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

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

3.3 מקרה מיוחד 3. עץ דו-מפלסי, לכל צומת ברמה השנייה יש מספר קבוע של ענפים

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

טבלאות על עץ דו-מפלסי לעומת על עץ ברמה אחת.

חסרונות
Pros

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

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

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

3.4 מקרה כללי. עצים ועצים מסודרים

כל מבנה נתונים שיכול להיות מיוצג כעץ מתאים לגלובלים.

3.4.1 אובייקטים עם אובייקטים משנה

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

דמיינו לעצמכם מסד נתונים של טבלאות SQL: "מטופל" ~ 100 שדות, "רפואה" - 000 שדות, "תרפיה" - 100 שדות, "סיבוכים" - 000 שדות וכו'. וכולי. או שאתה יכול ליצור מסד נתונים של אלפים רבים של טבלאות, כל אחת עבור סוג מסוים של מטופל (והן יכולות לחפוף!), טיפולים, תרופות ועוד אלפי טבלאות לקשרים בין הטבלאות הללו.

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

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

.
כמובן שב-SQL אפשר גם לחקות עץ עם כמה טבלאות בלבד (EAV, 1,2,3,4,5,6,7,8,9,10), אבל זה הרבה יותר מסובך ויהיה איטי יותר. למעשה, יהיה צורך לכתוב עבודה גלובלית על טבלאות ולהסתיר את כל העבודה עם טבלאות מתחת לשכבת הפשטה. זה לא נכון לחקות טכנולוגיה ברמה נמוכה יותר (גלובלים) באמצעות טכנולוגיה ברמה גבוהה יותר (SQL). לא ראוי.

זה לא סוד ששינוי סכימת הנתונים בטבלאות ענק (ALTER TABLE) יכול לקחת זמן הגון. MySQL, למשל, הופך את ALTER TABLE ADD|DROP COLUMN לעותק מלא של המידע מהטבלה הישנה לחדשה (מנועי MyISAM, InnoDB שנבדקו). מה יכול לתלות מסד נתונים עובד עם מיליארדי רשומות במשך ימים, אם לא שבועות.

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


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

ותן לי להזכיר לך, הגישה לכל אחד מהנכסים היא מיידית, מכיוון שבגלובל כל הנתיבים הם עץ B.

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

1. גודל מסמך. יחידת האחסון היא טקסט בפורמט JSON (ליתר דיוק BSON) בגודל מקסימלי של כ-16MB. ההגבלה נעשית בכוונה כדי שמסד הנתונים של JSON לא יאט בעת הניתוח אם מאוחסן בו מסמך JSON ענק, ואז הם ניגשים אליו לפי שדות. מסמך זה צריך להכיל את כל המידע על המטופל. כולנו יודעים כמה עבים יכולים להיות טבלאות מטופלים. גודל המפה המקסימלי של 16MB שם מיד קץ לחולים שמפת המחלות שלהם כוללת קבצי MRI, סריקות רנטגן ומחקרים נוספים. בענף אחד של הגלובלי, אתה יכול לקבל מידע על ג'יגה-בייט וטרה-בייט. עקרונית אפשר לשים לזה סוף, אבל אני אמשיך.
2. זמן ההכרה/שינוי/הסרה של תכונות חדשות בטבלת המטופל. מסד נתונים כזה צריך לקרוא את כל המפה לזיכרון (זו כמות גדולה!), לנתח BSON, להוסיף / לשנות / למחוק צומת חדש, לעדכן אינדקסים, לארוז ב-BSON, לשמור בדיסק. הגלובלי צריך רק להתייחס למאפיין ספציפי ולתפעל אותו.
3. גישה מהירה לנכסים בודדים. עם מאפיינים רבים במסמך והמבנה הרב-מפלסי שלו, הגישה למאפיינים בודדים תהיה מהירה יותר בשל העובדה שכל נתיב בגלובל הוא עץ B. ב-BSON, עליך לנתח את המסמך באופן ליניארי כדי למצוא את המאפיין הרצוי.

3.3.2 מערכים אסוציאטיביים

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

$a = array(
  "name" => "Vince Medvedev",
  "city" => "Moscow",
  "threatments" => array(
    "surgeries" => array("apedicectomy", "biopsy"),
    "radiation" => array("gamma", "x-rays"),
    "physiotherapy" => array("knee", "shoulder")
  )
);

3.3.3 מסמכים היררכיים: XML, JSON

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

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

<note id=5>
<to>Вася</to>
<from>Света</from>
<heading>Напоминание</heading>
<body>Позвони мне завтра!</body>
</note>

ב-COS, זה יתאים לקוד:

Set ^xml("note")="id=5"
Set ^xml("note","to")="Саша"
Set ^xml("note","from")="Света"
Set ^xml("note","heading")="Напоминание"
Set ^xml("note","body")="Позвони мне завтра!"

הערה: עבור XML, JSON, מערכים אסוציאטיביים, אתה יכול להמציא דרכים רבות ושונות להצגה בגלובליות. במקרה זה, לא שיקפנו את סדר התגים המקוננים בתג הערה. בעולם הגלובלי ^xml תגים מקוננים יוצגו בסדר אלפביתי. כדי לשקף בקפדנות את הסדר, אתה יכול להשתמש, למשל, במיפוי כזה:

ג'סון.
התמונה הראשונה מסעיף 3.3.1 מציגה השתקפות של מסמך JSON זה:

var document = {
  "name": "Vince Medvedev",
  "city": "Moscow",
  "threatments": {
    "surgeries": ["apedicectomy", "biopsy"],
    "radiation": ["gamma", "x-rays"],
    "physiotherapy": ["knee", "shoulder"]
  },
};

3.3.4 מבנים זהים המחוברים בקשרים היררכיים

דוגמאות: מבנה משרדי מכירות, מיקומם של אנשים במבנה MLM, בסיס הפתחים בשחמט.

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

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

4. מתי הכי מועיל להשתמש בגלובלים

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

מהירות
קלות עיבוד/הצגה של נתונים

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

1. אובייקטים/ישויות עם מספר עצום של מאפיינים/ישויות אופציונליות [ו/או מקוננות]
2. נתונים ללא סכמה. כאשר נכסים חדשים יכולים להופיע לעתים קרובות וישנים נעלמים.
3. אתה צריך ליצור מסד נתונים מותאם אישית.
4. בסיסי נתיבים ועצי החלטה. כשנוח לייצג שבילים כעץ.
5. הסרת מבנים היררכיים ללא שימוש ברקורסיה

הארכה "גלובלים הם חרבות אוצר לאחסון נתונים. מערכים דלילים. חלק 3".

כתב ויתור: מאמר זה וההערות שלי עליו הם דעתי ואינם מייצגים את העמדה הרשמית של InterSystems Corporation.

מקור: www.habr.com