DailyWatch मध्ये, आमचे "संबंधित व्हिडिओ" (related videos) पॅनेल एका साध्या SQLite क्वेरीपासून सुरू झाले. त्याने तीन टेबल्स एकत्र केले (join केले), ओव्हरलॅपिंग टॅग्स मोजले आणि एक रँक्ड लिस्ट परत केली. एका लहान कॅटलॉगसाठी ते पुरेसे होते. 'italian' आणि 'pasta' टॅग असलेला एखादा कुकिंग व्हिडिओ त्याच टॅग्सचे इतर व्हिडिओ समोर आणायचा आणि युजर्स त्यावर क्लिक करायचे. मेटाडेटा स्वच्छ असल्याने आणि लायब्ररी मर्यादित असल्याने आउटपुट संबंधित वाटायचे.

त्यानंतर कॅटलॉग वाढला आणि प्रेक्षकांच्या अपेक्षा बदलल्या. लोकांना केवळ सारख्याच टॅग्सचे अधिक व्हिडिओ नको होते. त्यांना असा क्लिप हवा होता जो ४० टक्के प्रेक्षक सध्याच्या व्हिडिओनंतर लगेच पाहतात. त्यांना तो विशिष्ट (niche) चॅनेल हवा होता जो त्याच रात्रीच्या पाहण्याच्या सत्रांमध्ये (viewing sessions) वारंवार समोर येत असे, जरी त्याच्या वर्णनात (description) सुरुवातीच्या व्हिडिओबद्दल काहीही उल्लेख नसला आणि त्याचे टॅग्सही कमी होते. हे वर्तणुकीचे नमुने (behavioral patterns) आहेत, मेटाडेटा मॅचेस नाहीत. SQLite मध्ये self-joins आणि recursive common table expressions चा गुंतागुंतीचा आणि न हाताळता येण्याजोगा पसारा न करता हे व्यक्त करणे शक्य नव्हते. आम्ही मॉडेल करण्याचा प्रयत्न केलेले प्रत्येक नवीन सिग्नल, मग तो co-viewership असो किंवा session adjacency, यामुळे लॅटन्सी (latency) आणि मानसिक ओझे (mental overhead) वाढत होता. आमच्याकडे ग्राफची समस्या होती जी रिलेशनल (relational) स्वरूपात बसवण्याचा प्रयत्न केला जात होता.

मी रेकमेंडेशन लेयर Apache AGE वर हलवले.

Apache AGE हे एक PostgreSQL extension आहे जे तुम्ही आधीच वापरत असलेल्या डेटाबेसमध्ये openCypher ग्राफ क्वेरीज जोडते. हा वेगळा सर्व्हर नाही. हा साइडकार (sidecar) देखील नाही. हे Postgres च्या आत चालते, याचा अर्थ असा की आम्ही एक समर्पित Neo4j क्लस्टर उभारल्याशिवाय किंवा पूर्णपणे नवीन ऑपरेशनल प्लेबुक शिकल्याशिवाय co-view नेटवर्क तयार करू शकलो. डेटाबेस रिलायबिलिटी इंजिनिअर नसलेल्या लहान टीमसाठी, हा फरक अत्यंत महत्त्वाचा होता.

नवीन डेटाबेसपेक्षा एक्सटेंशन का सरस आहे

तुमच्या स्टॅक मध्ये ग्राफ डेटाबेस जोडणे व्हाईटबोर्डवर सोपे वाटते पण प्रोडक्शनमध्ये ते महाग पडते. तुम्हाला नवीन मॉनिटरिंग डॅशबोर्ड्स, नवीन बॅकअप प्रक्रिया, नवीन कनेक्शन पूल्स आणि नवीन फेलओव्हर लॉजिकची गरज भासते. AGE या सर्वांना बगल देते कारण ते तुमच्या सध्याच्या Postgres इन्स्टन्समध्येच असते.

हे आमच्यासाठी का उपयुक्त ठरले याची चार व्यावहारिक कारणे आहेत.

  • नवीन इन्फ्रास्ट्रक्चरची गरज नाही. AGE हे एक extension असल्याने, तुमचे सध्याचे pg_dump वेळापत्रक, तुमचे विद्यमान रेप्लिका (replicas) आणि तुमचे मानक Postgres हेल्थ चेक सर्व चालू राहतात. तुम्हाला ऑपरेशन्स टीमला आणखी एक डेटा स्टोअर सांभाळण्यासाठी तयार करण्याची गरज नाही.
  • एकाच क्वेरीमध्ये मिश्र वर्कलोड्स. AGE तुम्हाला SQL मध्ये Cypher लिहिण्याची परवानगी देते. तुम्ही संभाव्य व्हिडिओ शोधण्यासाठी ग्राफ ट्रॅव्हर्सल (graph traversal) चालवू शकता आणि नंतर प्रादेशिक कंटेंट निर्बंध लागू करण्यासाठी ते रिझल्ट सेट तुमच्या रिलेशनल users टेबलसोबत किंवा काही चॅनेलना कमी प्राधान्य देण्यासाठी रिलेशनल sponsorships टेबलसोबत जॉइन करू शकता. एकच राऊंड-ट्रिप. दोन क्वेरी लँग्वेजेसचे सहकार्य.
  • पोर्टेबिलिटी (Portability). Cypher ही एक ओपन आणि चांगल्या प्रकारे दस्तऐवजीकरण केलेली (well-documented) ग्राफ क्वेरी लँग्वेज आहे. जर DailyWatch ची व्याप्ती वाढली आणि नंतर Neo4j किंवा Memgraph वर स्थलांतरित होण्याची गरज पडली, तर क्वेरी लॉजिक किमान फेरबदल करून वापरता येते. तुम्ही कोणत्याही प्रोप्रायटरी डायलेक्टमध्ये अडकून पडत नाही.
  • सुसंगतता (Compatibility). डेटा शेवटी PostgreSQL मध्ये असल्याने, तुमचे सध्याचे PHP किंवा Python टूल्स बदलत नाहीत. तुम्ही त्याच ड्रायव्हरने कनेक्ट होता, त्याच कनेक्शन स्ट्रिंग्स हाताळता आणि त्याच पद्धतीने रो (rows) मिळवता. ग्राफ लॉजिक क्वेरी लेयरमध्ये असते, ॲप्लिकेशन लेयरमध्ये नाही.

Co-Viewership मॉडेलिंग

याची अंमलबजावणी सरळ आहे. आम्ही आमच्यासाठी महत्त्वाच्या असलेल्या घटकांसाठी (entities) नोड्स (nodes) परिभाषित केले: Video आणि Channel. त्यानंतर आम्ही त्यांच्यातील संबंधांसाठी एडजेस (edges) परिभाषित केले. एक PUBLISHED एज Channel ला Video शी जोडते. एक CO_VIEWED एज एका Video ला दुसऱ्याशी जोडते, ज्यामध्ये weight प्रॉपर्टी असते जी दोन व्हिडिओ एकाच व्ह्यूइंग सेशनमध्ये किती वेळा दिसले हे दर्शवते.

हे मॉडेल अशी गोष्ट टिपते जी टॅग-आधारित SQL करू शकत नाही: ती म्हणजे अंतर्निहित संरचना (implicit structure)