DailyWatch-ൽ, ഞങ്ങളുടെ "related videos" പാനൽ ഒരു ലളിതമായ SQLite ക്വറിയിലൂടെയാണ് ആരംഭിച്ചത്. അത് മൂന്ന് ടേബിളുകളെ യോജിപ്പിക്കുകയും (join), പരസ്പരം ബന്ധപ്പെട്ട ടാഗുകൾ എണ്ണുകയും, ഒരു റാങ്ക് ചെയ്ത ലിസ്റ്റ് നൽകുകയും ചെയ്തു. ചെറിയൊരു കാറ്റലോഗിന് അത് മതിയായിരുന്നു. "italian", "pasta" എന്നീ ടാഗുകളുള്ള ഒരു കുക്കിംഗ് വീഡിയോ, അതേ ടാഗുകളുള്ള മറ്റ് വീഡിയോകൾ കാണിച്ചുതരും, ഉപയോക്താക്കളും അവ ക്ലിക്ക് ചെയ്യും. മെറ്റാഡാറ്റ കൃത്യമായതുകൊണ്ടും ലൈബ്രറി ചെറുതായതുകൊണ്ടും ആ ഔട്ട്പുട്ട് പ്രസക്തമായി തോന്നി.

പിന്നീട് കാറ്റലോഗ് വളരുകയും പ്രേക്ഷകരുടെ പ്രതീക്ഷകൾ മാറുകയും ചെയ്തു. ഒരേ ടാഗുകളുള്ള കൂടുതൽ വീഡിയോകൾ മാത്രമായിരുന്നില്ല അവർ ആഗ്രഹിച്ചത്. നിലവിലെ വീഡിയോ കണ്ട ഉടനെ ശതമാനത്തിൽ എത്ര ശതമാനം ആളുകളും കണ്ട വീഡിയോ ഏതാണെന്ന് അവർ ആഗ്രഹിച്ചു. നിലവിലെ വീഡിയോയുടെ വിവരണത്തിൽ ഒന്നും സൂചിപ്പിച്ചിട്ടില്ലെങ്കിലും, ടാഗുകൾ കുറവാണെങ്കിലും, ഒരേ സമയം കാണാറുള്ള ആ നിഷ്പ്രഭമായ (niche) ചാനലുകൾ അവർ ആഗ്രഹിച്ചു. ഇവ മെറ്റാഡാറ്റയുടെ പൊരുത്തമല്ല, മറിച്ച് പെരുമാറ്റ രീതികളാണ് (behavioral patterns). സ്വയം ജോയിനുകളുടെയും (self-joins) റിക്കഴ്സീവ് കോമൺ ടേബിൾ എക്സ്പ്രഷനുകളുടെയും (recursive common table expressions) സങ്കീർണ്ണമായ ഒരു വലയായി മാറാതെ SQLite-ന് ഇവയെ പ്രകടിപ്പിക്കാൻ കഴിഞ്ഞില്ല. കോ-വ്യൂവർഷിപ്പ് (co-viewership) അല്ലെങ്കിൽ സെഷൻ അഡ്ജസൻസി (session adjacency) എന്നിങ്ങനെ ഞങ്ങൾ മോഡൽ ചെയ്യാൻ ശ്രമിച്ച ഓരോ പുതിയ സിഗ്നലും ലേറ്റൻസിയും (latency) പ്രവർത്തനപരമായ സങ്കീർണ്ണതയും വർദ്ധിപ്പിച്ചു. ഒരു ഗ്രാഫ് പ്രശ്നത്തെ റിലേഷണൽ രീതിയിൽ ഒതുക്കാൻ ശ്രമിക്കുന്ന അവസ്ഥയായിരുന്നു അത്.

ഞാൻ റെക്കമെൻഡേഷൻ ലെയർ Apache AGE-ലേക്ക് മാറ്റി.

