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

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

תוכן

התמדה פוליגלוטית
רב דגם
DBMS ריבוי מודלים המבוססים על המודל ההתייחסותי
     מודל מסמך ב-MS SQL Server
     מודל גרף ב-MS SQL Server
DBMS ריבוי מודלים המבוססים על מודל המסמכים
     מודל יחסי ב-MarkLogic
     מודל גרף ב-MarkLogic
DBMS ריבוי דגמים "ללא דגם ראשי"
     ArangoDB
     אוריינט
     Azure CosmosDB
DBMS ריבוי מודלים המבוססים על מודל גרף?
מסקנה
ראיון

התמדה פוליגלוטית

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

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

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

ברור שלהיות משרת בגן חיות כזה זה לא קל.

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

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

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

ישנה עלייה משמעותית בעלות הבעלות הכוללת של המערכת (TCO). האם יש דרך לצאת מהמצב של "ריבוי אפשרויות אחסון"?

רב דגם

המונח "אחסון רב-תכליתי" נכנס לשימוש ב-2011. המודעות לבעיות הגישה והחיפוש אחר פתרון ארכו מספר שנים, ועד שנת 2015, מפי האנליסטים של גרטנר, התגבשה התשובה:

מ "מדריך שוק עבור NoSQL DBMSs - 2015»:
העתיד של DBMS, הארכיטקטורות שלהם ודרכי השימוש בהם הוא רב-מודלים.
מ "רבוע קסם עבור ODBMS - 2016»:
DBMS תפעוליים מובילים יציעו מודלים מרובים - יחסיים ולא יחסיים - כחלק מפלטפורמה אחת.

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

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

DBMS	דגם ראשוני	דגמים נוספים
אורקל	יחסי	גרף, מסמך
SQL MS	יחסי	גרף, מסמך
PostgreSQL	יחסי	גרף*, מסמך
MarkLogic	דוקומנטרי	גרף, יחסי
MongoDB	דוקומנטרי	ערך מפתח, גרף*
DataStax	עמודה רחבה	סרט תיעודי, גרף
Redis	ערך מפתח	סרט תיעודי, גרף*
ArangoDB	-	גרף, מסמך
אוריינט	-	גרף, מסמך, יחסי
Azure CosmosDB	-	גרף, מסמך, יחסי

הערות שולחן

כוכביות בטבלה מסמנות הצהרות המצריכות הסתייגויות:

ה- PostgreSQL DBMS אינו תומך במודל נתוני הגרף, אך מוצר זה כן תומך בו מבוסס על זה, כגון AgensGraph.
ביחס ל-MongoDB, נכון יותר לדבר על נוכחות של אופרטורים גרפים בשפת השאילתה ($lookup, $graphLookup) מאשר על תמיכה במודל הגרף, אם כי, כמובן, הצגתם דרשה כמה אופטימיזציות ברמת האחסון הפיזית בכיוון של תמיכה במודל הגרף.
ביחס לרדיס, אנחנו מתכוונים להרחבה RedisGraph.

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

DBMS ריבוי מודלים המבוססים על המודל ההתייחסותי

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

המחבר, לעומת זאת, מעדיף את הטמעת ריבוי מודלים ב-Microsoft SQL Server, שעל דוגמה זו תתואר תמיכת RDBMS עבור מודלים של מסמכים וגרפים.

מודל מסמך ב-MS SQL Server

כבר היו שני מאמרים מצוינים על Habré על האופן שבו MS SQL Server מיישם תמיכה במודל המסמכים; אני אסתפק בסיפור קצר ופרשנות:

הדרך לתמוך במודל המסמכים ב-MS SQL Server אופיינית למדי עבור DBMSs יחסי: מסמכי JSON מוצעים להיות מאוחסנים בשדות טקסט רגילים. התמיכה במודל המסמך היא לספק אופרטורים מיוחדים לנתח JSON זה:

JSON_VALUE כדי לחלץ ערכי תכונות סקלריות,
JSON_QUERY לחלץ מסמכי משנה.

הארגומנט השני של שני האופרטורים הוא ביטוי בתחביר דמוי JSONPath.

