ஃபோட்டான்: முதன்முதலில் இருந்து மீட்டெடுப்பு மற்றும் தரவரிசை என்ஜினை உருவாக்குதல்

அறிமுகம்

Perplexity இன் AI-சொந்த தேடல் ஸ்டாக் வேட்பாளர் பக்கங்களை மீட்டெடுத்து தரவரிசைப்படுத்துகிறது, மாடல் அதன் பதில்களைத் தரைமட்டமாக்க மிகவும் பொருத்தமான உள்ளடக்கத்தை வெளிப்படுத்துகிறது. ஆரம்பத்தில், இந்த கட்டம் எங்கள் அமைப்புக்கு நாங்கள் மாற்றியமைத்த ஓபன் சோலார் என்ஜினில் இயங்கியது. இருப்பினும், எங்கள் இன்டெக்ஸ் மற்றும் பணிச்சுமைகள் வளர்ந்தபோது, செலவுகள், டெயில் லேட்டன்சி மற்றும் நோடு மீட்பு நேரம் ஆகியவற்றில் கடிமான வரம்புகளைத் தாக்கினோம், அவற்றை ஏற்கனவே இருக்கும் மூன்றாம் தரப்பு பிளாட்ஃபார்மிற்குள் தீர்க்க முடியவில்லை.

இந்த சவால்களை சமாளிக்க, நாங்கள் ஒரு புதிய இன்-ஹவுஸ் மீட்டெடுப்பு மற்றும் தரவரிசை என்ஜினான ஃபோட்டானை உருவாக்கினோம். பக்க ரெக்கார்டுகளுக்கு சேவை செய்வதற்கான எங்கள் விநியோகிக்கப்பட்ட கியூ-வேல்யூ ஸ்டோரான CobbleDB மற்றும் எங்கள் Search API உடன் நாங்கள் செய்தது போல், ஏஐ-முதல் தேடல் உள்கட்டமைப்பை முதன்முதலில் இருந்து உருவாக்கும் எங்கள் அணுகுமுறையை இது தொடர்கிறது.

Photon, ஒவ்வொரு வினவலுக்கும் தேவையானதை மட்டும் படித்து டிகோடு செய்ய, சுருக்கமான தரவு வடிவங்களைப் பயன்படுத்துகிறது. இதனால் batch-aware caching மற்றும் asynchronous reads மூலம் டிஸ்க் அணுகல் குறைந்து, காத்திருக்கும் நேரங்கள் ஒன்றுடன் ஒன்று மேலோங்குகின்றன. index building, query serving-இலிருந்து தனியாக இயங்கி, ஒரு serving group-ஐ ஒரே நேரத்தில் ஒன்றாகப் புதுப்பித்து, live queries-ஐ அதற்குத் திசைதிருப்புவதற்கு முன் அதன் caches-ஐ warm செய்கிறது.

ஃபோட்டான் இப்போது எங்கள் தேடல் பைப்லைனை இயக்குகிறது மற்றும் எங்கள் தேடல் ஏபிஐ-க்கான புதிய ஃபாஸ்ட் ப்ரீசெட்டின் அடிப்படையாகவும் உள்ளது, p50 இல் 160 மி.வி மற்றும் p95 இல் 230 மி.வி ஒற்றை-தேடல்-கால் லேட்டன்சி கொண்டது. ஆறு பொது பெஞ்ச்மார்க்குகளில், ஃபாஸ்ட் ப்ரீசெட், இயல்புநிலை ப்ரீசெட்டுக்கு ஒப்பிடக்கூடிய ஒட்டுமொத்த பணித் தரத்தைப் பராமரிக்கும் அதே வேளையில், பணி ஒன்றுக்கான மதிப்பிடப்பட்ட மாடல்-பிளஸ்-தேடல் செலவை 68% குறைத்தது. டெவலப்பர்கள் இந்த மேம்பாடுகளை அணுகும் வகையில் நாங்கள் அதை இன்று வெளியிடுகிறோம்.

விரிவாக்கு

விரிவாக்கு

மீட்டெடுப்பு மற்றும் தரவரிசை என்ஜினுக்கு என்ன தேவை

ஒவ்வொரு வினவலுக்கும், மீட்டெடுப்பு மற்றும் தரவரிசை என்ஜின், தேடல் ஸ்டா்க்கின் லேட்டன்சி வரம்பிற்குள் சிறிய அளவிலான பொருத்தமான பக்கங்களைத் தேர்ந்தெடுத்து வரிசைப்படுத்த பெரிய, விநியோகிக்கப்பட்ட இன்டெக்ஸைத் தேடுகிறது. புதிய பக்கங்கள் வரும்போதும் ஏற்கனவே உள்ள பக்கங்கள் மாறும்போதும், அந்த வேலை நேரலை வினவல்களை மெதுவாக்க அனுமதிக்காமல், இன்டெக்சை புதுப்பித்த நிலையில் வைத்திருக்க வேண்டும்.

நாங்கள் பல ஓபன் சோர்ஸ் விருப்பங்களை மதிப்பீடு செய்து, எங்கள் ஆரம்ப தேவைகளைப் பூர்த்தி செய்த முதிர்ந்த, பொதுவான நோக்கத்திற்கான மீட்டெடுப்பு மற்றும் தரவரிசை என்ஜினைத் தேர்ந்தெடுத்தோம். பின்னர் அதை எங்கள் கட்டமைப்பு மற்றும் பணிச்சுமைகளுக்கு ஏற்ப மாற்றியமைத்து, உற்பத்தி அளவில் நிலையான லேட்டன்சியையும் த்ரூபுட்டையும் பராமரித்தோம்.

எங்கள் முந்தைய அமைப்பு எங்கு பற்றாக்குறையாக இருந்தது

எங்கள் வளர்ந்து வரும் இன்டெக்ஸிற்கு ஏற்ப என்ஜினை மாற்றியமைக்க எங்கள் சொந்த ஃபோர்க்கைப் பராமரித்தோம், ஆனால் முக்கிய வரம்புகளை நிவர்த்தி செய்வதற்கு பிளாட்ஃபார்மின் பெரிய பகுதிகளை மறுவடிவமைப்பு செய்வது zunehmend தேவையானது. அடிப்படை கட்டமைப்பு மாற்றங்கள் இல்லாமல் பல கட்டுப்பாடுகளை தீர்ப்பது கடினமாக இருந்தது:

1. அளவிடுதல் செலவுகள். நாம் சேமிக்கும் ஆவணங்களின் எண்ணிக்கையும், மீட்டெடுத்து தரவரிசைப்படுத்த வேண்டிய ஆவண வாரியான தரவின் அளவும் காலப்போக்கில் வளர்ந்து வருகின்றன. இந்த அளவிடுதல் எங்கள் வன்பொருள் மீது அழுத்தத்தை ஏற்படுத்தியது, குறிப்பாக கிடைக்கக்கூடிய RAM இன் அளவு. செலவுகளைக் கட்டுப்படுத்த, எங்களுக்கு மிகவும் காம்பாக்ட் ஆன தரவு பிரதிநிதித்துவங்களும், நினைவகத்தில் எவை தங்கியிருக்கும் மற்றும் வட்டில் இருந்து தேவைக்கேற்ப எவை படிக்கப்படும் என்பதைக் குறித்த சிறந்த கட்டுப்பாடும் தேவைப்பட்டது.

