CobbleDB: Endurbygging gervigreindarleitargeymslu fyrir lægri seinkun og kostnað

Gervigreindarinnfædd leit gerir mismunandi kröfur um hvernig þarf að vinna úr, geyma og þjóna vefefni. Til að mæta þessum kröfum í stórum stíl höfum við verið að endurbyggja allan staflann frá grunni til að bæta afköst og draga úr kostnaði.

Við byggðum okkar eigin skrið-, vísunar- og röðunarinnviði, ívafningalíkön og áhrifavélar til að knýja skilvirka vinnslu og hraða þjónustu. Við erum nú að stækka þá nálgun yfir í geymslu, tengivefinn sem vinnslan skrifar í og þjónustan les frá.

Stjórnaðir gagnagrunnar eins og DynamoDB veittu áreiðanlega geymslu, en við höfðum takmarkaðst stjórn á því hvernig gögn voru geymd og lestrarenni þjónað, og notkunartengd verðlagning jókst með stærð vísis okkar og fyrirspurnamagni. Að auki tengdi fyrri leiðsla okkar skjalavinnslu beint við þjónustugagnagrunninn, sem gerði það erfitt að stjórna uppfærslum óháð lifandi lestri.

Með hjálp frá nýjum innri kóðunarumboðsmannasvarm endurbyggðum við þetta lag í kringum CobbleDB, lykil-gildis heita geymslu, sem er studd af Pillar fyrir varanlega skjalastöðu og birtingu, og Lorry fyrir lotubundnar uppfærslur. Endurhönnunin aðskilur skjalavinnslu frá inntöku í heita geymslu og gerir okkur kleift að fínstilla þjónustu við vinnuálag okkar. Mælingar fyrir og eftir í framleiðslu sýna u.þ.b. 5× lægri lotulestrarseinkun og innra kostnaðarlíkan okkar áætlar að minnsta kosti 20% sparnað miðað við DynamoDB.

Geymsluinnviðir fyrir gervigreindarinnfædda leit

Klassískur leitarstafla er smíðaður fyrir mannlegan lesanda, ekki málmíkan. Sá munur breytir kornastærðinni sem kerfið þarf til að undirbúa, geyma og þjóna vefefni.

Til að breyta hráu HTML í líkamsbúið efnihreinsar vinnsluleiðsla okkar hverja síðu, skiptir henni upp í merkingarlega samhangandi textabúta, reiknar út ívafningar þeirra og geymir textabúta og ívafningar saman í gagnagrunninum. Á fyrirspurnartíma velur þjónustuleiðslan út textann sem skiptir máli fyrir fyrirspurnina og sendir hann til líkansins.

Tvö aðskilin verkflæði

Geymslulagið verður því að styðja tvö verkflæði með ólíkar kröfur: að taka inn uppfærslur úr vinnsluleiðslunni og þjóna lágseinkunarlestri.

Á skrifhliðinni koma nýjar síður stöðugt inn, núverandi síður breytast og breytingar á bútaaðferðum eða ívafningalíkönum geta krafist endurvinnslu á stórum hluta safnsins. Geymslulagið verður að fella þessar uppfærslur inn í varanlega skjalastöðu, fylgjast með núverandi útgáfum, birta réttar framsetningar til niðurstreymiskerfa og styðja stórar bakfyllingar án þess að endurtaka alla leiðina frá hráu skriði.

Aftur á móti biðja lestrar á fyrirspurnartíma um lotur af síðulyklum og sækja samsvarandi textabút og ívafningar fyrir röðun og val á textabútum. Þessir lestrar eru á leiðinni að endanlegu svari, svo þeir þurfa að klárast hratt.

Þetta vinnuálag kallar á mismunandi hönnun. Vinnsla hagnast á varanlegum biðröðum og getu til að afhenda uppfærslur á skilvirkan hátt, endurtaka bilanir og koma núverandi færslum í lag í stórum stíl. Þjónusta hagnast á fyrirfram reiknuðum færslum, hlýjum skyndimynnum og hröðum lotulestrum með lágmarks vinnu á fyrirspurnartíma. Þétt tenging á milli þessara tveggja getur valdið því að endurheimtarvinna og stórar uppfærslur keppni við seinkunarnæma lestra.

Þar sem stýrður gagnagrunnur bregst

