LanceDB, 100k OpenAI embeddings-களை pgvector-ஐ விட 22 மடங்கு வேகமாக ஏற்றது, அதே நேரத்தில் எட்டு ஒரே நேரத்தில் இயங்கும் கிளையன்களிடமிருந்து (simultaneous clients) வந்த அதே பணிச்சுமையை (workload) pgvector 1.8 மடங்கு வேகமாக பதிலளித்தது. ஒற்றை-திரி தாமதம் (single-thread latency) மற்றும் சேமிப்புத் திறன் (storage efficiency) ஆகியவற்றில் உள்ள இடைவெளியும் LanceDB பக்கமே சாய்ந்திருந்தது, இது டெவலப்பர்கள் ஒரு வெக்டர் ஸ்டோரைத் தேர்ந்தெடுக்க தரவு சார்ந்த வழியை வழங்குகிறது.

ஏன் இப்போது ஒரு பெஞ்ச்மார்க் (benchmark) முக்கியமானது

வெக்டர் தேடல் (Vector search) ஆராய்ச்சி ஆய்வகங்களிலிருந்து பரிந்துரை இயந்திரங்கள் (recommendation engines) மற்றும் retrieval-augmented generation (RAG) போன்ற உற்பத்திச் சேவைகளுக்கு (production services) நகர்ந்துள்ளது. பெரும்பாலான குழுக்கள் ஏற்கனவே PostgreSQL-ஐப் பயன்படுத்துவதால், pgvector விரிவாக்கம் (extension) புதிய உள்கட்டமைப்பு இல்லாமல் ஒற்றுமைத் தேடலை (similarity search) வழங்குகிறது. இருப்பினும், LanceDB போன்ற பிரத்யேக ஸ்டோர்கள் குறைந்த தாமதத்தையும் மலிவான சேமிப்பையும் தருவதாகக் கூறுகின்றன. தரவுத்தொகுப்புகள் (datasets) வளரம 따라 மற்றும் கோரிக்கை விகிதங்கள் (request rates) அதிகரிக்கப் பெற, குழுக்கள் "எங்களிடம் இருப்பதைச் சேர்த்துக் கொள்வதா" அல்லது "குறிப்பிட்ட நோக்கத்திற்காக உருவாக்கப்பட்ட இயந்திரத்தை இயக்குவதா" என்பதைத் தேர்ந்தெடுக்க வேண்டும்; இந்த முடிவு செலவு மற்றும் செயல்திறனைப் பாதிக்கும்.

சோதனை எவ்வாறு அமைக்கப்பட்டது

இரண்டு அமைப்புகளும் OpenAI-ன் embedding மாடலால் உருவாக்கப்பட்ட, ஒவ்வொன்றும் 1536 பரிமாணங்களைக் (dimensions) கொண்ட அதே 100k வெக்டர்களைத் தரம் (index) செய்தன. நாங்கள் தரவு உள்ளீட்டு வேகம் (ingestion speed), வட்டு பயன்பாடு (disk usage), ஒற்றை-திரி வினவல் தாமதம் (single-thread query latency) மற்றும் எட்டு ஒரே நேரத்தில் இயங்கும் கிளையன்களுடன் கூடியத் திறன் (throughput) ஆகியவற்றை அளவிட்டோம்.

நேரடி முடிவுகள்

  • தரவு உள்ளீட்டு வேகம் (Ingestion speed) – LanceDB 22× முன்னிலையைப் பதிவு செய்தது.
  • வட்டு பயன்பாடு (Disk footprint) – LanceDB, pgvector பயன்படுத்திய இடத்தின் ஏறத்தாழ மூன்றில் ஒரு பங்கு அளவில் வெக்டர்களைச் சேமித்தது.
  • ஒற்றை-திரி தாமதம் (Single-thread latency) – LanceDB-இல் வினவல்கள் (queries) சுமார் இரண்டு மடங்கு வேகமாக இயங்கின.
  • ஒரே நேரத்தில் இயங்கும் திறன் (Concurrency scaling) – எட்டு இணையான கிளையன்களுடன் (parallel clients), pgvector LanceDB-ஐ விட 1.8× அதிகத் திறனை (throughput) வழங்கியது.

வேறுபாடுகளின் கட்டமைப்பு காரணங்கள் (Architectural roots)

LanceDB என்பது பயன்பாட்டைத் தாங்கி நிற்கும் Python செயல்முறைக்குள் (process) இயங்கும் ஒரு embedded library ஆகும். அனைத்துச் செயல்பாடுகளும் அந்தச் செயல்முறைக்குள்ளேயே இருப்பதால், தரவு ஒருபோதும் நெட்வொர்க் எல்லையைத் தாண்டாது மற்றும் மிகக் குறைந்த கூடுதல் சுமையுடன் (overhead) இன்டெக்ஸ் புதுப்பிக்கப்படுகிறது. இந்த வடிவமைப்பு ஒற்றை-பணிப் பணிச்சுக்குகளுக்கு (single-task workloads) சிறப்பாகச் செயல்படுகிறது, ஆனால் பல Python திரிகள் (threads) Global Interpreter Lock (GIL)-க்காகப் போட்டியிடும்போது ஒரு வரம்பைச் சந்திக்கிறது; இது Python bytecode-ன் உண்மையான இணையான செயல்பாட்டைத் தடுக்கிறது.

