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

1. גרמלין, ניאו או דטומיק

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

https://www.tocode.co.il/blog/2023-10-gremlin-first-steps

וכאן:

https://www.tocode.co.il/blog/2023-10-dsl-gremlin-queries

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

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

2. בעיה 1 - תיעוד

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

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

3. בעיה 2 - זיכרון

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

4. בעיה 3 - אינדקסים הם קריטיים

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

5. סיכום

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

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

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