DynamoDB veitti okkur mjög aðgengilega geymslu án byrðarinnar af því að reka dreifðan gagnagrunn. Sérstök tafla fyrir undirbúnar síður geymdi textabúta og ívafninga fyrir lestur á fyrirspurnartíma, en fullt síðuefni og lýsigögn voru geymd sérstaklega. Hins vegar, þegar vinnuálag okkar jókst, urðu þrjár skorður mikilvægar.

Í fyrsta lagi rukkar notkunartengd verðlagning fyrir hvert bati lesið eða skrifað. Ein Leitaraðgangsbeiðni inniheldur 100-120 lykla sem samsvara síðum sem við þurfum að sækja. Gagnasóknarferlið skiptir beiðni upp í minni lotur af 10-20 síðulyklum þar sem meðalstærð hlutar er um 50 KB. Endurtekin lestur á þessum færslum eyddi verulegri afkastagetu, á meðan stöðug skrið og breytingar á búta- eða ívafningalíkönum mynduðu fleiri skrif. Hagfræðin fór einnig eftir stærð og tíðni færslna, ekki bara fjölda beiðna.

Í öðru lagi skortir stýrðu þjónustuna sveigjanleikann sem við þurfum fyrir fínstillingu afkasta. Aðgerðin sem við þurftum var þröng: gefinni lotu af síðuauðkendum, skilaðu tilbúnu innihaldi þeirra fljótt. Við vildum stjórn á því hvaða vél hélt skiptingu, hve miklu minni var varið í skyndiminni hennar og hvaða afrit tók við beiðni. Þær stýringar skipta máli vegna þess að óskyndiminni lestur, hopp yfir svæði eða hægvirkt afrit getur seinkað allri lotunni. DynamoDB stýrir sinni eigin geymslu- og afritunarhegðun á bak við forritaskilin. Við gátum stillt þjónustuna, en við gátum ekki fínstillt innri staðsetningu, skyndimynni geymsluvélar eða stefnu um val á afriti í kringum vinnuálag okkar.

Í þriðja lagi var vinnsla beintengd skrifum í heita geymslu. Fyrri vinnsluleiðsla okkar skrifaði hverja undirbúna síðu beint í DynamoDB. Stórt endurvinnsluverk varð þess vegna að öldu einstakra uppfærslna á heitri geymslu og vinnslan þurfti að taka tillit til afkastatakmarkana heitu geymslunnar og endurtilraunahegðunar. Við gátum ekki keyrt MapReduce yfir allan gagnagrunninn á 1-2 dögum til að prófa nýja bútaaðferð, breyta ívafningalíkani okkar eða bæta við nýjum reit. Það var enginn sjálfstæður straumur af vistuðum síðuuppfærslum sem sérstök þjónusta gæti safnað í lotu og afhent heitu geymslunni á sínum hraða.

Til að leysa þessar skorður þurfti meira en að skipta út gagnagrunninum. Við þurftum að aðgreina varanlega skjalastöðu og afhendingu uppfærslna frá geymslu á fyrirspurnartíma og fínstilla síðan heitu geymsluna sérstaklega fyrir hraða og lotubundna lestra.

Aðgreina skjalastöðu, afhendingu uppfærslna og þjónustu

Nýja arkitektúrinn úthlutar hverri ábyrgð á annan hluta. Pillar viðheldur varanlegri skjalastöðu og ákveður hvað á að birta. Lorry breytir þeim útflutningi í skiptingarhluta. CobbleDB tekur inn hlutana og þjónar undirbúnum færslum eftir síðulykli.

Stækka

CobbleDB: stillanlega lestrarleiðin

CobbleDB er heita geymslan okkar sem er fínstillt til að þjóna undirbúnum færslum á fyrirspurnartíma. Þetta er dreifð lykil-gildisgeymsla: lyklarnir eru auðkenni síðna (mássar vefslóðir) og gildin eru unnin framsetning síðunnar (forbútaðir textabútar þeirra og vektoraívafningar fyrir hvern bút).

Mikilvæga breytingin er stjórn okkar á geymslustillingum.

Gögnum er skipt niður ogdreifð yfir gagnahnúta. Þetta dreifða snið tryggir kwamba gagnagrunnurinn getur stækkað lárétt til að rúma gríðarstórt safn unninna síðna. Hver skipting hefur þrjú afrit á þremur mismunandi hnútum; ef ein afrit verður óaðgengileg geta hin haldið áfram að þjóna lestri.