pgvector என்பது சர்வர் பக்கத்தில் PostgreSQL-ஐ விரிவுபடுத்துகிறது. ஒவ்வொரு கிளையன்ட் இணைப்பும் ஒரு தனி சர்வர் செயல்முறையைத் தொடங்குகிறது, இது GIL-ஐ முற்றிலும் தவிர்க்கிறது. PostgreSQL planner ஒரு ஒற்றுமைத் தேடலை எவ்வாறு பூர்த்தி செய்வது என்பதைத் தீர்மானிக்கிறது, மேலும் சர்வர் ஒரே நேரத்தில் வரும் கோரிக்கைகளுக்குச் சேவை செய்ய பல செயல்முறைகளைத் தொடங்க முடியும். இந்தத் தனிமைப்படுத்தல் (isolation), பணிச்சுமையின் கீழ் சிறந்த அளவீட்டுத் திறனை (scaling) விளக்குகிறது.

வடிகட்டுதல் மற்றும் வினவல் திட்டமிடல் நுணுக்கங்கள் (Filtering and query planning quirks)

நிஜ உலக RAG குழாய்கள் (pipelines) பெரும்பாலும் வெக்டர் ஒற்றுமையுடன் பாரம்பரிய வடிகட்டிகளையும் (எ.கா., WHERE user_id = 42) இணைக்கின்றன. LanceDB ஒரு prefilter-ஐப் பயன்படுத்துகிறது, இது ஒவ்வொரு முறையும் கணிக்கக்கூடிய வகையில் செயல்படுகிறது. pgvector, PostgreSQL-ன் query planner-ஐச் சார்ந்துள்ளது, இது புள்ளிவிவரங்களைப் (statistics) பொறுத்து ஒரு வேகமான index scan-ஐத் தேர்ந்தெடுக்கலாம் அல்லது மெதுவான exact scan-க்கு மாறலாம். ஒரு pgvector அட்டவணையை மொத்தமாக ஏற்றிய பிறகு ANALYZE-ஐ இயக்குவது அந்தப் புள்ளிவிவரங்களைப் புதுப்பிக்கும்; அது இல்லையென்றால், recall கிட்டத்தட்ட பூஜ்ஜியத்திற்குத் குறையக்கூடும், இது தேடலைத் திறம்பட முறித்துவிடும்.

ஒவ்வொரு விருப்பமும் எப்போது பொருத்தமானது

pgvector-ஐத் தேர்ந்தெடுக்கவும், ஒருவேளை

  • உங்கள் stack ஏற்கனவே PostgreSQL-ஐக் கொண்டிருந்தால் மற்றும் மற்றொரு சேவையைச் சேர்ப்பதைத் தவிர்க்க விரும்பினால்.
  • நீங்கள் பல ஒரே நேரப் பயனர்கள் அல்லது API அழைப்புகளை எதிர்பார்க்கிறீர்கள் என்றால்.
  • ACID உத்தரவாதங்கள் மற்றும் தெரிந்த DBA கருவிகள் முக்கியம் என்றால்.

LanceDB-ஐத் தேர்ந்தெடுக்கவும், ஒருவேளை

  • உங்கள் பணிப்பாய்வு (workflow) அடிக்கடி புதிய embeddings-களைப் பெறும் ஒரு ML pipeline ஆக இருந்தால்.
  • ஒற்றை-கோரிக்கை ஏஜெண்டுகளுக்கு (எ.கா., chat bots) மிக வேகமான write path மற்றும் குறைந்த தாமதம் தேவைப்பட்டால்.
  • வட்டுச் செலவு ஒரு கவலையாக இருந்து, ஒற்றை-திரி செயல்திறன் வரம்பைத் தாங்கிக்கொள்ள முடியும் என்றால்.

சுருக்கமாக: மூலத் தரவு உள்ளீட்டு வேகம் (raw ingestion speed), குறைந்தபட்ச சேமிப்பு மற்றும் ஒற்றை-கோரிக்கை தாமதம் ஆகியவை மிக முக்கியமானவை என்றால், LanceDB வெற்றி பெறுகிறது. நீங்கள் ஒரே நேரத்தில் பல பயனர்களுக்குச் சேவை செய்ய வேண்டும் மற்றும் ஏற்கனவே உள்ள PostgreSQL பயன்பாட்டைச் சார்ந்திருக்க வேண்டும் என்றால், pgvector-ன் ஒரே நேரத்தில் இயங்கும் திறன் (concurrency edge) அதை ஒரு பாதுகாப்பான தேர்வாக மாற்றுகிறது. உங்கள் தயாரிப்பின் மிக முக்கியமான அளவீட்டிற்கு (metric) ஏற்ப ஸ்டோரைத் தேர்ந்தெடுக்க இந்த பெஞ்ச்மார்க்கின் எண்களைப் பயன்படுத்தவும்.