2. மோசமான டெயில் லேட்டன்சி. தயாரிப்பு டிராஃபிக்கில், பழைய அமைப்பின் p99 பதில் நேரம் தோராயமாக 800 மி.வி இருந்தது. டேட்டாசெட் கிடைக்கக்கூடிய RAM ஐ விட அதிகமாக இருந்தது, எனவே அதை முழுமையாக நினைவகத்தில் வைத்திருக்க எங்களால் mlock ஐப் பயன்படுத்த முடியவில்லை. குடியுரிமை அல்லாத தரவை அணுகுவது பெரிய பக்க பிழைகளை (page faults)த் தூண்டலாம், இயக்க முறைமை வட்டில் இருந்து படிக்கும்போது வினவல் செயலாக்கத்தை நிறுத்தி வைக்கும்.

என்ஜின் அவ்வப்போது அதன் முக்கிய வட்டு இன்டெக்சை நினைவகத்தில் இருந்து பறிக்கப்பட்ட சிறிய இன்டெக்சுகளுடன் இணைத்தது. இந்த வட்டு இன்டெக்ஸ் இணைவு செயல்முறையின் போது, பக்க பிழைகளின் எண்ணிக்கை இன்னும் அதிகமாக உயர்ந்தது, 10-15 நிமிடங்களுக்கு p99 லேட்டன்சி தோராயமாக 1.2 வினாடிகளை எட்டியது. கேச்சுகள் சூடானவுடன், பக்க பிழைகளின் அதிர்வெண்டும் லேட்டன்சியும் இரண்டும் குறைந்தன, கோல்டு ரீடுகள் ஸ்பைக்குகளுக்கு முக்கிய பங்களிப்பாக இருந்தன என்பதை இது பரிந்துரைக்கிறது. தரவை முன்கூட்டியே ஏற்றுவது மற்றும் இன்டெக்சை சூடாக்குவது ஸ்பைக்குகளைக் குறைத்தது ஆனால் உயர் டெயில் லேட்டன்சியை போதுமான அளவு நிவர்த்தி செய்யவில்லை.

3. நீண்ட மீட்பு மற்றும் ஒத்திசைவு. முந்தைய அமைப்பில், கூடுதல் கிளஸ்டரை வரிசைப்படுத்துவது மற்றும் அதன் தரவை ஒத்திசைப்பது ஒரு வாரத்திற்கும் மேல் ஆகலாம். கூடுதல் தரவு நகல்களை வைத்திருக்க முட்குழுக்களைச் சேர்க்கும்போது அல்லது முடக்கம் தோல்விகளில் இருந்து மீட்கும்போது ஒத்திசைவு தேவையாக இருந்தது. மீட்கும் போது, தேடல் பதில்களின் பெரிய பங்கு பகுதியாக இருந்தது, இது இறுதி-பதில் தர மதிப்பெண்களைக் குறைத்தது.

இறுதியில், எங்கள் ஃபோர்க்கைத் தொடர்ந்து மாற்றிமைத்து பராமரிப்பதை விட, புதிதாக உருவாக்குவது எளிமையாகவும் மலிவாகவும் இருக்கும் என்று நாங்கள் முடிவு செய்தோம். முந்தைய கணினியை இயக்கிய எங்கள் அனுபவத்திலிருந்து, ஃபோட்டானை உருவாக்க ஒரு சிறிய இன்ஜினியரிங் குழு தொடர்ச்சியான கோடிங் ஏஜென்ட் கூட்டத்துடன் இணைந்து பணியாற்றியது.

தேடல் ஸ்டாக்கில் ஃபோட்டான் எங்கு பொருந்துகிறது

ஃபோட்டான் இரண்டு முதன்மை பணிப்பாய்வுகளுக்காக வடிவமைக்கப்பட்டுள்ளது: தேடல் கோரிக்கைகளுக்கு சேவை செய்தல் மற்றும் செயலாக்க பைப்லைனில் இருந்து புதுப்பிப்புகளை உறிஞ்சுதல்.

உயர் மட்ட தேடல் சேவையிலிருந்து வரும் கோரிக்கை, லோட் பேலன்சர் மூலம் ஃபோட்டான் புரோக்கரை அடைகிறது. புரோக்கர் ஒரு ஷார்டு குழுவைத் தேர்ந்தெடுத்து கோரிக்கையை ஒவ்வொரு ஷார்ட்டுக்கும் அனுப்புகிறது, காலாவதி நேரங்களைக் கண்காணித்து தேவைப்படும்போது கூடுதல் கோரிக்கைகளை வெளியிடுகிறது.

ஒவ்வொரு ஷார்ட்டும் மீட்டெடுப்பு, ஆரம்ப தரவரிசை மற்றும் இரண்டாம் கட்ட தரவரிசையைச் செய்கிறது, பின்னர் அதன் சிறந்த வேட்பாளர்களை புரோக்கருக்குத் தருகிறது. புரோக்கர் இந்த வேட்பாளர்களை ஒற்றை தரவரிசைப்படுத்தப்பட்ட பட்டியலாக இணைத்து, தொடர்புடைய ஷார்ட்களில் இருந்து தேர்ந்தெடுக்கப்பட்ட பக்கங்களுக்கு முக்கிய ஆவண ஃபீல்டுகளைப் பெறுகிறது. இது இந்த முடிவுகளை உயர் மட்ட தேடல் சேவைக்குத் தருகிறது, இது ஏஜென்ட் தரைமட்டமாக்கப்பட்ட பதிலை உருவாக்கத் தேவையான பக்க உள்ளடக்கத்தைச் சேகரிக்கிறது.

இன்டெக்ஸ் புதுப்பிப்புகள் தனித்த Vவழிமுறையைப் பின்பற்றுகின்றன. எங்கள் பப்ளிஷிங் லேயரான பில்லர், தரவைத் தயாரித்து YTsaurus அட்டவணைகளில் சேமிக்கிறது. இன்டெக்ஸர்கள் இந்த அட்டவணைகளை தேடலுக்காக ஷார்ட்கள் ஏற்றக்கூடிய இன்டெக்ஸ் கட்டமைப்புகளாக மாற்றுகின்றன. கன்ட்ரோலர் தரவு தயாரிப்பு, இன்டெக்ஸ் உருவாக்கம் மற்றும் சர்விங் குழுக்களுக்கு புதிய இன்டெக்ஸ் பதிப்புகளின் வரிசைப்படுத்தல் ஆகியவற்றை ஒருங்கிணைக்கிறது. நேரலை டிராஃபிக்கைக் கையாள்வதற்கு முன்பு, ஒவ்வொரு ஷார்ட்டும் அதன் கேச்சுகளை சூடாக்க உண்மையான தேடல் வினவல்களை மீண்டும் இயக்குகிறது.

