pgvector-നേക്കാൾ 22 മടങ്ങ് വേഗത്തിൽ LanceDB 100k OpenAI എംബെഡിംഗുകൾ (embeddings) ലോഡ് ചെയ്തു, എന്നാൽ എട്ട് ഒരേസമയം പ്രവർത്തിക്കുന്ന ക്ലയന്റുകളിൽ നിന്നുള്ള ഒരേ വർക്ക്ലോഡ് pgvector 1.8 മടങ്ങ് വേഗത്തിൽ കൈകാര്യം ചെയ്തു. സിംഗിൾ-ത്രെഡ് ലേറ്റൻസിയിലും (single-thread latency) സ്റ്റോറേജ് കാര്യക്ഷമതയിലും LanceDB മുന്നിട്ടുനിന്നു, ഇത് ഡെവലപ്പർമാർക്ക് ഒരു വെക്റ്റർ സ്റ്റോർ തിരഞ്ഞെടുക്കാൻ ഡാറ്റാധിഷ്ഠിതമായ ഒരു മാർഗ്ഗം നൽകുന്നു.

എന്തുകൊണ്ടാണ് ഇപ്പോൾ ഒരു ബെഞ്ച്മാർക്ക് പ്രധാനമാകുന്നത്

വെക്റ്റർ സെർച്ച് (Vector search) ഗവേഷണ ലാബുകളിൽ നിന്ന് റെക്കമെൻഡേഷൻ എഞ്ചിനുകൾ, റിട്രീവൽ-ഓഗ്മെന്റഡ് ജനറേഷൻ (RAG) തുടങ്ങിയ പ്രൊഡക്ഷൻ സർവീസുകളിലേക്ക് മാറിയിരിക്കുന്നു. മിക്ക ടീമുകളും നിലവിൽ PostgreSQL ഉപയോഗിക്കുന്നുണ്ട്, അതിനാൽ പുതിയ ഇൻഫ്രാസ്ട്രക്ചർ ഇല്ലാതെ തന്നെ സമാനതകൾ കണ്ടെത്തുന്നതിനുള്ള (similarity search) സൗകര്യം pgvector എക്സ്റ്റൻഷൻ വാഗ്ദാനം ചെയ്യുന്നു. എന്നാൽ LanceDB പോലുള്ള ഡെഡിക്കേറ്റഡ് സ്റ്റോറുകൾ കുറഞ്ഞ ലേറ്റൻസിയും കുറഞ്ഞ ചിലവിലുള്ള സ്റ്റോറേജും വാഗ്ദാനം ചെയ്യുന്നു. ഡാറ്റസെറ്റുകൾ വർദ്ധിക്കുകയും റിക്വസ്റ്റ് നിരക്ക് ഉയരുകയും ചെയ്യുമ്പോൾ ചിലവിനെയും പ്രകടനത്തെയും ബാധിക്കുന്ന ഒരു തീരുമാനമാണ് "നിലവിലുള്ള സംവിധാനത്തോടൊപ്പം ഇത് ചേർക്കണോ" അതോ "പ്രത്യേകമായി നിർമ്മിച്ച ഒരു എഞ്ചിൻ ഉപയോഗിക്കണോ" എന്നത്.

ടെസ്റ്റ് എങ്ങനെയാണ് ക്രമീകരിച്ചത്

OpenAI-യുടെ എംബെഡിംഗ് മോഡൽ ഉപയോഗിച്ച് നിർമ്മിച്ച, ഓരോന്നിനും 1536 ഡൈമൻഷനുകളുള്ള ഒരേ 100k വെക്റ്ററുകൾ രണ്ട് സിസ്റ്റങ്ങളും ഇൻഡക്സ് ചെയ്തു. ഞങ്ങൾ ഇൻജഷൻ സ്പീഡ് (ingestion speed), ഡിസ്ക് ഉപയോഗം, സിംഗിൾ-ത്രെഡ് ക്വറി ലേറ്റൻസി, എട്ട് കൺകറന്റ് ക്ലയന്റുകൾ ഉപയോഗിച്ചുള്ള ത്രൂപുട്ട് (throughput) എന്നിവ അളന്നു.

