CobbleDB: குறைந்த தாமதம் மற்றும் செலவுக்காக AI தேடல் சேமிப்பகத்தை மறுவடிவமைத்தல்

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

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

DynamoDB போன்ற managed databases நம்பகமான storage-ஐ வழங்கின, ஆனால் தரவு எவ்வாறு சேமிக்கப்படுகிறது மற்றும் reads எவ்வாறு வழங்கப்படுகின்றன என்பதில் எங்களுக்குக் குறைந்த கட்டுப்பாடே இருந்தது; மேலும் பயன்பாடு-அடிப்படையிலான விலை நிர்ணயம், எங்களின் index அளவும் query அளவும் அதிகரித்ததுடன் உயர்ந்தது. தனியாக, எங்களின் முந்தைய pipeline document processing-ஐ serving database-க்கு நேரடியாக இணைத்திருந்தது; இதனால் live reads-இல் இருந்து சுயாதீனமாக updates-ஐ நிர்வகிப்பது கடினமாக இருந்தது.

புதிய உள் கோடிங் ஏஜெண்ட் கூட்டத்தின் உதவியுடன், கீ-வேல்யூ ஹாட் ஸ்டோரான CobbleDB ஐச் சுற்றி இந்த அடுக்கை மீண்டும் உருவாக்கினோம், நீடித்த ஆவண நிலை மற்றும் வெளியீட்டிற்கான Pillar மற்றும் தொகுதி புதுப்பிப்புகளுக்கான Lorry ஆகியவற்றால் ஆதரிக்கப்படுகிறது. மறுவடிவமைப்பு ஆவணச் செயலாக்கத்தை ஹாட்-ஸ்டோர் உள்ளெடுப்பிலிருந்து பிரிக்கிறது மற்றும் எங்கள் பணிச்சுமைக்கு சேவையை மாற்றியமைக்க அனுமதிக்கிறது. உற்பத்திக்கு முந்தைய மற்றும் பிந்தைய அளவீடுகள் தோராயமாக 5× குறைந்த தொகுதி-வாசிப்பு தாமதத்தைக் காட்டுகின்றன, மேலும் எங்கள் உள் செலவு மாதிரி DynamoDB ஐ விட குறைந்தது 20% சேமிப்பை மதிப்பிடுகிறது.

AI-சொந்த தேடலுக்கான சேமிப்பக உள்கட்டமைப்பு

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

Raw HTML-ஐ model-ready content ஆக மாற்ற, எங்களின் processing pipeline ஒவ்வொரு page-யையும் சுத்தப்படுத்துகிறது, அதைப் பொருளரீதியாக ஒத்த passages-ஆகப் பிரிக்கிறது, அவற்றின் embeddings-ஐ கணக்கிடுகிறது, மற்றும் passages-உம் embeddings-உம் ஒன்றாக database-இல் சேமிக்கிறது. query நேரத்தில், serving pipeline query-க்கு மிகவும் தொடர்புடைய text-ஐத் தேர்ந்தெடுத்து அதை model-க்கு அனுப்புகிறது.

இரண்டு தனித்துவமான பணிப்பாய்வுகள்

அதனால் storage layer, வெவ்வேறு தேவைகளைக் கொண்ட இரண்டு பணிப்பாய்வுகளை ஆதரிக்க வேண்டும்: processing pipeline-இலிருந்து updates-ஐ ingest செய்வது மற்றும் குறைந்த-தாமத reads-ஐ வழங்குவது.

Write side-இல், புதிய pages தொடர்ந்து வருகிறன, ஏற்கனவே உள்ள pages மாறுகின்றன, மேலும் chunking methods அல்லது embedding models-இல் ஏற்படும் மாற்றங்கள் corpus-இன் பெரிய பகுதிகளை reprocessing செய்ய வேண்டிய தேவை ஏற்படுத்தலாம். storage layer இந்த updates-ஐ durable document state-இல் இணைக்க வேண்டும், தற்போதைய versions-ஐ கண்காணிக்க வேண்டும், சரியான representations-ஐ downstream systems-க்கு வெளியிட வேண்டும், மேலும் raw crawl-இலிருந்து முழு pipeline-ஐ மீண்டும் இயக்காமல் பெரிய backfills-ஐ ஆதரிக்க வேண்டும்.

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

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

நிர்வகிக்கப்பட்ட தரவுத்தளம் எங்கு தோல்வியடைகிறது