விரிவாக்கு

எங்கள் பணிப்பாய்வுகளுக்காக ஃபோட்டானை வடிவமைத்தல்

மூன்று வடிவமைப்பு தேர்வுகள் ஃபோட்டானை எங்கள் பணிச்சுமைக்கு மிகவும் பொருத்தமானதாக ஆக்குகின்றன: காம்பாக்ட் தரவு பிரதிநிதித்துவங்கள், கேச்சிங் மற்றும் ஒத்திசைவற்ற வட்டு ரீடுகள், மற்றும் இன்டெக்ஸ் புதுப்பிப்புகளை வினவல் வழங்குவதில் இருந்து பிரித்தல்.

மீட்டெடுப்பு மற்றும் தரவரிசைக்கான தரவு பிரதிநிதித்துவங்கள்

மீட்டெடுப்பு மற்றும் தரவரிசை (retrieval and ranking) ஆவணத் தரவை வித்தியாசமாக அணுகுகின்றன. அகராதி மீட்டெடுப்பு வினவல் டெர்ம்களுடன் தொடங்கி அவற்றைக் கொண்ட ஆவணங்களைக் கண்டறிகிறது. அதன் பிறகு தரவரிசைக்கு டெர்ம் அதிர்வெண்கள் மற்றும் நிலைகள் உட்பட ஒவ்வொரு தேர்ந்தெடுக்கப்பட்ட ஆவணம் பற்றிய விரிவான தகவல் தேவைப்படுகிறது.

இந்த அணுகுமுறை வடிவங்களை ஆதரிக்க ஃபோட்டான் இரண்டு நிரப்பு பிரதிநிதித்துவங்களைப் பயன்படுத்துகிறது. ஒரு இன்வெர்ட்டட் இன்டெக்ஸ் ஒவ்வொரு டெர்முக்கும் பொருந்தக்கூடிய ஆவணங்களின் பட்டியலைச் சேமிக்கிறது, இது வேட்பாளர் தேர்வை ஆதரிக்க போஸ்டிங் பட்டியல் என்று அழைக்கப்படுகிறது. தனித்த ஆவண வாரியான ரெக்கார்டுகள் தரவரிசைக்குத் தேவையான தரவை வழங்குகின்றன. நிலையான வேலை வரம்பிற்குள் தேர்வை மேம்படுத்த போஸ்டிங் பட்டியல்கள் எவ்வாறு சேமிக்கப்பட்டு travers செய்யப்படுகின்றன என்பதையும் நாங்கள் உகப்பாக்குகிறோம்.

சிறப்பு தரவு பிரதிநிதித்துவங்கள் முக்கிய தரவை மிகவும் திறமையாக சேமிக்க நமக்கு உதவுகின்றன. மிகவும் காம்பாக்ட் ஆன இன்வெர்ட்டட் இன்டெக்ஸ் ஒவ்வொரு வினவலுக்கும் படிக்கப்படும் அல்லது நகர்த்தப்படும் தரவின் அளவைக் குறைக்கிறது, தேவையற்ற I/O செயல்பாடுகளை நீக்குவதன் மூலம் லேட்டன்சியை மேம்படுத்துகிறது. இந்த வடிவங்கள் ஒரு ஆவணம் ஒரு பட்டியலில் தோன்றுகிறதா என்பதை அதை முழுமையாக டீகோட் செய்யாமல் சரிபார்க்க சாத்தியமாக்குகின்றன, நிலையான பட்ஜெட்டின் கீழ் ஒரு வினவல் எவ்வளவு வேலையைச் செய்கிறது என்பதைக் கட்டுப்படுத்த எங்கள் டிராவர்சல் லாஜிக் நம்பியிருக்கும் ஒரு பண்பு இதுவாகும். ஆவண வாரியான ரெக்கார்டுகளை மேம்படுத்துவது தரவரிசைக்கு ஆவணத்திற்கு அதிக தரவை சேமிக்க அனுமதிக்கிறது, அதே நேரத்தில் நமது முந்தைய அமைப்புடன் தொடர்புடைய அளவிடுதல் செலவுகளையும் குறைக்கிறது.

இன்வெர்ட்டட் இன்டெக்ஸ்

ஒவ்வொரு டெர்முக்கும், இன்வெர்ட்டட் இன்டெக்ஸ் ஒரு போஸ்டிங் பட்டியலைச் சேமிக்கிறது. இந்தப் பட்டியல்கள் ஒரு சில ஆவணங்கள் முதல் மில்லியன் கணக்கானவை வரை இருக்கலாம், எனவே எந்த ஒற்றை வடிவமும் ஒவ்வொரு பட்டியலுக்கும் நன்றாக வேலை செய்யாது. டெர்மைக் கொண்டிருக்கும் ஆவணங்களின் எண்ணிக்கையின் அடிப்படையில் ஃபோட்டான் வடிவத்தைத் தேர்ந்தெடுக்கிறது.

குறுகிய பட்டியல்கள் ஒற்றை பக்கத்திற்குள் பொருந்தக்கூடிய மற்றும் பிளாக் அட்டவணை தேவையில்லாத இன்லைன் பிரதிநிதித்துவத்தைப் பயன்படுத்துகின்றன. இன்லைன் வடிவத்திற்குப் பொருந்தாத நீண்ட பட்டியல்கள் ஆவண அடையாளங்களின் நிலையான வரம்புகளை உள்ளடக்கிய பிளாக்குகளாகப் பிரிக்கப்படுகின்றன. ஒவ்வொரு பிளாக்கின் பிரதிநிதித்துவமும் அதன் அடர்த்தியைப் பொறுத்தது: ஸ்பார்ஸ் பிளாக்குகள் வரிசைப்படுத்தப்பட்ட ஆவண-ஐடி ஆஃப்செட்டுகளின் வரிசைகளைச் சேமிக்கின்றன, அதே நேரத்தில் டென்ஸ் பிளாக்குகள் பிட்மேப்களைப் பயன்படுத்துகின்றன. ஸ்பார்ஸ் பிளாக்குகள் கேலோப்பிங் தேடலைப் பயன்படுத்துகின்றன, இது பட்டியலின் பகுதிகளைத் தவிர்க்க பெருகிய முறையில் பெரிய படிகளில் முன்னேறும். டென்ஸ் பிளாக்குகள் ஆவணத்திற்கு ஒத்த பிட்டைப் பார்ப்பதன் மூலம் மெம்பர்ஷிப் சோதனைகளை அனுமதிக்கின்றன.

ஒரு டெர்மின் வினவல் அதிர்வெண் அதன் போஸ்டிங் பட்டியல் வட்டில் எங்கு வைக்கப்பட்டுள்ளது என்பதைத் தீர்மானிக்கிறது. அடிக்கடி வினவப்படும் பட்டியல்கள் ஒன்றுக்கொன்று அருகில் சேமிக்கப்படுகின்றன, சூடான தரவை சிறிய சேமிப்பகப் பகுதியில் செறிவூட்டுகின்றன. ஒவ்வொரு பட்டியலிலும், ஆவணங்கள் ஒரு தனி பயனுள்ள சமிக்ஞையால் வரிசைப்படுத்தப்படுகின்றன, இதனால் அதிக நம்பிக்கைக்குரிய வேட்பாளர்கள் முன்னதாகவே சந்திக்கப்படுகிறார்கள்.

