Hyperdrive എന്നത് Workers-ന് PostgreSQL ഡാറ്റാബേസുകളുമായി (vector search-നായി pgvector extension ഉപയോഗിക്കുന്നവ ഉൾപ്പെടെ) നേരിട്ട് ആശയവിനിമയം നടത്താൻ അനുവദിക്കുന്ന ഒരു managed connection-pooling സേവനമാണ്. ഡാറ്റാബേസ് കണക്ഷനുകളുടെ ഒരു പുനരുപയോഗിക്കാവുന്ന സെറ്റ് സെർവറിന് അടുത്തായി സൂക്ഷിക്കുന്നതിലൂടെ, edge AI വർക്ക്ലോഡുകളെ കാലങ്ങളായി തടസ്സപ്പെടുത്തിക്കൊണ്ടിരിക്കുന്ന handshake overhead കുറയ്ക്കാൻ Hyperdrive സഹായിക്കുന്നു.

എന്തുകൊണ്ടാണ് Workers-ഉം PostgreSQL-ഉം തമ്മിൽ പൊരുത്തപ്പെടാത്തത്

Cloudflare Workers ഡസൻ കണക്കിന് edge ലൊക്കേഷനുകളിൽ കുറഞ്ഞ സമയത്തേക്ക് മാത്രം പ്രവർത്തിക്കുന്ന JavaScript ഫംഗ്ഷനുകളായാണ് പ്രവർത്തിക്കുന്നത്. ഓരോ പുതിയ റിക്വസ്റ്റും ഒരു പുതിയ പ്രോസസ്സ് ആരംഭിക്കുന്നു, സാധാരണയായി ബാക്കെൻഡ് ഡാറ്റാബേസിലേക്ക് ഒരു പുതിയ TCP കണക്ഷൻ തുറക്കുക എന്നതാണ് ഇതിന്റെ രീതി. എന്നാൽ, PostgreSQL ഓരോ ക്ലയന്റ് പ്രോസസ്സിനും ഒരു സ്റ്റേബിൾ കണക്ഷൻ പ്രതീക്ഷിക്കുന്നു കൂടാതെ ഒരേസമയം കണക്ട് ചെയ്യാവുന്ന ആകെ കണക്ഷനുകളുടെ എണ്ണത്തിൽ പരിധിയുമുണ്ട്. ഇതിന്റെ ഫലമായി രണ്ട് പ്രശ്നങ്ങൾ ഉണ്ടാകുന്നു:

  • ഉയർന്ന കണക്ഷൻ ചിലവ് (High connection cost) – ഒരു കണക്ഷൻ സ്ഥാപിക്കുന്നതിന് ഓതന്റിക്കേഷനും പ്രോട്ടോക്കോൾ നnegotiation-നും വേണ്ടി പലതവണ ഡാറ്റ കൈമാറേണ്ടി വരുന്നു (round trips). ഈ പ്രക്രിയ ഓരോ റിക്വസ്റ്റിന്റെയും ലേറ്റൻസി (latency) വർദ്ധിപ്പിക്കുന്നു.
  • കണക്ഷൻ പരിധികൾ (Connection limits) – ആയിരക്കണക്കിന് ഒരേസമയം പ്രവർത്തിക്കുന്ന (concurrent) എക്സിക്യൂഷനുകളിലേക്ക് Workers വികസിപ്പിക്കാൻ കഴിയും, ഇത് PostgreSQL-ന്റെ കണക്ഷൻ പൂൾ വേഗത്തിൽ തീർക്കുകയും ഡാറ്റാബേസ് ക്രാഷ് ആകാൻ കാരണമാവുകയും ചെയ്തേക്കാം.

എങ്ങനെയാണ് Hyperdrive ഈ വിടവ് നികത്തുന്നത്

Hyperdrive ഒരു Worker-നും ഡാറ്റാബേസിനും ഇടയിൽ പ്രവർത്തിക്കുന്നു, ഇത് PostgreSQL ഇൻസ്റ്റൻസിന് നെറ്റ്‌വർക്ക് പരമാവധി അടുത്ത് ഒരു സെർവറിൽ സ്ഥിരമായ കണക്ഷനുകളുടെ ഒരു പൂൾ നിലനിർത്തുന്നു. Worker-ന്റെ കാഴ്ചപ്പാടിൽ മാറ്റം എന്നത് ഒരു പുതിയ connection string മാത്രം ഉപയോഗിക്കുക എന്നതാണ്. ആന്തരികമായി, പ്രോക്സി ഓരോ പുതിയ ക്വറിയ്ക്കും നിലവിലുള്ള ഒരു കണക്ഷൻ വീണ്ടും ഉപയോഗിക്കുന്നു, ഇത് handshake ചിലവ് ഒഴിവാക്കുന്നു.