മുഖാമുഖ ഫലങ്ങൾ

  • ഇൻജഷൻ സ്പീഡ് (Ingestion speed) – LanceDB 22 മടങ്ങ് മുന്നേറ്റം രേഖപ്പെടുത്തി.
  • ഡിസ്ക് ഫൂട്ട്പ്രിന്റ് (Disk footprint) – pgvector ഉപയോഗിച്ച സ്ഥലത്തിന്റെ ഏകദേശം മൂന്നിലൊന്ന് മാത്രം ഉപയോഗിച്ചാണ് LanceDB വെക്റ്ററുകൾ സംഭരിച്ചത്.
  • സിംഗിൾ-ത്രെഡ് ലേറ്റൻസി (Single-thread latency) – LanceDB-യിൽ ക്വറികൾ ഏകദേശം ഇരട്ടി വേഗത്തിൽ പ്രവർത്തിച്ചു.
  • കൺകറൻസി സ്കെയിലിംഗ് (Concurrency scaling) – എട്ട് പാരലൽ ക്ലയന്റുകൾ ഉപയോഗിക്കുമ്പോൾ, LanceDB-യേക്കാൾ 1.8 മടങ്ങ് ഉയർന്ന ത്രൂപുട്ട് pgvector നൽകി.

വ്യത്യാസങ്ങളുടെ ആർക്കിടെക്ചറൽ കാരണങ്ങൾ

ആപ്ലിക്കേഷൻ ഹോസ്റ്റ് ചെയ്യുന്ന Python പ്രോസസിനുള്ളിൽ പ്രവർത്തിക്കുന്ന ഒരു എംബെഡഡ് ലൈബ്രറിയാണ് LanceDB. എല്ലാ പ്രവർത്തനങ്ങളും ഇൻ-പ്രോസസ് (in-process) ആയതിനാൽ, ഡാറ്റ ഒരിക്കലും ഒരു നെറ്റ്‌വർക്ക് അതിർവരമ്പുകൾ കടക്കുന്നില്ല, കൂടാതെ ഇൻഡക്സ് വളരെ കുറഞ്ഞ ഓവർഹെഡിൽ അപ്‌ഡേറ്റ് ചെയ്യപ്പെടുന്നു. ഈ ഡിസൈൻ സിംഗിൾ-ടാസ്ക് വർക്ക്ലോഡുകൾക്ക് മികച്ചതാണ്, എന്നാൽ ഒന്നിലധികം Python ത്രെഡുകൾ Global Interpreter Lock (GIL)-നായി മത്സരിക്കുമ്പോൾ ഇതിന്റെ പരിമിതികൾ വെളിപ്പെടുന്നു. GIL പൈത്തൺ ബൈറ്റ്കോഡിന്റെ യഥാർത്ഥ പാരലൽ എക്സിക്യൂഷനെ തടയുന്നു.

pgvector സെർവർ സൈഡിൽ PostgreSQL-നെ വിപുലീകരിക്കുന്നു. ഓരോ ക്ലയന്റ് കണക്ഷനും ഒരു പ്രത്യേക സെർവർ പ്രോസസ്സ് ആരംഭിക്കുന്നു, ഇത് GIL പൂർണ്ണമായും ഒഴിവാക്കുന്നു. ഒരു സമാനത സെർച്ച് (similarity search) എങ്ങനെ നിറവേറ്റണമെന്ന് PostgreSQL പ്ലാനർ തീരുമാനിക്കുന്നു, കൂടാതെ ഒരേസമയം വരുന്ന റിക്വസ്റ്റുകൾ കൈകാര്യം ചെയ്യാൻ സെർവറിന് നിരവധി പ്രോസസ്സുകൾ പ്രവർത്തിപ്പിക്കാൻ കഴിയും. ഈ ഐസൊലേഷൻ (isolation) ആണ് കൂടുതൽ ലോഡ് വരുമ്പോൾ മികച്ച സ്കെയിലിംഗ് നൽകാൻ സഹായിക്കുന്നത്.

ഫിൽട്ടറിംഗും ക്വറി പ്ലാനിംഗും തമ്മിലുള്ള വ്യത്യാസങ്ങൾ