விரிவாக்கு

ஒரு work budget-க்குள் lists-ஐ traversing

வேட்பாளர் தேர்தலுக்கு சாத்தியமான பொருத்தமான ஆவணங்களைக் கண்டறிய போஸ்டிங் பட்டியல்களைத் travers செய்வது தேவைப்படுகிறது. ஒவ்வொரு பட்டியலையும் முழுமையாக ஸ்கேன் செய்வது விலை உயர்ந்தது, எனவே ஃபோட்டான் WAND போன்ற அல்காரிதத்தைப் பயன்படுத்துகிறது, இது மற்றவற்றில் உள்ள பொருத்தங்களைக் கணக்கிடும் போது சில பட்டியல்களை மட்டுமே travers செய்கிறது.

அல்காரிதம் பட்டியல்களை இரண்டு குழுக்களாகப் பிரிக்கிறது. டிரைவிங் பட்டியல்கள் டிராவர்சலை முன்னேற்றி வேட்பாளர் ஆவணங்களை பரிந்துரைக்கின்றன. ப்ரோப் பட்டியல்கள் அந்த வேட்பாளர்களின் மதிப்பெண்களுக்கு பங்களிக்கின்றன ஆனால் அவையே வேட்பாளர்களை உருவாக்குவதில்லை.

வேட்பாளர் மதிப்பெண் கணக்கிடுதல் என்பது எடையிடப்பட்ட வினவல்-டெர்ம் கவரேஜ் மற்றும் அதிர்வெண் பங்களிப்பை ஒருங்கிணைக்கிறது, ஆவண-நீள இயல்பாக்கம் மற்றும் மீண்டும் மீண்டும் வரும் டெர்ம்களில் இருந்து பெறப்படும் லாபங்களுக்கான வரம்புடன். ஒவ்வொரு வேட்பாளரின் அதிகபட்ச சாத்தியமான மதிப்பெண்ணைக் கட்டுப்படுத்த ஃபோட்டான் முதலில் அரேக்கள் மற்றும் பிட்மேப்களில் டெர்ம் இருப்பதைச் சரிபார்க்கிறது. தேர்வுத் தகுதியை இன்னும் பூர்த்தி செய்யக்கூடிய வேட்பாளர்களுக்கு மட்டுமே அது சரியான டெர்ம் அதிர்வெண்களைப் படிக்கிறது.

தேர்வு பின்னர் மூன்று படிகளில் தொடர்கிறது:

• டிராவர்சல்: கடுமையான வினவல்-கவரேஜ் தேவையுடன் தொடங்குங்கள். மிகக் குறைவான வேட்பாளர்கள் கண்டறியப்பட்டால், தளர்வான தேவையுடன் மீண்டும் செய்யவும்.
• தக்கவைப்பு: கவரேஜ் மற்றும் அதிர்வெண்டை ஒருங்கிணைக்கும் மதிப்பெண்ணைப் பயன்படுத்தி வேட்பாளர்கள் கட்டுப்படுத்தப்பட்ட தொகுப்பில் வைக்கப்படுகிறார்கள். சேகரிக்கப்பட்ட டாப் வேட்பாளர்கள் மேம்படும் போது, அட்மிஷன் த்ரெட்டோல்ட் அதிகரிக்கிறது.
• இறுதித் தேர்வு: பாஸிற்கான இறுதி முடிவுகள் அதிர்வெண் மதிப்பெண்களின் அடிப்படையில் தக்கவைக்கப்பட்ட தொகுப்பிலிருந்து தேர்ந்தெடுக்கப்படுகின்றன. ஒவ்வொரு ஃபீல்டும் அதன் சொந்த பாஸை இயக்குகிறது, மேலும் முடிவுகள் ஃபீல்டு எடைகளைப் பயன்படுத்தி இணைக்கப்படுகின்றன.

அல்காரிதம் மேலும் தரவரிசைப்படுத்த பயன்படுத்தப்பட வேண்டிய பொருத்தமான ஆவணங்களின் வேட்பாளர் தொகுப்பை உருவாக்குகிறது.

விரிவாக்கு

Docblob

வேட்பாளர் பக்கங்கள் தேர்ந்தெடுக்கப்பட்ட பிறகு, தரவரிசை கட்டத்திற்கு டெர்ம் அதிர்வெண்கள், ஃபீல்டு கவரேஜ் மற்றும் நிகழ்வுகளின் இருப்பிடங்கள் மற்றும் அருகாமை ஆகியவை தேவைப்படுகின்றன. இன்வெர்ட்டட் இன்டெக்ஸ் மூலம் இந்தத் தரவைப் பெறுவதற்கு பல டெர்ம்-ஆவண ஜோடிகளில் சிதறிய அணுகல்கள் தேவைப்படும். ஃபோட்டானில், டெர்ம் அதிர்வெண்கள், டெர்ம் தோன்றிய ஃபீல்டுகள் மற்றும் ஆவணத்தில் அது எங்கு நிகழ்ந்தது ஆகியவற்றைக் கொண்ட docblob எனப்படும் காம்பாக்ட் ஆவண வாரியான ரெக்கார்டைச் சேமிக்கிறோம். இதன் விளைவாக, ஒரு வேட்பாளரை தரவரிசைப்படுத்த ஆவணத்திற்கு ஒரு லுக்அப் மட்டுமே தேவைப்படுகிறது.

தேவைக்கு மேல் டீகோடிங் செய்வதைத் தவிர்க்க இந்த வடிவம் உருவாக்கப்பட்டுள்ளது. docblob க்குள், ஃபீல்டுகள் உரை அனலைசர் மூலம் தொகுக்கப்படுகின்றன. ஒவ்வொரு குழுவும் Elias-Fano உடன் குறியிடப்பட்ட வரிசைப்படுத்தப்பட்ட டெர்ம் பட்டியலைச் சேமிக்கிறது, இதனால் முழு பட்டியலையும் முதலில் விரிவாக்காமல் ஒரு வினவல் டெர்மை நேரடியாகத் தேட முடியும். ஒரு ஃபீல்டு மாஸ்க் ஒரு டெர்ம் எங்கு நிகழ்ந்தது என்பதைக் குறிக்கிறது, ஒரு அதிர்வெண் எண்ணிக்கை எவ்வளவு அடிக்கடி என்பதைக் கண்காணிக்கிறது, மற்றும் உண்மையான நிலைகள் நிலை வேறுபாடுகளாக குறியிடப்பட்ட டெர்ம்-ஃபீல்டு ஜோடிக்கு தனித்தனி பிளாக்குகளில் வாழ்கின்றன. உண்மையில் பொருந்திய டெர்ம்களுக்கான பிளாக்குகள் மட்டுமே டீகோட் செய்யப்படுகின்றன, அதே நேரத்தில் ரெக்கார்டில் உள்ள மற்றவை சுருக்கப்பட்ட வடிவத்திலேயே இருக்கும்.