Hverju gagnahnúti er úthlutað hlutmengi af skiptingunum. Hnúturinn geymir gögn sín með RocksDB, opnum innbyggðum lykil-gildisgeymsluvél sem hentar vel fyrir lestrardrifið vinnuálag sem nærist á lotuinntöku.

Hægt er að þjóna skyndiminni gögnum úr minni, á meðan óskyndiminni lestrar nota staðbundna NVMe geymslu. Þetta gefur okkur beina leið til að fínstilla jafnvægi minnis og disks fyrir athugað vinnuálag, í stað þess að samþykka innri skyndiminni stýrðar þjónustu.

Ríkislaus fyrirspurnarbeinir massar lykla að skiptingum og beinist beiðnum að hnútum samhliða. Arkitektúrinn inniheldur einnig PostgreSQL-studda lýsigagnapjónustu og varanlega hlutageymslu.

Þessi hönnun styður lestraarmynstrið sem vinnuálag okkar krefst. Eftir að fyrirspurn fer í gegnum leit og röðun til að fá framboðssetningu viðeigandi síðna er heitu geymslunni flett upp í lotu fyrir innihald þessara síðna. Þessar lestraarbeiðnir berast í beini og eru beindar að samsvarandi gagnahnúti. Beirinn setur í forgang að senda beiðnir á hnút á sama aðgengissvæði til að lágmarka seinkun yfir svæði, ef mögulegt er. Hver gagnahnútur getur sótt innihald síðunnar með MultiGet, RocksDB lotulestraforritaskilum sem eru hönnuð til að sækja marga lykla samtímis með lágri seinkun. Ef hnútur er hægvirkur til svörunar getur kerfið einnig spurt annað skiptingarafrit á öðrum hnúti, sem bætir endaseinkun.

Við getum einnig forðast að útfæra algenga eiginleika sem verkflæði okkar krefst ekki. Til dæmis bjóða flestir gagnagrunnar upp á samkvæmni og færslustuðning, en heita geymslan okkar krefst ekki færslna eða samstilltra afrita. Það er í lagi þótt það sé stutt bil á milli þess sem skjal er skrifað og hvenær það er aðgengilegt til lestrar, og það er líka í lagi þótt eitt afrit taki gögn inn hraðar en annað. Að sleppa eiginleikum sem við þurfum ekki dregur úr yfirbyggingu og kostnaði kerfisins.

Stækka

Pillar og Lorry: varanlega skrifleiðin

Sérstakt geymslulag heldur utan um allt sem við skriðum og vinnum, og sameinar uppfærslur í útgáfustýrða skjalastöðu og birtir nauðsynlegar framsetningar á CobbleDB og leitavísunni. Við smíðuðum Pillar, skjalastöðu- og birtingarlag okkar, í þessum tilgangi.

Pillar er knúinn áfram af YTsaurus. Hann geymir síðuhluta (eins og lýsigögn, búta og ívafningar) í sérstökum YTsaurus töflufjölskyldum. Hann fylgist einnig með útgáfum bóta og ívafninga, sem gerir kleift að margar framsetningar séu til samhliða án þess að skrifa yfir hvor aðra þannig að undirliggjandi líkön geti breyst. Þar sem Pillar og YTsaurus nota ódýra HDD geymslu getum við geymt margfalt fleiri skjöl en við geymdum áður í DynamoDB.

Pillar fylgist með hlutmengi, eða stefnumörkuðum hópum síðna eins og ferskum síðum eða hágildum síðum. Aðild að hlutmengi ákvarðar hvaða uppfærslur þurfa að fara áfram til niðurstreymisþátta eins og CobbleDB. CobbleDB notar dýrari NVMe geymslu, þannig að við flytjum aðeins út skjölin sem við viljum raunverulega nota í leitarútkomum. Þegar innihald síðu er uppfært, eða ef henni er bætt við eða hún fjarlægð úr hlutmengi, ber Pillar ábyrgð á að setja samsvarandi útflutningsverk í biðröð.

Atómugar YTsaurus færslur ná yfir stöðu, útflutningsáform og neytt inntak til að tryggja réttmæti. Til þess að færsla ljúki með góðum árangri verður kerfið að uppfæra varanlega stöðu, merkja inntak sem skráð og setja öll nauðsynleg útflutningsefni í biðröð; ef færslan er stöðvuð er engum breytingum gerðar á neinu lagi.

