מדוע מפתחים צריכים להשתמש במאגרי גרפים

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

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

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

השימוש במסד הנתונים הגרפי בהחלט גדל במהלך העשור האחרון מכיוון שחברות התחשבו בטכנולוגיות NoSQL אחרות ובביג דאטה. שוק מאגרי הגרפים העולמי נאמד ב -651 מיליון דולר בשנת 2018 וצפוי לגדול ל -3.73 מיליארד דולר בשנת 2026. אך טכנולוגיות רבות אחרות לניהול נתונים גדולים, כולל Hadoop, Spark ואחרים, צפו בצמיחה משמעותית הרבה יותר בפופולריות, באימוץ מיומנויות, ומקרי שימוש בייצור בהשוואה למאגרי גרפים. לשם השוואה, גודל שוק טכנולוגיית הביג דאטה נאמד בכ -36.8 מיליארד דולר בשנת 2018 וצפוי לגדול עד 104.3 מיליארד דולר עד 2026.

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

לימוד שפות השאילתות של מאגרי גרפים

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

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

שוחחתי עם ג'ים וובר, המדען הראשי ב- Neo4j, אחד ממאגרי הגרפים המוקמים הזמינים, על אופן בניית שאילתת חברים של חברים. מפתחים יכולים לבצע שאילתות על מאגרי גרפים של Neo4j באמצעות RDF (Resource Description Framework) ו- Gremlin, אך וובר אמר לי שיותר מ -90% מהלקוחות משתמשים ב- Cypher. כך נראית השאילתה ב- Cypher לחילוץ חברים וחברים של חברים:

MATCH (me:Person {name:'Rosa'})-[:FRIEND*1..2]->(f:Person)

WHERE me f

RETURN f

כך תבין שאילתה זו:

  • מצא לי את התבנית שבה יש צומת עם התווית Person ושם מאפיין: 'רוזה', וקשר את זה למשתנה 'אני'. השאילתה מציינת של- "לי" יש יחסי FRIEND יוצאים בעומק 1 או 2 לכל צומת אחר עם תווית Person, וקושרים התאמות אלה למשתנה "f."
  • ודא ש"אני "לא שווה" f ", כי אני חבר של החברים שלי!
  • החזירו את כל החברים והחברים של החברים

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

תכנון היררכיות גמישות עם בסיסי נתונים גרפיים

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

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

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

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

אפשרויות פריסת ענן מפחיתות את המורכבות התפעולית

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

לארגונים המתנסים במאגרי מידע גרפיים יש כעת כמה אפשרויות ענן. מהנדסים יכולים לפרוס את Neo4j ל- GCP, AWS, Azure, או למנף את Aura של Neo4j, בסיס נתונים כשירות. ל- TigerGraph יש ענן שמציע ערכות התחלה למקרי שימוש כגון 360 לקוחות, איתור הונאות, מנועי המלצה, ניתוח רשתות חברתיות וניתוח שרשרת האספקה. כמו כן, לספקי הענן הציבוריים יכולות מסדי נתונים של גרפים, כולל AWS Neptune, ממשק ה- API של Gremlin ב- CosmoDB של Azure, המקור הפתוח JanusGraph ב- GCP, או תכונות הגרף בשירותי מסד הנתונים של Cloud של אורקל.

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