அந்தத் தேர்ந்தெடுக்கப்பட்ட டீகோடிங், docblob ஆனது விகிதாசார செலவு அதிகரிப்பு இல்லாமல் ஆவணத்திற்கு அதிக தரவைச் சேமிப்பதை ஆதரிக்க அனுமதிக்கிறது. ரெக்கார்டை வளர்ப்பது ஒரு லுக்அப்பிற்கு அதிக வேலையை கட்டாயப்படுத்துவதில்லை, ஏனெனில் ரேங்கிங் ஆனது முழு ரெக்கார்டைக் காட்டிலும் பொருந்திய டெர்ம்களுக்கு பொருத்தமான பகுதிகளை மட்டுமே எப்போதும் தொட்கிறது.

விரிவாக்கு

தொகுதி ரீடுகளும் நினைவகத்துடன் வேலை செய்வதும்

மிகவும் திறமையான தரவு பிரதிநிதித்துவங்களுடன் கூட, மற்ற வளங்களுக்கு முன்பே RAM தீர்ந்துவிடுகிறது, எனவே வட்டில் சேமிக்கப்பட்ட தரவை நாம் அடிக்கடி அணுக வேண்டியுள்ளது. இந்த அணுகல்களை விரைவுபடுத்த ஃபோட்டான் ஒத்திசைவற்ற வட்டு ரீடுகளையும் தொகுதி ரீடுகளுக்காக உகப்பாக்கப்பட்ட கேச்சையும் பயன்படுத்துகிறது, கோரிக்கைக்கான காத்திருப்பு நேரத்தைக் குறைக்கிறது. முந்தைய அமைப்புடன் ஒப்பிடும்போது டெயில் லேட்டன்சியில் குறிப்பிடத்தக்க முன்னேற்றத்திற்கு இது பங்களிக்கிறது.

விரிவாக்கு

மேற்பொருந்தும் வட்டு காத்திருப்பு நேரங்கள்

தரவரிசைக்கு ஒரு கோப்பின் வெவ்வேறு பகுதிகளில் அமைந்துள்ள நூறு ஆவணங்களின் அம்சங்களைப் பெறுவது தேவைப்படுகிறது. எங்கள் முந்தைய அமைப்பு கோப்பை மெய்நிகர் முகவரி வெளியில் மேப் செய்ய mmap ஐப் பயன்படுத்தியது, இதனால் அதை நினைவக சுட்டிகள் மூலம் படிக்க முடியும். இருப்பினும், நினைவகத்தில் இல்லாத பக்கத்தை அணுகுவது இன்னும் வட்டு ரீட் தேவைப்பட்டது. கணக்கீட்டைத் தொடர்வதற்கு முன்பு த்ரெட் தரவுக்காகக் காத்திருக்க வேண்டியிருந்தது, மேலும் செயல்முறை கோல்டு ரெக்கார்டுகளை வரிசையாகப் படிக்க வேண்டியிருந்தபோது இந்த காத்திருப்பு நேரம் சேர்ந்தது.

ரெக்கார்ட் ஆஃப்செட்டுகள் முன்கூட்டியே தெரியும் என்ற உண்மையை ஃபோட்டான் (Photon) பயன்படுத்துகிறது, இதனால் நம்மால் ஒரே நேரத்தில் பல ரீடுகளை (reads) சமர்ப்பிக்க முடியும். இது விடையியற்றியால் (reactor) நிர்வகிக்கப்படுகிறது: பிரத்யேகமான வொர்க்கர் த்ரெட்டுகள் io_uring மூலம் தொகுப்புகளை (batches) சமர்ப்பித்து, தாங்கள் படித்த தரவைக் calling கோப்பிற்கு அனுப்புகின்றன. ஒவ்வொரு த்ரெட்டும் அதன் சொந்த io_uring ஐப் பராமரிக்கிறது; தொகுப்புகள் குறைந்த சுமை கொண்ட விடையியற்றிக்கு அனுப்பப்படுகின்றன. முன்கூட்டியே பதிவுசெய்யப்பட்ட கோப்பு டெஸ்கிரிப்டர்களும் பஃபர் கூட்டமைப்புகளும் (buffer pools) மீண்டும் மீண்டும் செய்யப்படும் ரீடுகளின் ஓவர்ஹெட்டை (overhead) குறைக்கின்றன. இந்த ஒத்திசைவற்ற (asynchronous) செயல்பாடு பல செயல்பாடுகளுக்கான காத்திருப்பு நேரங்கள் ஒன்றுடன் ஒன்று மேற்பொருந்த அனுமதிக்கிறது, இதனால் டெயில் லேட்டன்சி (tail latency) குறைகிறது.

டிரைவ் அணுகல்களின் எண்ணிக்கையைக் குறைத்தல்

ரீடுகளை சமர்ப்பிப்பதற்கு முன்பு, ஃபோட்டான் இன்-மெமரி கேச்சில் முழு தொகுப்பையும் சரிபார்க்கிறது. விடுபட்ட ரெக்கார்டுகளுக்கான கோரிக்கைகள் மட்டுமே வட்டுக்குச் செல்கின்றன; படித்த தரவு பின்னர் கேச்சை நிரப்புகிறது.

கேச் தொகுக்கப்பட்ட ரீடுகளுக்காக வடிவமைக்கப்பட்டுள்ளது. குறிப்பாக:

• ஹிட்டில் தனி ஒதுக்கீடு இல்லை. மாறாக, அழைக்கும் குறியீட்டால் முன்கூட்டியே தயாரிக்கப்பட்ட பஃபரில் தரவு நகலெடுக்கப்படுகிறது.
• வாசகரால் லாக் கையகப்படுத்தல் இல்லை. மாறாக, இது தரவு பதிப்பைச் சரிபார்த்து, அது ரைட்டுடன் முரண்பட்டால் மீண்டும் முயற்சிக்கிறது.
• இது ஒவ்வொரு ரீட்டிலும் பகிரப்பட்ட LRU பட்டியலுக்கான புதுப்பிப்புகளைக் கோருவதற்குப் பதிலாக CLOCK எவிக்ஷனைப் பயன்படுத்துகிறது.
• இது சிபியு (CPU) கேச் ப்ரீஃபெட்சிங்கைப் (prefetching) பயன்படுத்துகிறது, இதில் வரவிருக்கும் ரெக்கார்டுகளுக்கான மெட்டாடேட்டாவும் தரவும் முன்கூட்டியே கோரப்படுகின்றன.

இந்த உகப்பாக்கங்கள் நாம் அக்கறை கொள்ளும் பணிச்சுமைகளில் செயல்திறனைப் பாதிக்காமல் லேட்டன்சியைக் குறைக்கின்றன.

சேவை செய்வதில் இருந்து இன்டெக்சை உருவாக்குவதும் புதுப்பிப்பதும் தனித்தனியாக