നിലവിൽ നിങ്ങൾ ഉപയോഗിക്കുന്ന ഡാറ്റാബേസിലേക്ക് openCypher ഗ്രാഫ് ക്വറികൾ കൂടി ചേർക്കുന്ന ഒരു PostgreSQL extension ആണ് Apache AGE. ഇതൊരു പ്രത്യേക സെർവർ അല്ല. ഇതൊരു sidecar അല്ല. ഇത് Postgres-നുള്ളിൽ തന്നെ പ്രവർത്തിക്കുന്നു, അതായത് ഒരു പ്രത്യേക Neo4j ക്ലസ്റ്റർ സജ്ജമാക്കാതെയോ അല്ലെങ്കിൽ തികച്ചും പുതിയൊരു പ്രവർത്തന രീതി പഠിക്കാതെയോ ഞങ്ങൾക്ക് ഒരു co-view network നിർമ്മിക്കാൻ കഴിഞ്ഞു. ഡാറ്റാബേസ് റിലയബിലിറ്റി എഞ്ചിനീയർ ഇല്ലാത്ത ഒരു ചെറിയ ടീമിനെ സംബന്ധിച്ചിടത്തോളം ഈ വ്യത്യാസം വളരെ വലുതായിരുന്നു.

എന്തുകൊണ്ടാണ് ഒരു പുതിയ ഡാറ്റാബേസിനേക്കാൾ ഒരു extension മികച്ചതാകുന്നത്

നിങ്ങളുടെ സ്റ്റാക്കിലേക്ക് ഒരു ഗ്രാഫ് ഡാറ്റാബേസ് ചേർക്കുന്നത് ഒരു വൈറ്റ്ബോർഡിൽ എളുപ്പമായി തോന്നാമെങ്കിലും പ്രൊഡക്ഷനിൽ അത് ചിലവേറിയതാണ്. നിങ്ങൾക്ക് പുതിയ മോണിറ്ററിംഗ് ഡാഷ്‌ബോർഡുകൾ, പുതിയ ബാക്കപ്പ് നടപടിക്രമങ്ങൾ, പുതിയ കണക്ഷൻ പൂളുകൾ, പുതിയ ഫെയിലോവർ ലോജിക് എന്നിവ ആവശ്യമായി വരും. AGE ഇവയെല്ലാം ഒഴിവാക്കുന്നു, കാരണം അത് നിങ്ങളുടെ നിലവിലുള്ള Postgres ഇൻസ്റ്റൻസിനുള്ളിൽ തന്നെ പ്രവർത്തിക്കുന്നു.