സെറ്റപ്പ് വളരെ ലളിതമാണ്:

  1. ഒറിജിനൽ ഡാറ്റാബേസ് URL നൽകിക്കൊണ്ട് ഒരു Hyperdrive ഇൻസ്റ്റൻസ് നിർമ്മിക്കാൻ Wrangler CLI (Cloudflare-ന്റെ കമാൻഡ്-ലൈൻ ടൂൾ) ഉപയോഗിക്കുക.
  2. നിർമ്മിച്ച Hyperdrive binding wrangler.toml കോൺഫിഗറേഷൻ ഫയലിൽ ചേർക്കുക.
  3. Worker കോഡിൽ node-postgres പോലുള്ള ഒരു കോംപാറ്റിബിൾ ഡ്രൈവർ ഉപയോഗിക്കുക; ഈ ഡ്രൈവർ Hyperdrive എൻഡ്പോയിന്റിനെ ഒരു സാധാരണ PostgreSQL സെർവറായിട്ടായിരിക്കും കാണുന്നത്.

ഡാറ്റാബേസ് പാസ്‌വേഡ് Hyperdrive കോൺഫിഗറേഷനിൽ മാത്രം ഉള്ളതിനാൽ, അത് Worker സോഴ്‌സ് കോഡിൽ ഒരിക്കലും പ്രത്യക്ഷപ്പെടില്ല, ഇത് സുരക്ഷ വർദ്ധിപ്പിക്കുന്നു.

വെക്റ്റർ സെർച്ചിനായുള്ള പ്രായോഗിക നിർദ്ദേശങ്ങൾ

pgvector ഉപയോഗിക്കുന്ന വെക്റ്റർ-സെർച്ച് വർക്ക്ലോഡുകളിൽ ഓരോ ക്വറിയിലും മാറിക്കൊണ്ടിരിക്കുന്ന വലിയ ഫ്ലോട്ടിംഗ്-പോയിന്റ് അറേകൾ (floating-point arrays) ഉൾപ്പെടുന്നു. Hyperdrive-ന്റെ ഡിഫോൾട്ട് രീതിയിൽ ഒരു റീഡ് ക്യാഷെ (read cache) ഉൾപ്പെടുന്നു, ഇത് നിരന്തരം മാറിക്കൊണ്ടിരിക്കുന്ന ഡാറ്റയുമായി പൊരുത്തപ്പെടാൻ പ്രയാസമുണ്ടാക്കിയേക്കാം. ഫലങ്ങൾ കൃത്യമായി ലഭിക്കുന്നതിന്, ക്യാഷിംഗ് (caching) ഡിസേബിൾ ചെയ്തുകൊണ്ട് രണ്ടാമതൊരു Hyperdrive കോൺഫിഗറേഷൻ സജ്ജീകരിക്കുക.

ദീർഘനേരം നീണ്ടുനിൽക്കുന്ന ട്രാൻസാക്ഷനുകളും (Long-running transactions) മറ്റൊരു പ്രശ്നമാണ്. ഒരു എക്സ്റ്റേണൽ AI മോഡൽ മറുപടിക്കായി കാത്തുനിൽക്കുമ്പോൾ ഡാറ്റാബേസ് കണക്ഷൻ പിടിച്ചുവെക്കുന്നത് കണക്ഷൻ പൂളിലെ ഒരു സ്ലോട്ട് ഉപയോഗിക്കാനും പൂളിംഗിന്റെ ഉദ്ദേശ്യം ഇല്ലാതാക്കാനും കാരണമാകും. ശുപാർശ ചെയ്യുന്ന രീതി ഇതാണ്:

  • ഒരു ട്രാൻസാക്ഷൻ തുറക്കുക.
  • ക്വറി എക്സിക്യൂട്ട് ചെയ്യുക.
  • ഉടൻ തന്നെ കമ്മറ്റ് (Commit) ചെയ്യുക.
  • ട്രാൻസാക്ഷന് പുറത്ത് AI മോഡലിനെ വിളിക്കുക.

pgvector പാരാമീറ്ററുകൾ ഫൈൻ ട്യൂൺ ചെയ്യുന്നത് (ഉദാഹരണത്തിന്, സെർച്ച് കൃത്യത നിയന്ത്രിക്കുന്ന hnsw.ef_search സെറ്റിംഗ്) ഒരു ചെറിയ ട്രാൻസാക്ഷനുള്ളിൽ SET LOCAL സ്റ്റേറ്റ്‌മെന്റ് ഉപയോഗിച്ച് ചെയ്യാവുന്നതാണ്. ഇത് മാറ്റം നിലവിലെ ക്വറിക്ക് മാത്രമായി പരിമിതപ്പെടുത്തുന്നുവെന്നും പൂൾ പങ്കിടുന്ന മറ്റ് Workers-നെ ബാധിക്കില്ലെന്നും ഉറപ്പാക്കുന്നു.

നിലനിൽക്കുന്ന പരിമിതികൾ