ஃபோட்டானில், இன்டெக்ஸ் உருவாக்கம் மற்றும் வினவல் வழங்குதல் ஆகியவை வெவ்வேறு முடுகளில் இயங்குகின்றன. இன்டெக்ஸர்கள் தரவை தயாரான சேமிப்பக கட்டமைப்புகளாக மாற்றுகின்றன, அதே நேரத்தில் சர்விங் நோடுகள் அவற்றைப் படித்து மீட்டெடுப்பு மற்றும் தரவரிசையைச் செய்கின்றன. இதன் விளைவாக, இன்டெக்ஸ் உருவாக்கம் சிபியு-விற்காக தேடல் வினவல்களுடன் போட்டியிடுவதில்லை, மேலும் இந்தப் பணிகளுக்கான வளங்களை independently அளவிட முடியும்.

இந்தப் பிரிவு முந்தைய செயலாட்டத்தில் இருந்த மீட்பு மற்றும் ஒத்திசைவு இடையூறுகளை நிவர்த்தி செய்கிறது. வினவல்களுக்கு சேவை செய்த அதே கிளஸ்டருக்குள்ளேயே இன்டெக்ஸ் உருவாக்கம் இயங்கியதால், தோல்வியடைந்த முடையை மீட்டெடுப்பது அல்லது தரவின் புதிய நகலைச் சேர்ப்பது ஆவணங்களை அங்கேயே மீண்டும் இன்டெக்ஸ் செய்வதைக் குறிக்கலாம், இந்தச் செயல்முறை நாட்கள் ஆனது மற்றும் மீட்பின் போது பகுதி பதில்களை அதிகரித்தது. ஃபோட்டான் அந்த இணைப்பை நீக்குகிறது; இன்டெக்ஸர்கள் சர்விங் நோடுகளில் இருந்து independently பதிப்பு செய்யப்பட்ட, சேவைக்கு தயாராக உள்ள இன்டெக்ஸ் கட்டமைப்புகளை உருவாக்கும் விநியோகிக்கப்பட்ட வேலைகளாக இயங்குகின்றன, எனவே இன்டெக்டின் அடுத்த பதிப்பை உருவாக்குவது இனி நேரலை டிராஃபிக்குடன் போட்டியிடுவதில்லை.

விரிவாக்கு

தயாரிப்பு மற்றும் விநியோகிக்கப்பட்ட உருவாக்கம்

ஒரு உருவாக்கம் என்பது செயலில் உள்ள இன்டெக்ஸிற்கான ஆவணங்களைத் தேர்ந்தெடுத்து மூல ஏற்றுமதியை உருவாக்குவதன் மூலம் தொடங்குகிறது. கன்ட்ரோலர் மூலப் பதிப்பு, உள்ளீட்டு அட்டவணைகள் மற்றும் எதிர்பார்க்கப்படும் ஷார்ட்களின் எண்ணிக்கையைப் பதிவு செய்கிறது. YTsaurus இல் உள்ள MapReduce வேலைகள் உரை, மெட்டாடேட்டா, துண்டுகள், அம்சங்கள் மற்றும் முன்கூட்டியே கணக்கிடப்பட்ட உட்பொதிப்புகளை ஷார்டு வாரியாகப் பிரிக்கப்பட்ட பதிப்பு அட்டவணைகளாகத் தயார்படுத்துகின்றன. ஒவ்வொரு இன்டெக்ஸரும் தயாரிக்கப்பட்ட அட்டவணையை ஸ்ட்ரீம் செய்கிறது, அதன் ஷார்ட்க்கான கட்டமைப்புகளை உருவாக்குகிறது மற்றும் உரைப் பகுதிகளை இணைக்கிறது. தயாராக உள்ள இன்டெக்ஸ், அதன் கூறுகளின் விளக்கத்துடன் சேர்த்து, ஆப்ஜெக்ட் ஸ்டோரேஜில் பதிவேற்றப்படுகிறது.

ஷார்டு எண்ணிக்கை மற்றும் ஒரே நேரத்தில் இயங்கும் இன்டெக்ஸர்களின் எண்ணிக்கை ஆகியவை independiente ஆக கட்டமைக்கப்படுகின்றன, எனவே ஒரு உருவாக்கம் பல அலைகளில் இயங்கலாம், அல்லது பல கணினிகள் இணையாக வேலை செய்ய ஒதுக்கப்படலாம். விநியோகிக்கப்பட்ட தயாரிப்பு மற்றும் இணை இன்டெக்ஸர்கள் முழு வலை இன்டெக்ஸையும் ஒற்றை இலக்க மணிநேரங்களில் உருவாக்க அனுமதிக்கின்றன, இது முந்தைய கணினியுடன் ஒப்பிடும்போது குறிப்பிடத்தக்க முன்னேற்றமாகும்.

புதிய பதிப்பை வரிசைப்படுத்துதல்

வரிசைப்படுத்துவதற்கு முன்பு, புதிய இன்டெக்ஸ் தயாராக உள்ளதா என்பதை கன்ட்ரோலர் சரிபார்க்கிறது. தரவு முழுமையடையவில்லை என்றால், வரிசைப்படுத்துதல் தானாகவே தடுக்கப்படும்.

பல சர்விங் குழுக்கள் இருக்கும்போது, கன்ட்ரோலர் அவற்றை ஒவ்வொன்றாகப் புதுப்பிக்கிறது. இது முதலில் ஒரு குழுவை புரோக்கர் ரூட்டிங்கில் இருந்து அகற்றி புதிய இன்டெக்ஸ் பதிப்பில் தொடங்குகிறது. கோரிக்கைகளுக்கு சேவை செய்வதற்கு முன்பு, ஷார்ட்கள் தேடல் பதிவுகளின் அடிப்படையில் ஒரு தனி வார்மப் கட்டத்தின் மூலம் செல்கின்றன, இது ஆரம்பநிலையை முன்கூட்டியே நிரப்புகிறது மற்றும் உண்மையான டிராஃபிக்கிற்கான மாற்றத்தை மென்மையாக்குகிறது. வார்மப்பிற்குப் பிறகு, கன்ட்ரோலர் இன்டெக்ஸ் நிலையையும் readiness ஐயும் சரிபார்த்து, பின்னர் குழுவை ரூட்டிங்கிற்குத் தருகிறது. மற்ற குழுக்கள் இந்த நேரத்தில் கோரிக்கைகளுக்கு சேவை செய்வதைத் தொடர்கின்றன. செயல்பாட்டு நிலை நிலைநிறுத்தப்படுவதால், மறுதொடக்கம் ஒரு உருவாக்கத்தை புதிதாகத் தொடங்க கட்டாயப்படுத்தாது; கன்ட்ரோலர் ஏற்கனவே நடந்து கொண்டிருக்கும் தயாரிப்புடன் மீண்டும் இணைக்கலாம், தயாராக உள்ள முடிவை மீண்டும் பயன்படுத்தலாம் அல்லது சேமிக்கப்பட்ட படியிலிருந்து தடைபட்ட சுழற்சியைத் தொடரலாம்.