באופן מופשט, אנו יכולים לומר שמסמכים המאוחסנים בצורה זו אינם "ישויות מהשורה הראשונה" ב-DBMS יחסי, בניגוד ל-tuples. באופן ספציפי, ב-MS SQL Server אין כיום אינדקסים על שדות מסמכי JSON, מה שמקשה על הצטרפות לטבלאות באמצעות הערכים של שדות אלו ואף לבחור מסמכים באמצעות ערכים אלו. עם זאת, ניתן ליצור עמודה מחושבת לשדה כזה ואינדקס עליו.

בנוסף, MS SQL Server מספק את היכולת לבנות בנוחות מסמך JSON מתוכן הטבלאות באמצעות האופרטור FOR JSON PATH - אפשרות, במובן מסוים, הפוכה מהקודמת, אחסון קונבנציונלי. ברור שלא משנה כמה מהיר RDBMS, גישה זו סותרת את האידיאולוגיה של DBMS של מסמכים, אשר בעצם מאחסנות תשובות מוכנות לשאילתות פופולריות, ויכולות לפתור רק בעיות של קלות פיתוח, אך לא מהירות.

לבסוף, MS SQL Server מאפשר לך לפתור את הבעיה ההפוכה של בניית מסמכים: אתה יכול לפרק את JSON לטבלאות באמצעות OPENJSON. אם המסמך אינו שטוח לחלוטין, תצטרך להשתמש CROSS APPLY.

מודל גרף ב-MS SQL Server

התמיכה במודל הגרף (LPG) מיושמת במלואה גם ב-Microsoft SQL Server באופן צפוי: מוצע להשתמש בטבלאות מיוחדות לאחסון צמתים ולאחסון קצוות גרפים. טבלאות כאלה נוצרות באמצעות ביטויים CREATE TABLE AS NODE и CREATE TABLE AS EDGE בהתאמה.

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

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

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

CREATE TABLE Person (
  ID INTEGER NOT NULL,
  name VARCHAR(100)
) AS NODE;

CREATE TABLE Cafe (
  ID INTEGER NOT NULL, 
  name VARCHAR(100), 
) AS NODE;

CREATE TABLE likes (
  rating INTEGER
) AS EDGE;

CREATE TABLE friendOf
  AS EDGE;

ALTER TABLE likes
  ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);

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

SELECT Cafe.name
  FROM Person, likes, Cafe
  WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
  AND Person.name = 'John';

יתר על כן, די קשה שלא להשתמש בתבניות גרפים אלה בעת עבודה עם טבלאות כאלה, שכן בשאילתות SQL רגילות לפתרון בעיות דומות יהיה צורך לעשות מאמצים נוספים כדי להשיג מזהי צומת "גרף" של המערכת ($node_id, $from_id, $to_id; מאותה סיבה, שאילתות להכנסת נתונים אינן מוצגות כאן מכיוון שהן מסורבלות שלא לצורך).

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

DBMS ריבוי מודלים המבוססים על מודל המסמכים

בחלק זה, ברצוני להמחיש את היישום של ריבוי מודלים במסמכי DBMS באמצעות הדוגמה של הלא פופולרי שבהם, MongoDB (כאמור, יש לו רק אופרטורים גרפים מותנים $lookup и $graphLookup, לא עובד על אוספים מרוסקים), אלא באמצעות דוגמה של DBMS בוגר ו"ארגוני" יותר MarkLogic.

אז תן לאוסף להכיל קבוצה של מסמכי XML מהסוג הבא (MarkLogic מאפשר לך גם לאחסן מסמכי JSON):

<Person INN="631803299804">
  <name>John</name>
  <surname>Smith</surname>
</Person>

מודל יחסי ב-MarkLogic

ניתן ליצור תצוגה יחסית של אוסף מסמכים באמצעות תבנית תצוגה (תוכן של אלמנטים value בדוגמה למטה יכול להיות XPath שרירותי):

<template >
  <context>/Person</context>
  <rows>
    <row>
      <view-name>Person</view-name>
      <columns>
        <column>
          <name>SSN</name>
          <value>@SSN</value>
          <type>string</type>
        </column>
        <column>
          <name>name</name>
          <value>name</value>
        </column>
        <column>
          <name>surname</name>
          <value>surname</value>
        </column>
      </columns>
    </row>
  <rows>
</template>

אתה יכול לטפל בתצוגה שנוצרה באמצעות שאילתת SQL (לדוגמה, דרך ODBC):

SELECT name, surname FROM Person WHERE name="John"

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

מודל גרף ב-MarkLogic

