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

I. GraphQL עבור גישה ל-RDF
ש-GraphQL טוען שהיא שפת הגישה האוניברסלית למסד הנתונים. ומה לגבי היכולת לגשת באמצעות GraphQL ל-RDF?
מחוץ לקופסה, הזדמנות זו ניתנת על ידי:
- stardog(, );
- מוצרי TopQuadrant (, ).
אם המאגר אינו מספק הזדמנות כזו, הוא מיושם באופן עצמאי על ידי כתיבת ה"resolver" המתאים (resolver). זה נעשה, למשל, בפרויקט הצרפתי . או שאתה כבר לא יכול לכתוב כלום, אלא פשוט לקחת .
מנקודת מבטו של חסיד אורתודוקסי של הרשת הסמנטית והנתונים המקושרים, כל זה כמובן עצוב, שכן נראה שהוא מיועד לאינטגרציות שנבנו סביב ממגורת הנתונים הבאה, ולא לפלטפורמות מתאימות (כמובן, אחסון RDF) .
ההתרשמות מהשוואת GraphQL עם SPARQL הן כפולות.
- מצד אחד, GraphQL נראה כמו קרוב משפחה רחוק של SPARQL: הוא פותר את הבעיות של בחירה מחדש ושאילתות מרובות האופייניות ל-REST - שבלעדיהן, כנראה, לא ניתן יהיה לשקול שפת שאילתה, לפחות עבור האינטרנט;
- מצד שני, התוכנית הנוקשה של GraphQL מטרידה. בהתאם, נראה שה"אינטרוספקטיביות" שלו מוגבלת מאוד בהשוואה לרפלקסיביות המלאה של RDF. ואין אנלוגי לנתיבי נכסים, אז אפילו לא מאוד ברור למה זה "גרף-".
II. מתאמים עבור MongoDB
מגמה משלימה לקודמתה.
- עכשיו בסטארדוג - בפרט, הכל באותו GraphQL - הגדר את התצוגה של נתוני MongoDB לגרפי RDF וירטואליים;
- לאחרונה, GraphDB הכנס לתוך קטעי SPARQL בשאילתת MongoDB.
אם מדברים בצורה רחבה יותר, על מתאמים למקורות JSON שמאפשרים פחות או יותר "בתנועה" לייצג את ה-JSON המאוחסן במקורות אלה כ-RDF, אז נוכל גם לזכור את הקיים במשך די הרבה זמן שניתן להתאים , לאפצ'י ג'נה.
אם נסכם את שתי המגמות הראשונות, אנו יכולים לומר שמאגרי RDF מפגינים מוכנות מלאה לאינטגרציה ותפקוד בתנאים של "אחסון מרובה" (התמדה רב-גלתית). זה ידוע, עם זאת, זה האחרון כבר מזמן יצא מהאופנה, ולהחליף אותו ריבוי מודלים. ומה לגבי ריבוי מודלים בעולם אחסון RDF?
בקיצור, אין מצב. אני רוצה להקדיש מאמר נפרד לנושא של DBMS מרובה מודלים, אך לעת עתה אתה יכול לראות שאין DBMS רב מודל "מבוסס" על מודל הגרף (RDF יכול להיחשב כווריאציה שלו) כעת. כמה מודלים מרובים קטנים - תמיכה על ידי אחסון RDF של מודל גרף גפ"מ חלופי - יידונו ב .
III. OLTP לעומת OLAP
עם זאת, אותו גרטנר שריבוי מודלים הוא תנאי בסיס בעיקרו עבורו חדרי ניתוח DBMS. זה מובן: במצב של "אחסון מרובה", הבעיות העיקריות מתעוררות בעסקאות.
אבל היכן בסולם OLTP-OLAP נמצאים מאגרי RDF? הייתי עונה כך: לא שם ולא כאן. כדי לציין למה הם מיועדים, יש צורך בקיצור שלישי כלשהו. כאופציה הייתי מציע OLIP - עיבוד אינטלקטואלי מקוון.
עם זאת, עדיין:
- מנגנוני האינטגרציה המיושמים ב- GraphDB עם MongoDB הם לא הפחותים לעקוף בעיות ביצועים בכתיבה;
- Stardog הולך אפילו רחוק יותר לגמרי מנוע, שוב במטרה לשפר את ביצועי הכתיבה.
עכשיו הרשו לי להציג שחקן חדש בשוק. מיוצרי IBM Netezza ו-Amazon Redshift - . בתחילת הכתבה הוצבה תמונה מתוך פרסומת למוצר המבוססת עליו. AnzoGraph ממצב את עצמו כפתרון GOLAP. איך אתה אוהב SPARQL עם פונקציות חלון? —
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }IV. RocksDB
כבר למעלה להכרזה על Stardog 7 Beta, שאמרה ש-Stardog עומדת להשתמש ב-RocksDB כמערכת אחסון בסיסית - אחסון מפתח-ערך, המזלג של פייסבוק של LevelDB של גוגל. למה כדאי לדבר על טרנד מסוים?
ראשית, אם לשפוט לפי , לא רק מאגרי RDF "מושתלים" ל- RocksDB. ישנם פרויקטים לשימוש ב-RocksDB כמנוע אחסון ב-ArangoDB, MongoDB, MySQL ו-MariaDB, Cassandra.
שנית, פרויקטים (כלומר, לא מוצרים) של הנושא המקביל נעשים על RocksDB.
לדוגמה, eBay משתמש ב- RocksDB ב עבור "גרף הידע" שלך. אגב, מצחיק לקרוא: שפת השאילתה התחילה כפורמט ביתי, אך לאחרונה היא עברה להיות הרבה יותר דומה ל-SPARQL. כמו בבדיחה: לא משנה כמה גרף ידע נעשה, אנחנו עדיין מקבלים RDF.
דוגמה נוספת - הופיעה לפני מספר חודשים . לפני הצגתו, היה צורך לגשת למידע ההיסטורי של ויקידאטה ל-API הרגיל של Mediawiki. הרבה אפשרי כעת ב-SPARQL טהור. "מתחת למכסה המנוע" יש גם RocksDB. אגב, WDHQS עשה את זה, זה נראה כמו האדם המעורב בייבוא Freebase לתוך גרף הידע של Google.
V. תמיכת גפ"מ
תן לי להזכיר לך את ההבדל העיקרי בין גרפי GPG לגרפי RDF.
ב-LPG ניתן לצרף מאפיינים סקלרים למופעי קצה, בעוד שב-RDF ניתן לצרף אותם רק ל"טיפוסים" קצה (אך לא רק מאפיינים סקלרים, אלא גם קישורים רגילים). מגבלה זו של RDF בהשוואה לגפ"מ איזושהי טכניקת דוגמנות. קשה יותר להתגבר על המגבלות של גפ"מ בהשוואה ל-RDF, אבל גרפי גפ"מ דומים יותר לתמונות מספר הלימוד של הררי מאשר לגרפי RDF, אז אנשים רוצים אותם.
ברור, המשימה של "תמיכה בגפ"מ" מתחלקת לשני חלקים:
- ביצוע שינויים במודל RDF המאפשרים לדמות בו מבני גפ"מ;
- ביצוע שינויים בשפת השאילתות RDF המאפשרים גישה לנתונים במודל שונה זה, או יישום היכולת לבצע שאילתות למודל זה בשפות שאילתות LPG פופולריות.
V.1. מודל נתונים
יש כאן כמה גישות אפשריות.
V.1.1. נכס יחיד
הגישה המילולית ביותר להרמוניה של RDF ו-LPG היא כנראה :
- במקום, למשל, הפרדיקט
:isMarriedToנעשה שימוש בפרדיקטים:isMarriedTo1,:isMarriedTo2ושנאים. ד. - הפרדיקטים הללו הופכים לאחר מכן לנושאים של שלישיות חדשות:
:isMarriedTo1 :since "2013-09-13"^^xsd:dateוכו ' - הקשר של מקרים אלה של פרדיקטים עם פרדיקט משותף נוצר על ידי שלישיות של הצורה
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - זה ברור
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, אבל שקול למה אתה לא צריך פשוט לכתוב:isMarriedTo1 rdf:type :isMarriedTo.
המשימה של "תמיכה ב-LPG" נפתרת כאן ברמת RDFS. החלטה כזו מחייבת הכללה ברלוונטי . ייתכן שיידרשו שינויים מסוימים ממאגרי RDF התומכים בהצמדת השלכות, אך לעת עתה, ניתן לחשוב על Singleton Property כאל עוד טכניקת מודלים.
V.1.2. התיקון נעשה נכון
גישות נאיביות פחות נובעות מההבנה שמופעי נכסים מיוצרים בצורה מושלמת על ידי שלישיות. על ידי היכולת לדבר על שלישיות, נוכל לדבר גם על מקרים של רכוש.
המוצק ביותר מבין הגישות הללו הוא aka RDR, במעיים של Blazegraph. זה מההתחלה עבורי ועבור AnzoGraph. מוצקות הגישה נקבעת על ידי העובדה שבמסגרתה שינויים מתאימים ב . הנקודה, לעומת זאת, פשוטה ביותר. בסריאליזציה של RDF Turtle, כעת אתה יכול לכתוב משהו כזה:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .V.1.3. גישות אחרות
אתה לא יכול להתעסק בסמנטיקה פורמלית, אלא פשוט לקחת בחשבון שלשלישיות יש כמה מזהים, שהם, כמובן, URIs, ולהרכיב שלישיות חדשות עם URIs אלה. כל מה שנותר הוא לתת גישה ל-URI הללו ב-SPARQL. כך כלב כוכבים.
באלגרוגרפיה בדרך ביניים. ידוע כי המזהים של שלישיות באלגרוגרפיה , אך כאשר מיושמות תכונות משולשות, הן אינן בולטות. עם זאת, אפילו סמנטיקה פורמלית רחוקה מאוד. יש לציין כי תכונות שלישיה אינן URI, והערכים של תכונות אלו יכולים להיות רק מילוליים. חובבי גפ"מ מקבלים בדיוק את מה שהם רצו. בפורמט NQX שהומצא במיוחד, דוגמה דומה לזו שלמעלה עבור RDF* נראית כך:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. שפות שאילתות
לאחר שתמכת ב-LPG בצורה כזו או אחרת ברמת הדגם, אתה צריך לאפשר שאילתות נתונים במודל כזה.
- תומך בשאילתות Blazegraph for RDF* и . שאילתת SPARQL* נראית כך:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }- Anzograph גם תומך והוא הולך לתמוך , שפת השאילתה ב-Neo4j.
- סטארדוג שומרת על שלו SPARQL ו גרמלין. אתה יכול לקבל את URI של שלישייה ו"מטה-מידע" ב-SPARQL באמצעות משהו כזה:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- אלגרגרף תומך גם בעצמו SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }אגב, GraphDB תמך ב-Tinkerpop/Gremlin בבת אחת מבלי לתמוך ב-LPG, אבל זה הפסיק בגרסה 8.0 או 8.1.
VI. הידוק רישיונות
לאחרונה לא תוספו נתונים לצומת שבין ערכות "טריפלסטור של בחירה" ו"טריפלסטור קוד פתוח". מאגרי RDF חדשים בקוד פתוח רחוקים מלהיות בחירה טובה לשימוש יומיומי, וקוד המקור של מאגרי RDF חדשים שהיינו רוצים להשתמש בהם (אותו AnzoGraph) סגור. במקום זאת, נוכל אפילו לדבר על חיסורים...
כמובן, הקוד הפתוח בעבר אינו סגור, אך חלק ממאגרי הקוד הפתוח כבר לא נחשבים בהדרגה ראויים לבחירה. וירטואוז, שיש לה מהדורת קוד פתוח, לדעתי, טובעת בבאגים. Blazegraph נקנה על ידי AWS והיווה את הבסיס לאמזון נפטון; כעת לא ברור אם תהיה עוד שחרור אחד לפחות. רק ג'נה נשארה...
אם הקוד הפתוח לא מאוד חשוב, אבל אתה רק רוצה לנסות, אז הכל גם פחות ורוד מבעבר. לדוגמה:
- סטארדוג להפיץ את הגרסה החינמית (עם זאת, תקופת הניסיון של הרגילה הוכפלה);
- в , שם בעבר ניתן היה לבחור תוכנית בסיסית בחינם, השעתה רישומי משתמשים חדשים.
באופן כללי, החלל הופך להיות יותר ויותר בלתי נגיש עבור הדיוט IT רגיל, הפיתוח שלו הופך לנחלת התאגידים.
מקור: www.habr.com