விநியோகிக்கப்பட்ட தரவுத்தளத்தை இயக்கும் சுமை இல்லாமல் DynamoDB எங்களுக்கு உயர் கிடைக்கும் சேமிப்பகத்தை (high available storage) வழங்கியது. வினவல் நேர வாசிப்புகளுக்காக பத்திகள் மற்றும் எம்படிங்குகளை ஒரு பிரத்யேக தயாரிக்கப்பட்ட பக்கங்கள் அட்டவணை வைத்திருந்தது, அதே நேரத்தில் முழு பக்க உள்ளடக்கமும் மெட்டாடேட்டாவும் தனித்தனியாக சேமிக்கப்பட்டன. இருப்பினும், எங்கள் பணிச்சுமை வளர்ந்தபோது, மூன்று தடைகள் முக்கியமானதாக மாறின.

முதலில், பயன்பாடு சார்ந்த விலை வாசிக்கப்பட்ட அல்லது எழுதப்பட்ட ஒவ்வொரு பைட்டுக்கும் கட்டணம் வசூலிக்கிறது. ஒற்றை தேடல் API கோரிக்கையில் நாம் பெற வேண்டிய பக்கங்களுக்கு ஒத்த 100-120 கீ-கள் உள்ளன. தரவு மீட்டெடுப்பு செயல்முறை ஒரு கோரிக்கையை 10-20 பக்க கீ-களின் சிறிய தொகுதிகளாகப் பிரிக்கிறது, சராசரி உருப்படி அளவு சுமார் 50 KB ஆகும். அந்தப் பதிவுகளை மீண்டும் மீண்டும் படிப்பது கணிசமான திறனை உட்கொண்டது, அதே நேரத்தில் தொடர்ச்சியான கிரால்கள் மற்றும் சங் அல்லது எம்படிங் மாதிரிகளில் மாற்றங்கள் அதிக எழுத்துக்களை உருவாக்கின. API அழைப்புகளின் எண்ணிக்கை மட்டுமல்லாமல், பதிவுகளின் அளவு மற்றும் அதிர்வெண்ணையும் பொருளாதாரம் சார்ந்துள்ளது.

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

மூன்றாவதாக, processing நேரடியாக hot-store writes-க்கு இணைக்கப்பட்டிருந்தது. எங்களின் முந்தைய processing pipeline ஒவ்வொரு prepared page-யையும் நேரடியாக DynamoDB-க்கு எழுதினது. ஆகையால், ஒரு பெரிய reprocessing job என்பது individual hot-store updates-இன் ஒரு அலை ஆகிவிடும்; மேலும் processing, hot store-இன் throughput limits மற்றும் retry நடத்தை ஆகியவற்றுக்கு ஏற்ப அமைக்கப்பட வேண்டியிருந்தது. 1-2 நாட்களில் முழு database-ல் MapReduce இயக்கி புதிய chunking முறையைச் சோதிக்கவும், எங்களின் embedding model-ஐ மாற்றவும், அல்லது புதிய field ஒன்றைச் சேர்க்கவும் எங்களால் முடியவில்லை. தனி service ஒன்று தன் சொந்த வேகத்தில் hot store-க்கு batch செய்து வழங்கக்கூடிய saved page updates-இன் independent stream எதுவும் இல்லை.

இந்தத் தடைகளைக் கையாள்வதற்கு தரவுத்தளத்தை மாற்றுவதை விட அதிக தேவைப்பட்டது. நீடித்த ஆவண நிலை மற்றும் புதுப்பிப்பு விநியோகத்தை வினவல் நேர சேமிப்பகத்திலிருந்து பிரிக்க வேண்டியிருந்தது, பின்னர் ஹாட் ஸ்டோரை குறிப்பாக வேகமான தொகுதி வாசிப்புகளுக்கு உகந்ததாக்க வேண்டும்.

தனித்த ஆவண நிலை, புதுப்பிப்பு விநியோகம் மற்றும் சேவை செய்தல்

புதிய கட்டமைப்பு ஒவ்வொரு பொறுப்பையும் வெவ்வேறு கூறுக்கு ஒதுக்குகிறது. Pillar நீடித்த ஆவண நிலையைப் பராமரிக்கிறது மற்றும் என்ன வெளியிட வேண்டும் என்பதை முடிவு செய்கிறது. Lorry அந்த ஏற்றுமதிகளை பார்ட்டிஷன் செய்யப்பட்ட தொகுதிகளாக மாற்றுகிறது. CobbleDB தொகுதிகளை உள்ளெடுக்கிறது மற்றும் பக்க கீ மூலம் தயாரிக்கப்பட்ட பதிப்புகளுக்கு சேவை செய்கிறது.

விரிவாக்கு

CobbleDB: மாற்றியமைக்கக்கூடிய வாசிப்புப் பாதை

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

முக்கியமான மாற்றம் சேமிப்பக உள்ளமைவு மீதான எங்கள் கட்டுப்பாடாகும்.

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