עם תמיכה במודל הגרף (RDF), הכל בערך אותו דבר. שוב בעזרת העזרה תבנית תצוגה אתה יכול ליצור ייצוג RDF של אוסף מסמכים מהדוגמה שלמעלה:

<template >
  <context>/Person</context>
    <vars>
      <var>
        <name>PREFIX</name>
        <val>"http://example.org/example#"</val>
      </var>
    </vars>
  <triples>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || surname )</value></predicate>
      <object><value>xs:string( surname )</value></object>
    </triple>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || name )</value></predicate>
      <object><value>xs:string( name )</value></object>
    </triple>
  </triples>
  </template>

אתה יכול לטפל בגרף ה-RDF המתקבל באמצעות שאילתת SPARQL:

PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

בניגוד לזה ההתייחסותי, MarkLogic תומך במודל הגרף בשתי דרכים אחרות:

DBMS יכול להיות אחסון נפרד מן המניין של נתוני RDF (השלשות בו ייקראו הצליח בניגוד לאלה שתוארו לעיל חילוץ).
ניתן פשוט להכניס RDF בסריאליזציה מיוחדת למסמכי XML או JSON (ולאחר מכן ייקרא שלישייה לא מנוהל). זו כנראה חלופה למנגנונים idref וכו '

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

DBMS ריבוי דגמים "ללא דגם ראשי"

יש בשוק גם DBMS שממצבים עצמם כרב-מודלים בתחילה, ללא שום מודל ראשי שעבר בירושה. אלו כוללים ArangoDB, אוריינט (משנת 2018 חברת הפיתוח שייכת ל-SAP) ו CosmosDB (שירות כחלק מפלטפורמת הענן של Microsoft Azure).

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

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

כבר הייתה מאמר נפלא על ArangoDB ו-OrientDB ב-Habré: הצטרף לבסיסי נתונים של NoSQL.

ArangoDB

ArangoDB טוען לתמיכה במודל נתוני גרף.

הצמתים של גרף ב-ArangoDB הם מסמכים רגילים, והקצוות הם מסמכים מסוג מיוחד שיחד עם שדות מערכת רגילים יש (_key, _id, _rev) שדות מערכת _from и _to. מסמכים במסמכי DBMS משולבים באופן מסורתי לאוספים. אוספי מסמכים המייצגים קצוות נקראים אוספי קצה ב-ArangoDB. אגב, מסמכי איסוף קצוות הם גם מסמכים, אז קצוות ב-ArangoDB יכולים לשמש גם כצמתים.

נתונים גולמיים

תנו לנו אוסף persons, שהמסמכים שלו נראים כך:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Алиса"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Боб"  
  }
]

שיהיה גם אוסף cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Джон Донн"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Жан-Жак"
  }
]

ואז האוסף likes עשוי להיראות כך:

[
  {
    "_id" : "likes/1" ,
    "_key" : "1" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jd",
    "since" : 2010 
  },
  {
    "_id" : "likes/2" ,
    "_key" : "2" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jj",
    "since" : 2011 
  } ,
  {
    "_id" : "likes/3" ,
    "_key" : "3" ,
    "_from" : "persons/bob" ,
    "_to" : "cafes/jd",
    "since" : 2012 
  }
]

שאילתות ותוצאות

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

FOR p IN persons
  FOR c IN OUTBOUND p likes
  RETURN { person : p.name , likes : c.name }

בסגנון יחסי, שבו אנו "מחשבים" יחסים במקום מאחסנים אותם, ניתן לשכתב את השאילתה הזו כך (אגב, ללא האוסף likes יכול להסתדר בלי):

FOR p IN persons
  FOR l IN likes
  FILTER p._key == l._from
    FOR c IN cafes
    FILTER l._to == c._key
    RETURN { person : p.name , likes : c.name }

התוצאה בשני המקרים תהיה זהה:

[
  { "person" : "Алиса" , likes : "Жан-Жак" } ,
  { "person" : "Алиса" , likes : "Джон Донн" } ,
  { "person" : "Боб" , likes : "Джон Донн" }
]

עוד שאילתות ותוצאות

אם נראה שפורמט התוצאה שלמעלה אופייני יותר ל-DBMS יחסי מאשר ל-DBMS של מסמך, אתה יכול לנסות את השאילתה הזו (או שאתה יכול להשתמש COLLECT):

FOR p IN persons
  RETURN {
    person : p.name,
    likes : (
      FOR c IN OUTBOUND p likes
      RETURN c.name
    )
}