தரவு புதுப்பிக்கும் நேரங்கள் தேடல் செங்குத்துகளில் வேறுபடுகின்றன. அதிக புத்துணர்ச்சி தேவைகளைக் கொண்ட செங்குத்துகளுக்கு, ஆவண விநியோகம் ஒற்றை இலக்க நிமிடங்களை எடுக்கும். தரவின் கூடுதல் நகலை அரை மணி நேரத்தில் வரிசைப்படுத்தலாம்; மூல ஆவணங்களை மீண்டும் இன்டெக்ஸ் செய்யாமல் தயாராக உள்ள இன்டெக்ஸ்கள் ஷார்ட்களில் ஏற்றப்பட்டு இணைக்கப்படுகின்றன.

விரிவாக்கு

எங்கள் தேடல் ஸ்டாக்கிற்குள் இடம்பெயர்தல் மற்றும் சரிபார்த்தல்

பதில் நேரங்களைக் குறைக்கும் அதே வேளையில் செயல்பாடு மற்றும் தேடல் தரத்தைப் பாதுகாத்த ஒரு என்ஜின் மூலம் பழைய அமைப்பை மாற்றுவதே எங்கள் முதல் இலக்காகும். நேரலை டிராஃபிக்கிற்குச் செல்வதற்கு முன்பு, மீண்டும் உருவாக்கக்கூடிய சுமை சோதனைகள் மற்றும் ஆஃப்லைன் தர மதிப்பீடுகளுடன் தொடங்கி, பல கட்டங்களாக ஃபோட்டானைச் சரிபார்த்தோம். ஃபோட்டான் இப்போது எங்கள் உற்பத்தி தேடல் ஸ்டாக்கில் மீட்டெடுப்பு மற்றும் தரவரிசையை இயக்குகிறது, பழைய அமைப்பைக் காட்டிலும் கணிசமாகக் குறைந்த பதில் நேரங்களைக் கொண்டுள்ளது.

சுமை சோதனை மற்றும் மதிப்பீடுகள்

செயல்திறன் சோதனைக்காக, உள்ளமைக்கக்கூடிய வருகை விகிதங்களில் எங்கள் தேடல் பதிவுகளில் இருந்து வினவல்களை மீண்டும் இயக்கும் சுமை-சோதனை கருவியை உருவாக்கினோம். இது இயக்கங்கள் முழுவதும் முடிவுகளை ஒப்பிடுகிறது மற்றும் கவனிக்கப்பட்ட செயல்திறன் வேறுபாடுகள் சீரானதாக உள்ளதா என்பதை மதிப்பிட புள்ளிவிவர சோதனைகளைப் பயன்படுத்துகிறது. தனித்தனியாக, தரவு குறைபாடுகளைச் சரிபார்க்க எங்கள் உள் ஆஃப்லைன் மதிப்பீட்டு அமைப்புகளில் அதே டேட்டாசெட்டுகளில் ஃபோட்டானையும் பழைய அமைப்பையும் மதிப்பீடு செய்தோம்.

இந்த சோதனைகளுக்குப் பிறகு, ஷேடோ டிராஃபி்க்கைப் பயன்படுத்தி ஒரே நேரத்தில் இரண்டு என்ஜின்களுக்கும் நேரலை வினவல்களை அனுப்பினோம். பயனர்களுக்கு சேவை செய்யும் என்ஜினை மாற்றுவதற்கு முன்பு, உற்பத்தி பணிச்சுமைகளில் அவற்றின் செயல்திறனையும் முடிவுகளையும் ஒப்பிட்டுப் பார்க்க இது எங்களுக்கு அனுமதி அளித்தது. பின்னர் சிறு அளவிலான பயனர்களுக்கு ஃபோட்டானை இயக்கினோம், படிப்படியாக வெளியீட்டை விரிவுபடுத்தினோம், தரம் மற்றும் செயல்திறனைக் கண்காணித்தோம். முதல் பதிப்பு தர குறைபாடுகள் இன்றி ஏற்புச் சோதனையில் தேர்ச்சி பெற்றது, மேலும் அனைத்து உற்பத்தி டிராஃபிக்கிற்கும் ஃபோட்டான் சேவை செய்யும் வரை வெளியீட்டைத் தொடர்ந்தோம்.

உற்பத்தியில் அளவிடப்பட்ட மேம்பாடுகள்

எங்கள் உற்பத்தி பணிப்பாய்வில், p99 பதில் நேரம் பழைய அமைப்பில் தோராயமாக 800 மி.வி இலிருந்து ஃபோட்டானில் தோராயமாக 65 மி.வி ஆகக் குறைந்தது. இந்த அளவீடு ஃபோட்டானுக்குள் உள்ள அனைத்து கட்டங்களையும் உள்ளடக்கியது, ஆனால் உயர் மட்ட தேடல் ஸ்டாக்கில் உள்ள அடுத்தடுத்த கட்டங்களைத் தவிர்க்கிறது. இன்டெக்ஸ் பதிப்புகளை மாற்றுவதுடன் முன்பு தொடர்புடைய லேட்டன்சி ஸ்பைக்குகளையும் நாங்கள் இனி கவனிப்பதில்லை.

பழைய அமைப்பின் கன்டென்ட் மோடுகளை விட ஃபோட்டான் தோராயமாக 20% குறைவான சமமான சர்விங் கணினிகளைப் பயன்படுத்துகிறது, அதே நேரத்தில் ஆவணத்திற்கு தோராயமாக 2.5 மடங்கு அதிக தரவைச் சேமிக்கிறது. இடம்பெயர்தலுக்குப் பிறகு, பழைய அமைப்பின் தரத்திற்கு அப்பாற்பட்டு தரவரிசை தரத்தை மேம்படுத்த இந்த கூடுதல் தரவைப் பயன்படுத்தினோம்.

நினைவகத்தில் இருக்க வேண்டிய தரவின் அளவையும் ஃபோட்டான் குறைக்கிறது. RAM இல் அதே ஃபோட்டான் டேட்டாசெட்டை mlock மூலம் பின் செய்வது, ஃபோட்டான் தற்போது பயன்படுத்துவதை விட தோராயமாக 4.6 மடங்கு அதிக ரெசிடென்ட் நினைவகத்தைக் கோரும்.

வேகமான தேடல் ஏபிஐ ப்ரீசெட்டின் மதிப்பீடு

லேட்டன்சி-உணர்திறன் பணிச்சுமைகளுக்காக வடிவமைக்கப்பட்ட எங்கள் தேடல் ஏபிஐ-க்கான புதிய ஃபாஸ்ட் ப்ரீசெட்டின் அடிப்படையாக ஃபோட்டானைப் பயன்படுத்தினோம். எங்கள் அளவீடுகளின்படி, ஃபாஸ்ட் ப்ரீசெட்டிற்கான ஒற்றை-தேடல்-கால் லேட்டன்சி p50 இல் 160 மி.வி மற்றும் p95 இல் 230 மி.வி ஆகும், இது மற்ற தேடல் ஏபிஐ வழங்குநர்களின் சுய-அறிவிக்கப்பட்ட எண்களை விடக் குறைவு அல்லது ஒப்பிடத்தக்கது, இருப்பினும் அறிவிக்கப்பட்ட டெயில் பர்சென்டைல்கள் வேறுபடுகின்றன.

WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 மற்றும் SEAL-Hard ஆகிய ஆறு ஏஜென்ட் பெஞ்ச்மார்க்குகளில் ஃபாஸ்ட் ப்ரீசெட்டை மதிப்பீடு செய்தோம். இந்த மதிப்பீடுகளில், சோதிக்கப்பட்ட உள்ளமைவுகளில் இது மிகக் குறைந்த மதிப்பிடப்பட்ட மொத்த மாடல்-பிளஸ்-தேடல் செலவையும் மிக உயர்ந்த ஒட்டுமொத்த பணி மதிப்பெண்ணையும் கொண்டிருந்தது.

ஃபாஸ்ட் ப்ரீசெட் ஃபோட்டானை ஏஜென்ட் பணிப்பாய்வுகளுக்காக உகப்பாக்கப்பட்ட தரவரிசையுடன் இணைக்கிறது, கணிசமாகக் குறைந்த செலவில் இயல்புநிலை ப்ரீசெட்டிற்கு ஒப்பிடக்கூடிய செயல்திறனை வழங்குகிறது. இருப்பினும், இது பரந்த தேடல் தரத்தில் ஒரு சமரசத்துடன் வருகிறது. ஃபாஸ்ட் ப்ரீசெட் இயல்புநிலை ப்ரீசெட்டைக் காட்டிலும் தரவரிசைக்கு குறைந்த கணினியைப் பயன்படுத்துகிறது. நீண்ட-டெயில் வினவல்கள், பரந்த கவரேஜ் மற்றும் முடிவு பன்முகத்தன்மை ஆகியவற்றை உள்ளடக்கிய உள் பெஞ்ச்மார்க்குகளில், இது பொருத்தத்தன்மையில் 0.24 புள்ளிகள் குறைவாகவும், பதில் கிடைக்கும் தன்மையில் தோராயமாக 3 சதவிகித புள்ளிகள் குறைவாகவும் மதிப்பெண் பெறுகிறது. மாடலின் சொந்த பகுத்தறிதல் மற்றும் அறிவு இந்த வேறுமையை ஈடுகட்ட உதவுவதால், இது ஏஜென்ட் பணிப்பாய்வுகளுக்கு ஒரு விவேகமான சமரசம் என்று நம்புகிறோம்.

விரிவாக்கு

நாள்சரி ஏஜென்ட் பணிகளுக்கு ஃபாஸ்ட் ப்ரீசெட்டைப் பரிந்துரைக்கிறோம். நேர உணர்திறன் குறைவான மிகவும் சவாலான அல்லது தெளிவற்ற கேள்விகளுக்கு, இயல்புநிலை ப்ரீசெட் மிகவும் வலுவான தரவை வழங்குகிறது, இது அதன் அதிக லேட்டன்சி மற்றும் செலவை நியாயப்படுத்துகிறது.

முடிவுரை

எங்கள் தேடல் ஸ்டாக்கை ரஸ்ட் அடிப்படையிலான, இன்-ஹவுஸ் உள்கட்டமைப்பிற்கு சீராக நகர்த்தி வருகிறோம். ஓபன் சோர்ஸ் என்ஜினுக்கு பதிலாக எங்கள் தனிப்பயன் மீட்டெடுப்பு மற்றும் தரவரிசை என்ஜினான ஃபோட்டானை மாற்றுவது சமீபத்திய படியாகும். ஃபோட்டான் தரவு பிரதிநிதித்துவங்கள், ரீடுகள் எவ்வாறு οργανίζονται (organize), மற்றும் புதிய இன்டெக்ச்கள் எவ்வாறு வரிசைப்படுத்தப்படுகின்றன என்பதன் மீது முழுமையான கட்டுப்பாட்டை எங்களுக்கு வழங்குகிறது, ஒவ்வொரு லேயரையும் எங்கள் பணிச்சுமைகளுக்கு ஏற்ப உகப்பாக்க அனுமதிக்கிறது.

Perplexity இன் தயாரிப்புகளில் விரைவான தேடலை ஃபோட்டான் இயக்கியுள்ளது மற்றும் தேடல் ஏபிஐ-ல் எங்கள் புதிய ஃபாஸ்ட் ப்ரீசெட்டிற்கான அடிப்படையை வழங்குகிறது. இடம்பெயர்தலுக்குப் பிறகு, p99 மீட்டெடுப்பு-மற்றும்-தரவரிசை லேட்டன்சி தோராயமாக 800 மி.வி இலிருந்து 65 மி.வி ஆகக் குறைந்தது. எங்கள் காம்பாக்ட் தரவு வடிவங்கள் ஆவணத்திற்கு 2.5 மடங்கு அதிக தரவை சேமிக்கவும் அனுமதிக்கின்றன, மீட்டெடுப்பு மற்றும் தரவரிசைக்கு செழுமையான ஆவணத் தகவல்களை அணுக வழங்குகின்றன.

ஃபாஸ்ட் ப்ரீசெட் (fast preset) p50 இல் 160 மி.வி மற்றும் p95 இல் 230 மி.வி ஒற்றை-தேடல்-கால் லேட்டன்சியை வழங்குகிறது. மதிப்பீடு செய்யப்பட்ட ஆறு ஏஜென்ட் அடிப்படையிலான பெஞ்ச்மார்க்குகளில், இயல்புநிலை ப்ரீசெட்டுடன் ஒப்பிடும்போது, பணி ஒன்றுக்கான மதிப்பிடப்பட்ட மாடல்-பிளஸ்-தேடல் செலவை இது 68% குறைத்தது, அதே நேரத்தில் ஒப்பிடத்தக்க ஒட்டுமொத்த பணி தரத்தை பராமரித்தது. இந்த முடிவுகள், Perplexity இன் தயாரிப்புகளுக்கும் எங்கள் ஏபிஐ (API) மூலம் உருவாக்கும் டெவலப்பர்களுக்கும் எங்கள் தேடல் பணிச்சுமைகளைச் சுற்றி வடிவமைக்கப்பட்ட உள்கட்டமைப்பின் நடைமுறை நன்மைகளைக் காட்டுகின்றன.

ஃபோட்டானின் செயல்திறன் மற்றும் சேமிப்புத் திறனை நாங்கள் தொடர்ந்து மேம்படுத்தி வருகிறோம். எங்கள் பணிச்சுமை வளரும்போது தேடலை வேகமாகவும் அதே வன்பொருளில் பெரிய இன்டெக்ஸ் மற்றும் செழுமையான ஆவணத் தரவையும் ஆதரிப்பதே எங்கள் இலக்காகும்.

மேற்கோள்

@online{perplexity2026Photon,
  author = {{Perplexity} and Maksim Morozov and Bogdan Savko and Ruslan Kovalev and Aleksei Bykov and Artur Zayats and Denis Bykov and Nikita Kireev and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Photon: Building a retrieval and ranking engine from scratch}},
  date = {2026-09-24},
  url = {https://www.perplexity.ai/hub/blog/photon}
}