ஒவ்வொரு தரவு node-க்கும் partitions-இன் ஒரு துணைத்தொகுதி ஒதுக்கப்படுகிறது. அந்த node தனது தரவை RocksDB மூலம் சேமிக்கிறது; இது batch ingestion மூலம் வழங்கப்படும் read-heavy workloads-க்கு மிகவும் ஏற்ற, open-source embedded key-value storage engine ஆகும்.

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

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

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

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

விரிவாக்கு

Pillar மற்றும் Lorry: நீடித்த எழுதும் பாதை

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

Pillar ஆனது YTsaurus ஆல் ஆதரிக்கப்படுகிறது. இது பக்கக் கூறுகளை (மெட்டாடேட்டா, சங் மற்றும் எம்படிங்குகள் போன்றவை) தனித்த YTsaurus அட்டவணை குடும்பங்களில் சேமிக்கிறது. இது சங் மற்றும் எம்படிங்குகளின் பதிப்புகளையும் கண்காணிக்கிறது, அடிப்படை மாதிரிகள் மாறக்கூடிய வகையில் பல பிரதிநிதித்துவங்கள் ஒன்றுக்கொன்று மேலெழுதாமல் இணைந்து esist செய்ய அனுமதிக்கிறது. Pillar மற்றும் YTsaurus மலிவான HDD சேமிப்பகத்தைப் பயன்படுத்துவதால், நாம் முன்பு DynamoDB இல் சேமித்ததை விட பல ஆவணங்களை சேமிக்க முடியும்.

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

சரியான தன்மையை உறுதி செய்வதற்காக அட்டாமிக் YTsaurus பரிவர்த்தனைகள் நிலை (state), ஏற்றுமதி நோக்கங்கள் (export intents) மற்றும் பயன்படுத்தப்பட்ட உள்ளீடு ஆகியவற்றை உள்ளடக்கியுள்ளவை. ஒரு பரிவர்த்தனை வெற்றிகரமாக நிறைவடைய, அமைப்பு நீடித்த நிலையைப் புதுப்பிக்க வேண்டும், உள்ளீடு கணக்கிடப்பட்டதாகக் குறிக்க வேண்டும், மற்றும் தேவையான அனைத்து ஏற்றுமதிகளையும் வரிசைப்படுத்த வேண்டும்; பரிவர்த்தனை ரத்துசெய்யப்பட்டால், எந்த அடுக்கிலும் மாற்றம் செய்யப்படாது.

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

Lorry மற்றும் Cobble இடையே, ஒரு கூடுதல் நெறிமுறையானது தரவுத் தளத்தை (S3) கட்டுப்பாட்டுத் தளத்திலிருந்து பிரிக்கிறது. Lorry தொகுதியை ஒரு தனித்துவமான அடையாளத்தின் கீழ் S3 இல் எழுதி Cobble இல் தொகுதியைப் பதிவு செய்கிறது. அடுத்த S3 தொகுதியை உள்ளெடுக்க Cobble பார்ட்டிஷன் பிரதிகள் தொகுதி அல்லது கட்டுப்பாட்டுத் தள API ஐ சுயமாக வினவுகின்றன மற்றும் காலவரிசைப்படி தொகுதி புதுப்பிப்புகளை ஒத்திசைவற்ற முறையில் প্রয়োগ செய்கின்றன. இதன் பொருள் என்னவென்றால், மெதுவான அல்லது மீண்டு வரும் முனையம் அமைப்பின் மற்ற பகுதிகளை மெதுவாக்குவதற்குப் பதிலாக அதன் சொந்த வேகத்தில் பிடிக்கலாம்.

விரிவாக்கு

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

சரிபார்ப்பு

5x வேகமானது

ஹாட் ஸ்டோரை இடம்பெயர்ந்த பிறகு, சராசரி தொகுதி-வாசிப்பு (batch-read) தாமதம் 31.4 மி.நொடியிலிருந்து 5.60 மி.நொடியாகக் குறைந்தது. p90 மதிப்பு 56.7 மி.நொடியிலிருந்து 9.77 மி.நொடியாகவும், p99 மதிப்பு 123 மி.நொடியிலிருந்து 24.2 மி.நொடியாகவும் குறைந்தது. வழக்கமான கோரிக்கைகள் மற்றும் டெயில் இரண்டிலும் மேம்பாடுகளுடன், விகிதங்கள் 5.08× முதல் 5.80× வரை உள்ளன.

விரிவாக்கு