ഇത് ഞങ്ങൾക്ക് ഫലപ്രദമായതിന് നാല് പ്രായോഗിക കാരണങ്ങളുണ്ട്.

  • പുതിയ ഇൻഫ്രാസ്ട്രക്ചർ ആവശ്യമില്ല. AGE ഒരു extension ആയതുകൊണ്ട്, നിങ്ങളുടെ നിലവിലുള്ള pg_dump ഷെഡ്യൂൾ, നിലവിലുള്ള റെപ്ലിക്കകൾ, നിങ്ങളുടെ സ്റ്റാൻഡേർഡ് Postgres ഹെൽത്ത് ചെക്കുകൾ എന്നിവയെല്ലാം തുടർന്നും പ്രവർത്തിക്കും. മറ്റൊരു ഡാറ്റാ സ്റ്റോർ കൂടി കൈകാര്യം ചെയ്യാൻ ഓപ്പറേഷൻസ് ടീമിനെ നിർബന്ധിക്കേണ്ടി വരില്ല.
  • ഒറ്റ ക്വറിയിൽ മിക്സഡ് വർക്ക്ലോഡുകൾ. SQL-നുള്ളിൽ തന്നെ Cypher എഴുതാൻ AGE നിങ്ങളെ അനുവദിക്കുന്നു. അനുയോജ്യമായ വീഡിയോകൾ കണ്ടെത്താൻ ഒരു ഗ്രാഫ് ട്രാവേഴ്സൽ (graph traversal) നടത്താം, തുടർന്ന് ആ റിസൾട്ട് സെറ്റിനെ റിലേഷണൽ users ടേബിളുമായി യോജിപ്പിച്ച് (join) പ്രാദേശിക ഉള്ളടക്ക നിയന്ത്രണങ്ങൾ നടപ്പിലാക്കാം, അല്ലെങ്കിൽ ചില ചാനലുകളെ ഒഴിവാക്കാൻ റിലേഷണൽ sponsorships ടേബിളുമായി യോജിപ്പിക്കാം. ഒറ്റ റൗണ്ട് ട്രിപ്പ്. രണ്ട് ക്വറി ഭാഷകൾ സഹകരിക്കുന്നു.
  • പോർട്ടബിലിറ്റി (Portability). Cypher എന്നത് ഒരു ഓപ്പൺ ആയ, കൃത്യമായി ഡോക്യുമെന്റ് ചെയ്ത ഗ്രാഫ് ക്വറി ഭാഷയാണ്. DailyWatch-ന് AGE-ൽ നിന്ന് മാറി പിന്നീട് Neo4j അല്ലെങ്കിൽ Memgraph-ലേക്ക് മാറേണ്ടി വന്നാൽ, ക്വറി ലോജിക് വളരെ കുറഞ്ഞ മാറ്റങ്ങളോടെ മാറ്റാൻ സാധിക്കും. നിങ്ങൾ ഒരു പ്രത്യേക ഡയലക്റ്റത്തിൽ മാത്രം ഒതുങ്ങിപ്പോകുന്നില്ല.
  • കോംപാറ്റിബിലിറ്റി (Compatibility). ഡാറ്റ അന്തിമമായി PostgreSQL-ൽ ഇരിക്കുന്നതുകൊണ്ട്, നിങ്ങളുടെ നിലവിലുള്ള PHP അല്ലെങ്കിൽ Python ടൂളുകളിൽ മാറ്റം വരുത്തേണ്ടതില്ല. നിങ്ങൾ അതേ ഡ്രൈവർ ഉപയോഗിച്ച് കണക്ട് ചെയ്യാം, അതേ കണക്ഷൻ സ്ട്രിംഗുകൾ കൈകാര്യം ചെയ്യാം, ഒരേ രീതിയിൽ തന്നെ റോകൾ (rows) എടുക്കാം. ഗ്രാഫ് ലോജിക് ക്വറി ലെയറിൽ ആണ് ഇരിക്കുന്നത്, അല്ലാതെ ആപ്ലിക്കേഷൻ ലെയറിലല്ല.

Co-Viewership മോഡലിംഗ്

ഇതിന്റെ നടപ്പിലാക്കൽ വളരെ ലളിതമാണ്. ഞങ്ങൾക്ക് ആവശ്യമുള്ള എൻ്റേറ്റികൾക്കായി (entities) ഞങ്ങൾ നോഡുകൾ (nodes) നിർവചിച്ചു: Video, Channel. തുടർന്ന് അവ തമ്മിലുള്ള ബന്ധങ്ങൾക്കായി എഡ്ജുകൾ (edges) നിർവചിച്ചു. ഒരു PUBLISHED എഡ്ജ് ഒരു Channel-നെ ഒരു Video-യുമായി ബന്ധിപ്പിക്കുന്നു. ഒരു CO_VIEWED എഡ്ജ് ഒരു Video-യെ മറ്റൊരു വീഡിയോയുമായി ബന്ധിപ്പിക്കുന്നു, ഇതിൽ രണ്ട് വീഡിയോകളും എത്ര തവണ ഒരേ വ്യൂയിംഗ് സെഷനിൽ പ്രത്യക്ഷപ്പെട്ടു എന്ന് സൂചിപ്പിക്കുന്ന ഒരു weight പ്രോപ്പർട്ടി ഉണ്ടായിരിക്കും.

ടാഗ് അടിസ്ഥാനമാക്കിയുള്ള SQL-ന് കഴിയാത്ത ഒരു കാര്യം ഈ മോഡൽ ഉൾക്കൊള്ളുന്നു: അതിന്റെ പരോക്ഷമായ ഘടന (implicit structure)