യഥാർത്ഥ ലോകത്തെ RAG പൈപ്പ്‌ലൈനുകൾ പലപ്പോഴും വെക്റ്റർ സമാനതയെ പരമ്പരാഗത ഫിൽട്ടറുകളുമായി (ഉദാഹരണത്തിന്, WHERE user_id = 42) സംയോജിപ്പിക്കുന്നു. LanceDB പ്രവചിക്കാവുന്ന രീതിയിൽ പ്രവർത്തിക്കുന്ന ഒരു പ്രീഫിൽറ്റർ (prefilter) ഉപയോഗിക്കുന്നു. എന്നാൽ pgvector PostgreSQL-ന്റെ ക്വറി പ്ലാനറുകളെയാണ് ആശ്രയിക്കുന്നത്; ഇത് സ്റ്റാറ്റിസ്റ്റിക്സുകൾ അനുസരിച്ച് വേഗതയേറിയ ഇൻഡക്സ് സ്കാനോ അല്ലെങ്കിൽ സാവധാനത്തിലുള്ള എക്സാക്റ്റ് സ്കാനോ തിരഞ്ഞെടുക്കാം. ഒരു pgvector ടേബിൾ ബൾക്ക് ലോഡ് ചെയ്ത ശേഷം ANALYZE റൺ ചെയ്യുന്നത് ആ സ്റ്റാറ്റിസ്റ്റിക്സുകളെ പുതുക്കുന്നു; ഇത് ചെയ്തില്ലെങ്കിൽ, റികാൾ (recall) പൂജ്യത്തോട് അടുത്ത് കുറയാൻ സാധ്യതയുണ്ട്, ഇത് സെർച്ചിനെ ഫലപ്രദമല്ലാതാക്കുന്നു.

ഏത് ഓപ്ഷൻ എപ്പോൾ തിരഞ്ഞെടുക്കണം

ഈ സാഹചര്യങ്ങളിൽ pgvector തിരഞ്ഞെടുക്കുക:

  • നിങ്ങളുടെ സ്റ്റാക്കിൽ നിലവിൽ PostgreSQL ഉണ്ടെങ്കിൽ, പുതിയൊരു സർവീസ് കൂടി ചേർക്കുന്നത് ഒഴിവാക്കാൻ ആഗ്രഹിക്കുന്നുണ്ടെങ്കിൽ.
  • ഒരേസമയം ധാരാളം ഉപയോക്താക്കളോ API കോളുകളോ ഉണ്ടാകുമെന്ന് പ്രതീക്ഷിക്കുന്നുണ്ടെങ്കിൽ.
  • ACID ഗ്യാരണ്ടികളും പരിചിതമായ DBA ടൂളുകളും പ്രധാനമാണെങ്കിൽ.

ഈ സാഹചര്യങ്ങളിൽ LanceDB തിരഞ്ഞെടുക്കുക:

  • നിങ്ങളുടെ വർക്ക്ഫ്ലോ നിരന്തരം പുതിയ എംബെഡിംഗുകൾ ഇൻജസ്റ്റ് ചെയ്യുന്ന ഒരു ML പൈപ്പ്‌ലൈൻ ആണെങ്കിൽ.
  • സിംഗിൾ-റിക്വസ്റ്റ് ഏജന്റുകൾക്ക് (ഉദാഹരണത്തിന്, ചാറ്റ് ബോട്ടുകൾ) ഏറ്റവും വേഗതയേറിയ റൈറ്റ് പാത്തും കുറഞ്ഞ ലേറ്റൻസിയും ആവശ്യമാണെങ്കിൽ.
  • ഡിസ്ക് ചിലവ് ഒരു പ്രശ്നമാണെങ്കിൽ, കൂടാതെ സിംഗിൾ-ത്രെഡ് പെർഫോമൻസ് പരിമിതികൾ നിങ്ങൾക്ക് അംഗീകരിക്കാൻ കഴിയുമെങ്കിൽ.

ചുരുക്കത്തിൽ: ഇൻജഷൻ സ്പീഡ്, കുറഞ്ഞ സ്റ്റോറേജ്, സിംഗിൾ-റിക്വസ്റ്റ് ലേറ്റൻസി എന്നിവയാണ് ഏറ്റവും പ്രധാനമെങ്കിൽ LanceDB ആണ് മികച്ചത്. ഒരേസമയം നിരവധി ഉപയോക്താക്കളെ സേവിക്കേണ്ടതുണ്ടെങ്കിൽ, കൂടാതെ നിലവിലുള്ള PostgreSQL ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, pgvector-ന്റെ കൺകറൻസി ശേഷി അതിനെ കൂടുതൽ സുരക്ഷിതമായ തിരഞ്ഞെടുപ്പാക്കുന്നു. നിങ്ങളുടെ ഉൽപ്പന്നത്തിന്റെ ഏറ്റവും പ്രധാനപ്പെട്ട അളവുകോലുകൾക്ക് (metrics) അനുസൃതമായി ഒരു സ്റ്റോർ തിരഞ്ഞെടുക്കാൻ ഈ ബെഞ്ച്മാർക്കിലെ വിവരങ്ങൾ ഉപയോഗിക്കുക.