התוצאה תיראה כך:

[
  { "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"]  } ,
  { "person" : "Боб" , likes : ["Джон Донн"] }
]

אוריינט

הבסיס להטמעת מודל גרף על גבי מודל מסמך ב-OrientDB הוא הזדמנות לשדות מסמכים, בנוסף לערכים סקלרים סטנדרטיים פחות או יותר, יש גם ערכים מסוגים כגון LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. הערכים של סוגים אלה הם קישורים או אוספי קישורים מזהי מערכת מסמכים.

למזהה המסמך שהוקצה על ידי המערכת יש "משמעות פיזית", המציינת את מיקום הרשומה במסד הנתונים, והוא נראה בערך כך: @rid : #3:16. לפיכך, הערכים של מאפייני הייחוס הם באמת מצביעים (כמו במודל הגרף) ולא תנאי בחירה (כמו במודל ההתייחסותי).

כמו ArangoDB, קצוות ב-OrientDB מיוצגים כמסמכים נפרדים (אם כי אם לקצה אין מאפיינים משלו, ניתן ליצור אותו קל, וזה לא יתאים למסמך נפרד).

נתונים גולמיים

בפורמט קרוב ל פורמט dump מסד הנתונים של OrientDB, הנתונים מהדוגמה הקודמת עבור ArangoDB ייראו בערך כך:

[
     {
      "@type": "document",
      "@rid": "#11:0",
      "@class": "Person",
      "name": "Алиса",
      "out_likes": [
        "#30:1",
        "#30:2"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#12:0",
      "@class": "Person",
      "name": "Боб",
      "out_likes": [
        "#30:3"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#21:0",
      "@class": "Cafe",
      "name": "Жан-Жак",
      "in_likes": [
        "#30:2",
        "#30:3"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#22:0",
      "@class": "Cafe",
      "name": "Джон Донн",
      "in_likes": [
        "#30:1"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#30:1",
      "@class": "likes",
      "in": "#22:0",
      "out": "#11:0",
      "since": 1262286000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:2",
      "@class": "likes",
      "in": "#21:0",
      "out": "#11:0",
      "since": 1293822000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:3",
      "@class": "likes",
      "in": "#21:0",
      "out": "#12:0",
      "since": 1325354400000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    }
  ]

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

שאילתות ותוצאות

שאילתה דומה במטרה לשאילתה מהדוגמה עבור ArangoDB ב-OrientDB נראית כך:

SELECT name AS person_name, OUT('likes').name AS cafe_name
   FROM Person
   UNWIND cafe_name

התוצאה תתקבל בטופס הבא:

[
  { "person_name": "Алиса", "cafe_name": "Джон Донн" },
  { "person_name": "Алиса", "cafe_name": "Жан-Жак" },
  { "person_name": "Боб",  "cafe_name": "Жан-Жак" }
]

אם פורמט התוצאה נראה שוב "יחסי", עליך להסיר את הקו עם UNWIND():

[
  { "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
  { "person_name": "Боб",  "cafe_name": [ "Жан-Жак" ' }
]

ניתן לתאר את שפת השאילתה של OrientDB כ-SQL עם תוספות דמויות גרמלין. בגרסה 2.2 הופיע טופס בקשה דמוי סייפר, MATCH :

MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe}
RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name
GROUP BY person_name

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

Azure CosmosDB

במידה פחותה, מה שנאמר לעיל על ArangoDB ו-OrientDB חל על Azure CosmosDB. CosmosDB מספק את ממשקי ה-API הבאים לגישה לנתונים: SQL, MongoDB, Gremlin ו-Cassandra.

SQL API ו-MongoDB API משמשים לגישה לנתונים במודל המסמך. Gremlin API ו- Cassandra API - לגישה לנתונים בפורמטים של גרפים ועמודות, בהתאמה. הנתונים בכל הדגמים נשמרים בפורמט המודל הפנימי של CosmosDB: ARS ("רצף אטום-רשומה"), שגם הוא קרוב למסמך אחד.

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

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

DBMS ריבוי מודלים המבוססים על מודל גרף?

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

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

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

בעת יישום מודל מסמך על גבי מודל גרף, עליך לזכור, למשל, את הדברים הבאים:

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

קצת פרסום

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

אני מקווה שאתאר איך נראית התאמת דגמים ב- NitrosBase באחד מהמאמרים הבאים.

מסקנה

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

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

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

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.