Hyperdrive ഡാറ്റാബേസിനെ മറ്റൊരു സ്ഥലത്തേക്ക് മാറ്റുന്നില്ല. PostgreSQL സെർവർ ദൂരെയുള്ള ഒരു ക്ലൗഡ് റീജിയണിലാണെങ്കിൽ, ലേറ്റൻസി ആ ഭൗതിക ദൂരത്താൽ പരിമിതമായിരിക്കും. ഒരു Hyperdrive ഇൻസ്റ്റൻസ് ഉള്ള ഏറ്റവും അടുത്തുള്ള എഡ്ജ് നോഡിലേക്ക് Workers-നെ റൂട്ട് ചെയ്യുന്നതിലൂടെ Cloudflare-ന്റെ “Smart Placement” ഫീച്ചറിന് സഹായിക്കാനാകും, എന്നാൽ അടിസ്ഥാനപരമായ നെറ്റ്‌വർക്ക് റൗണ്ട്-ട്രിപ്പ് ഒഴിവാക്കാൻ കഴിയില്ല.

സ്റ്റാറ്റിക് റീഡുകൾക്ക് (static reads) ഉപകാരപ്രദമാണെങ്കിലും, ഓരോ റിക്വറിനും മാറിക്കൊണ്ടിരിക്കുന്ന വെക്റ്റർ ഡാറ്റയിൽ ക്യാഷിംഗ് ലെയർ പലപ്പോഴും പരാജയപ്പെട്ടേക്കാം (miss). ക്യാഷ് ഹിറ്റുകളും (cache hits) സെർച്ച് ഫലങ്ങളുടെ പുതുമയും തമ്മിലുള്ള സന്തുലിതാവസ്ഥ ഡെവലപ്പർമാർ പരിഗണിക്കേണ്ടതുണ്ട്.

എപ്പോഴാണ് ഒരു ബദൽ തിരഞ്ഞെടുക്കേണ്ടത്

ഒരു ആപ്ലിക്കേഷന് റിലേഷണൽ ജോയിനുകൾ (relational joins) ഇല്ലാതെ വെക്റ്റർ സ്റ്റോറേജ് മാത്രം ആവശ്യമുള്ളതെങ്കിൽ, Cloudflare 'Vectorize' എന്ന പേരിൽ ഒരു പ്രത്യേക സേവനം വാഗ്ദാനം ചെയ്യുന്നു. Vectorize വെക്റ്ററുകൾ നേരിട്ട് എഡ്ജിൽ സൂക്ഷിക്കുന്നു കൂടാതെ ഇതിന് PostgreSQL ബാക്കെൻഡിന്റെ ആവശ്യമില്ല. എന്നാൽ യൂസർ പ്രൊഫൈലുകൾ അല്ലെങ്കിൽ ട്രാൻസാക്ഷൻ ഹിസ്റ്ററികൾ പോലുള്ള നിലവിലുള്ള റിലേഷണൽ ടേബിളുകളുമായി വെക്റ്ററുകൾ ജോയിൻ ചെയ്യേണ്ടതുണ്ടെങ്കിൽ Hyperdrive ആണ് മികച്ച തിരഞ്ഞെടുപ്പ്.

ചുരുക്കത്തിൽ

PostgreSQL കണക്ഷൻ പരിധികൾ മറികടക്കാതെ തന്നെ AI അധിഷ്ഠിത വെക്റ്റർ സെർച്ചുകൾ നടത്താൻ എഡ്ജ് ഡെവലപ്പർമാർക്ക് Hyperdrive ഒരു പ്രായോഗിക ഉപകരണം നൽകുന്നു. ഇത് handshake ലേറ്റൻസി കുറയ്ക്കുകയും, ക്രെഡൻഷ്യലുകൾ കേന്ദ്രീകരിക്കുകയും, ക്യാഷിംഗിനും ട്രാൻസാക്ഷൻ ദൈർഘ്യത്തിനും മേൽ കൃത്യമായ നിയന്ത്രണം നൽകുകയും ചെയ്യുന്നു. ഈ സേവനം എഡ്ജും ഡാറ്റാബേസും തമ്മിലുള്ള അടിസ്ഥാനപരമായ ദൂരം ഇല്ലാതാക്കുന്നില്ല, കൂടാതെ ക്യാഷ്-മിസ്സുകളും (cache-misses) ഒരു ആശങ്കയായി തുടരുന്നു. എങ്കിലും, റിലേഷണൽ ജോയിനുകളും വെക്റ്റർ സിമിലാരിറ്റിയും (vector similarity) ഒരുപോലെ ആവശ്യമുള്ള വർക്ക്ലോഡുകൾക്ക്, സ്കെയിലബിൾ ആയതും കുറഞ്ഞ ലേറ്റൻസിയുള്ളതുമായ ഒരു എഡ്ജ് സ്റ്റാക്കിനായുള്ള ഏറ്റവും നേരിട്ടുള്ള പാത Hyperdrive ആണ്.