CobbleDB ætblast til þess að uppfærslum sé safnað í lotur samkvæmt skiptingu. Útflutningi Pillar er breytt í þetta snið af ríkislausri þjónustu sem við köllum Lorry. Eina hlutverk hennar er að lesa útflutningsfærslur úr viðvarandi skiptingartengdri biðröð, safna þeim saman í lotuskrár fyrir hverja skiptingu og afhenda þær CobbleDB.

Milli Lorry og Cobble skiptir viðbótarsamskiptaregla gagnaflatanum (S3) frá stjórnunarflatanum. Lorry skrifar lotuna í S3 undir einstökum auðkenni og skráir lotuna innan Cobble. Cobble skiptingarafrit spyrja sjálfstætt um lotu- eða stjórnunarflatarforritaskil fyrir næstu S3 lotu til að taka inn og beita lotuuppfærslum ósamstillt í tímaröð. Þetta þýðir að hægvirkur eða endurheimtandi hnútur getur náð upp á sínum hraða, í stað þess að hægja á restinni af kerfinu.

Stækka

Nýja leiðin aðgreinir tafarlausa vinnslufærslu frá inntöku í heita geymslu og býður upp á endurspilanlega leið fyrir vaxandi uppfærslur og magnendurbyggingar. Þessi verkaskipting tryggir að uppfærslur á varanlegri skjalastöðu trufli ekki seinkun lestrarleiðarinnar.

Staðfesting

5x hraðari

Eftir flutning á heitu geymslunni fór miðgildi lotulestrarseinkunar úr 31,4 ms í 5,60 ms. P90 fór úr 56,7 ms í 9,77 ms og p99 fór úr 123 ms í 24,2 ms. Hlutfallið er á bilinu 5,08× til 5,80×, með umbótum í bæði dæmigerðum beiðnum og endanum.

Stækka

Þessar tölur eru unnar úr lotulestrum, þar sem hver fyrirspurn biður um um það bil 10-15 lykla. Meðalstærð farms síðu er 50KB. Bæði kerfi voru spurð við u.þ.b. 200k rps, þó að við keyrðum einnig álagpróf upp að 500k rps án rýrnunar.

Til að einangra framlag CobbleDB voru öll önnur atriði uppsetningar látin haldast óbreytt. Hins vegar er þetta enn athugunarmiðaður samanburður fyrir og eftir; kerfin þjónuðu lifandi framleiðsluumferð á mismunandi tímum frekar en sömu beiðnum við stýrðar aðstæður. Við mældum því einnig afköst beggja kerfa á tilbúnu viðmiðunarprófi. Til að nálgast beiðnirnar sem sjást í framleiðslu spurðum við báða með lotum af 10-15 lyklum og gildum á bilinu 100B til 100 KiB.

Stækka

DynamoDB á í erfiðleikum í þessu samhengi vegna þess að stjórnað lestraarleið þess verður ekki fínstillt fyrir lotulestra af þessari stærð. Aftur á móti er CobbleDB fínstillt fyrir nákvæmlega þetta umhverfi, þar sem við stýrum staðsetningu, skyndiminni og afritunarstýringum. Það flokkar lykla eftir skiptingum, keyrir lestur samhliða gegn skiptingarafritum og getur varist hægum lestrum gegn öðrum afritum. Niðurstöður okkar sýna fram á að þessar hönnunarval skila sér í hraðari lestrum í framleiðsluumhverfi.

20% ódýrara

CobbleDB er einnig verulega ódýrara en DynamoDB. Til viðbótar við geymslu rukkar DynamoDB einnig fyrir hvert bati lesið eða skrifað. Við stærð safns okkar og þjónustuumferð verða þess töluverðu notkunartengdu gjöld stór hluti heildarkostnaðarins. Stöðugar uppfærslur eyða skrifgetu, á meðan hver lota af undirbúnum síðum sem sóttar eru fyrir fyrirspurn eyðir lestraargetu.

Við reiknuðum út kostnaðarsparnaðinn út frá innri áætlunum um geymslustærð, skrifgetueiningar og lestraargetueiningar. Á öllum skuldbindingarstigum er CobbleDB að minnsta kosti 20% ódýrara en DynamoDB. Raunverulegur sparnaður er líklega enn meiri, þar sem þessar niðurstöður taka ekki tillit til líklegs sparnaðar við öryggisafrit vegna þjöppunar.