இந்த எண்கள் தொகுக்கப்பட்ட வாசிப்புகளிலிருந்து பெறப்பட்டவை, இதில் ஒவ்வொரு வினவலும் தோராயமாக 10-15 கீ-களைக் கோருகிறது. சராசரி பேலோட் உருப்படி அளவு 50KB ஆகும். எந்தச் சிதைவும் இல்லாமல் 500k rps வரை சுமை சோதனைகளை நாங்கள் நடத்தினாலும், இரண்டு அமைப்புகளும் தோராயமாக 200k rps இல் வினவப்பட்டன.

CobbleDB-ன் பங்களிப்பைத் தனிமைப்படுத்த, அமைப்பின் மற்ற அனைத்து அம்சங்களும் மாறாமல் வைக்கப்பட்டன. இருப்பினும், இது தற்போதைய அவதானிப்பு சார்ந்த ஒப்பீடே ஆகும்; கட்டுப்படுத்தப்பட்ட நிபந்தனைகளின் கீழ் ஒரே கோரிக்கைகளுக்குப் பதிலாக, இந்த அமைப்புகள் வெவ்வேறு நேரங்களில் நேரலை தயாரிப்பு ட்ராஃபிக்கிற்கு சேவை செய்தன. எனவே செயற்கையான அளவுகோலிலும் (synthetic benchmark) இரண்டு அமைப்புகளின் செயல்திறனை நாங்கள் அளந்தோம். உற்பத்தியில் காணப்பட்ட கோரிக்கைகளை நெருங்குவதற்காக, 10-15 கீ-கள் மற்றும் 100B முதல் 100 KiB வரையிலான மதிப்புகளைக் கொண்ட தொகுதிகளுடன் இரண்டையும் வினவினோம்.

விரிவாக்கு

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

20% மலிவானது

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

சேமிப்பக அளவு, எழுது திறன் அலகுகள் மற்றும் வாசிப்பு திறன் அலகுகள் பற்றிய உள் மதிப்பீடுகளின் அடிப்படையில் செலவு சேமிப்புகளைக் கணக்கிட்டோம். ஒவ்வொரு உறுதிமொழி அடுக்கிலும், DynamoDB ஐ விட CobbleDB குறைந்தது 20% மலிவானது. சுருக்கத்திலிருந்து சாத்தியமான காப்புப்பிரதி சேமிப்புகளை இந்த முடிவுகள் கணக்கில் எடுத்துக்கொள்ளாததால், உண்மையான சேமிப்புகள் இன்னும் அதிகமாக இருக்கக்கூடும்.

AI ஏஜெண்டுகளின் கூட்டம் அதை உருவாக்க எவ்வாறு உதவுகிறது

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

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

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

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

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

முடிவுரை

CobbleDB ஒரு பொது-நோக்க தரவுத்தளம் அல்ல; அது asynchronous processing pipeline மூலம் வழங்கப்படும், முன் தயாரிக்கப்பட்ட page records-இன் மீண்டும் மீண்டும் நிகழும் batch reads என்ற எங்கள் குறிப்பிட்ட workload-க்கு purpose-built ஆகும். durable state, update delivery, மற்றும் query-time serving ஆகியவற்றை பிரித்து வைத்ததால், maintenance பணியை live query path-க்கு தள்ளாமல், அனைத்தையும் ஒரே database interface-க்கு பொருத்த வைக்க கட்டாயப்படுத்தாமல், ஒவ்வொரு பொறுப்பையும் தனித்தனியாக optimize செய்ய முடிகிறது. CobbleDB-க்கு இடம்பெயர்ந்தது median மற்றும் tail latency இரண்டையும் குறிப்பிடத்தக்க அளவில் மேம்படுத்தியதுடன், infrastructure செலவுகளையும் குறைத்தது.

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

நாங்கள் விரைவில் CobbleDB ஐ ஓப்பன் சோர்ஸ் செய்ய திட்டமிட்டுள்ளோம், இதனால் AI-சொந்த தேடல் அமைப்புகளை உருவாக்கும் பிற குழுக்கள் எங்கள் தயாரிப்புகளுக்குள் தேடலை வேகமாகவும் மலிவாகவும் மாற்றும் அதே சேமிப்பக அடுக்கிலிருந்து பயனடையலாம்.

மேற்கோள்

@online{perplexity2026Cobbledb,
  author = {{Perplexity} and Alexandr Yarats and Marco Montagna and Aleksei Bykov and Alexey Gusev and Ali Abdullaev and Amir Mokhammed-Ali and Andrey Zosimov and Denis Kremko and Gleb Vishnevsky and Micah Zirn and Phi Hoang and Claire Beamer and Jeremy Yang and Jerry Ma and Denis Yarats},
  title = {{CobbleDB: Rebuilding AI search storage for lower latency and cost}},
  date = {2026-09-14},
  url = {https://www.perplexity.ai/hub/blog/cobbledb}
}