Hvernig svarmur af gervigreindarumboðmönnum hjálpaði okkur að byggja það

Að byggja CobbleDB og umgjörð þess var engan veginn auðvelt mál. Kjarnagagnagrunnur CobbleDB einn og sér er um 40.000 línur af Rust, og flutningurinn krafðist einnig umfangsmikillar vinnu til að staðfesta réttmæti og bilunarhegðun í framleiðslustærð, samþætta CobbleDB við bæði vinnslu- og þjónustuleiðir, og skipta yfir í lifandi umferð á öruggan hátt.

Við flýttum þessu átaki með því að nota innra kerfi sem rekur svarm af kóðunarumboðsmönnum. Kerfið er hannað til að vera mjög viðvarandi; það heldur markmiðum verkefnisins, virkum áhættum, geymslusögu og fyrri ákvörðun yfir samtöl.

Við úthlutuðum hópi svona fyrirbyggjandi, sívirkra umboðsmanna til CobbleDB verkefnisins. Fyrsta verkefni þeirra var að smíða nákvæmt líkan af því verki sem þegar var í gangi. Þeir yfirfóru verkefnaþráðinn og virka þræði, tengdu framúrskarandi atriði við pull request þeirra og eigendur, og skiluðu núverandi stöðuskýrslu um heilsu kerfisins og næstu aðgerðir. Þaðan unnu þeir yfir nokkra hluta verkfræðilykkjunnar:

• Yfirfarnir kóða- og innviðabreytingar.
• Kom með hindranir á yfirborðið sem auðvelt var að missa af, þar á meðal óöruggar forsendur um endurheimt, útrunnar byggingartilvísun og stillingar sem myndu biluðu við keyrslu.
• Undirbúið markvissar lagfæringar, próf, breytingar á eftirliti og starfsgögn.
• Fylgst var með CI, yfirferð og innviðahliðum á meðan framleiðsluaðgerðum var haldið beinlínis í mannlegri eigu.
• Fylgst var með útgáfum og öryggisafrits- eða endurheimtaræfingum, og síðan borið saman athugaða kerfisstöðu við árangursviðmið útgáfunnar.
• Við héldum við stöðuskýrslum verkefnisins þannig að verkfræðingar gætu séð hvað hafði verið sent, hvað var enn stíflað og hvar mannlegs dómstóls var enn þörf.

Verkfræðingar setja samt sem áður upp arkitektúrinn, fóru yfir afleiðingaríkar breytingar og heimiluðu framleiðsluaðgerðir. Umboðsmennirnir sáu um mikinn hluta stöðugrar skoðunar og eftirfylgni á milli þessara ákvarðana. Þetta leyfði litlu teymi að keyra verkefnið á skilvirkan hátt — kjarnainnviðir CobbleDB voru smíðaðir af tveimur mannlegum verkfræðingum og hundruðum gervigreindarumboðsmanna á tveimur mánuðum.

Niðurstaða

CobbleDB er ekki almennur gagnagrunnur; hann er sérhannaður fyrir okkar sérstaka vinnuálag með endurteknum lotulestrum á undirbúnum síðufærslum, sem eru mataðar af ósamstilltri vinnsluleiðslu. Með því að aðgreina varanlega stöðu, afhendingu uppfærslna og þjónustu á fyrirspurnartíma getum við fínstillt hverja ábyrgð sjálfstætt án þess að neyða eitt gagnagrunnsviðmót til að rúma þær allar eða þrýsta viðhaldsvinnu yfir á lifandi fyrirspurnarleiðina. Að flytja yfir á CobbleDB bætti bæði miðgildi og endaseinkun verulega á meðan innviðakostnaður minnkaði.

Þegar we haldsm áfram að þróa gervigreindarinnfædd innviði innanhúss getum við fínstillt afköst og kostnað á þann hátt sem er ekki mögulegur þegar við erum bundin við útfærslur þriðju aðila og verðlagningarlíkön. Öflugir gervigreindarumboðmenn færa útreikningana enn frekar í átt að því að byggja í stað þess að kaupa.

Við stefnum á að opna CobbleDB fljótlega, þannig að önnur teymi sem byggja gervigreindarinnfædd leitarkerfi geti notið góðs af sama geymslulaginu sem gerir leit hraðari og ódýrari innan vörum okkar.

Tilvitnun

@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}
}