CobbleDB: తక్కువ లేటెన్సీ మరియు ఖర్చు కోసం AI సెర్చ్ స్టోరేజ్‌ను పునర్నిర్మించడం

వెబ్ కంటెంట్‌ను ఎలా ప్రాసెస్ చేయాలి, నిల్వ చేయాలి మరియు అందించాలి అనే దానిపై AI-నేటివ్ సెర్చ్ వివిధ అవసరాలను విధిస్తుంది. ఆ డిమాండ్‌లను పెద్ద ఎత్తున నెరవేర్చడానికి, పనితీరును మెరుగుపరచడానికి మరియు ఖర్చును తగ్గించడానికి మేము మొత్తం స్టాక్‌ను మొదటి నుండి పునర్నిర్మిస్తున్నాము.

సమర్థవంతమైన ప్రాసెసింగ్ మరియు వేగవంతమైన సర్వింగ్‌ను శక్తివంతం చేయడానికి మేము మా సొంత క్రాలింగ్, ఇండెక్సింగ్ మరియు ర్యాంకింగ్ ఇన్‌ఫ్రాస్ట్రక్చర్, ఎంబెడ్డింగ్ మోడల్స్ మరియు ఇన్ఫరెన్స్ ఇంజిన్‌లను నిర్మించాము. ప్రాసెసింగ్ వ్రాసే మరియు సర్వింగ్ రీడ్ చేసే కనెక్టివ్ టిష్యూ అయిన స్టోరేజ్‌కి మేము ఇప్పుడు ఆ విధానాన్ని విస్తరిస్తున్నాము.

DynamoDB వంటి మేనేజ్డ్ డేటాబేస్‌లు నమ్మదగిన నిల్వను అందించాయి, అయితే డేటా ఎలా నిల్వ చేయబడింది మరియు రీడ్‌లు ఎలా అందించబడ్డాయి అనే దానిపై మాకు పరిమిత నియంత్రణ ఉంది మరియు వినియోగ-ఆధారిత ధర మా ఇండెక్స్ పరిమాణం మరియు క్వెరీ వాల్యూమ్‌తో పాటు పెరిగింది. విడిగా, మా మునుపటి పైప్‌లైన్ డాక్యుమెంట్ ప్రాసెసింగ్‌ను నేరుగా సర్వింగ్ డేటాబేస్‌తో జత చేసింది, లైవ్ రీడ్‌ల నుండి స్వతంత్రంగా అప్‌డేట్‌లను నిర్వహించడం కష్టతరం చేసింది.

కొత్త internal coding agent swarm సహాయంతో, మేము ఈ layer‌ను CobbleDB అనే key-value hot store చుట్టూ తిరిగి నిర్మించాం; దీన్ని durable document state మరియు publishing కోసం Pillar, అలాగే batched updates కోసం Lorry మద్దతిస్తున్నాయి. ఈ redesign document processing‌ను hot-store ingestion నుండి వేరు చేస్తుంది మరియు serving‌ను మా workload‌కు అనుగుణంగా సర్దుబాటు చేయడానికి మాకు అవకాశం ఇస్తుంది. production ముందు-తరువాత కొలతలు batch-read latency సుమారు 5× తక్కువగా ఉందని చూపుతున్నాయి, మరియు మా internal cost model DynamoDBతో పోలిస్తే కనీసం 20% savings‌ను అంచనా వేస్తోంది.

AI-నేటివ్ సెర్చ్ కోసం స్టోరేజ్ ఇన్‌ఫ్రాస్ట్రక్చర్

క్లాసిక్ సెర్చ్ స్టాక్ అనేది భాషా నమూనా కోసం కాకుండా మానవ పాఠకుడి కోసం నిర్మించబడింది. ఆ వ్యత్యాసం సిస్టమ్ వెబ్ కంటెంట్‌ను సిద్ధం చేయడానికి, నిల్వ చేయడానికి మరియు అందించడానికి అవసరమైన గ్రాన్యులారిటీని మారుస్తుంది.

خام HTMLని మోడల్-సిద్ధమైన కంటెంట్‌గా మార్చడానికి, మా ప్రాసెసింగ్ పైప్‌లైన్ ప్రతి పేజీని శుభ్రపరుస్తుంది, దానిని సెమాంటిక్‌గా స్థిరమైన పాసేజ్‌లుగా విభజిస్తుంది, వాటి ఎంబెడ్డింగ్‌లను లెక్కిస్తుంది మరియు పాసేజ్‌లు మరియు ఎంబెడ్డింగ్‌లను డేటాబేస్‌లో కలిపి నిల్వ చేస్తుంది. క్వెరీ సమయంలో, సర్వింగ్ పైప్‌లైన్ క్వెరీకి అత్యంత సంబంధం ఉన్న టెక్స్ట్‌ను ఎంచుకుని, దానిని మోడల్‌కు పంపుతుంది.

రెండు వేర్వేరు వర్క్‌ఫ్లోలు

అందువల్ల నిల్వ లేయర్ వేర్వేరు డిమాండ్‌లతో కూడిన రెండు వర్క్‌ఫ్లోలకు మద్దతు ఇవ్వాలి: ప్రాసెసింగ్ పైప్‌లైన్ నుండి అప్‌డేట్‌లను ఇన్‌జెస్ట్ చేయడం మరియు తక్కువ-లేటెన్సీ రీడ్‌లను అందించడం.

రైట్ వైపున, కొత్త పేజీలు నిరంతరం వస్తాయి, ఇప్పటికే ఉన్న పేజీలు మారుతాయి మరియు చంకింగ్ పద్ధతులు లేదా ఎంబెడ్డింగ్ మోడళ్ల మార్పులకు కార్పస్‌లో పెద్ద భాగాలను రీప్రాసెస్ చేయడం అవసరం కావచ్చు. నిల్వ లేయర్ ఈ అప్‌డేట్‌లను మన్నికైన డాక్యుమెంట్ స్థితిలో చేర్చాలి, ప్రస్తుత వెర్షన్‌లను ట్రాక్ చేయాలి, సరైన ప్రాతినిధ్యాలను డౌన్‌స్ట్రీమ్ సిస్టమ్‌లకు ప్రచురించాలి మరియు రా క్రాల్ నుండి పూర్తి పైప్‌లైన్‌ను పునరావృతం చేయకుండా పెద్ద బ్యాక్‌ఫిల్‌లకు మద్దతు ఇవ్వాలి.

దీనికి విరుద్ధంగా, క్వెరీ-టైమ్ రీడ్‌లు పేజీ కీల బ్యాచ్‌లను అభ్యర్థిస్తాయి మరియు ర్యాంకింగ్ మరియు పాసేజ్ ఎంపిక కోసం తదనుగుణమైన పాసేజ్ టెక్స్ట్ మరియు ఎంబెడ్డింగ్‌లను తిరిగి పొందుతాయి. ఈ రీడ్‌లు తుది సమాధానానికి వెళ్లే మార్గంలో ఉంటాయి, కాబట్టి అవి త్వరగా పూర్తి కావాలి.

ఈ వర్క్‌లోడ్‌లకు వేర్వేరు డిజైన్‌లు అవసరం. ప్రాసెసింగ్ మన్నికైన క్యూలు మరియు అప్‌డేట్‌లను సమర్థవంతంగా అందించడం, వైఫ్రల్యాలను పునఃప్రయత్నించడం మరియు ఇప్పటికే ఉన్న రికార్డ్‌లను పెద్ద ఎత్తున అప్‌డేట్ చేయగల సామర్థ్యం నుండి ప్రయోజనం పొందుతుంది. సర్వింగ్ ముందుగా లెక్కించిన రికార్డ్‌లు, వార్మ్ క్యాచెస్ మరియు కనీస క్వెరీ-టైమ్ పనులతో వేగవంతమైన బ్యాచ్డ్ రీడ్‌ల నుండి ప్రయోజనం పొందుతుంది. రెండింటి మధ్య గట్టి అనుబంధం రికవరీ పని మరియు పెద్ద అప్‌డేట్‌లు లేటెన్సీ-సెన్సిటివ్ రీడ్‌లతో పోటీ పడేలా చేస్తుంది.

మేనేజ్డ్ డేటాబేస్ ఎక్కడ విఫలమవుతుంది

డిస్ట్రిబ్యూటెడ్ డేటాబేస్‌ను నిర్వహించే భారం లేకుండా DynamoDB మాకు అత్యంత అందుబాటులో ఉండే నిల్వను అందించింది. క్వెరీ-టైమ్ రీడ్‌ల కోసం అంకితమైన ప్రిపేర్డ్-పేజీల టేబుల్ పాసేజ్‌లు మరియు ఎంబెడ్డింగ్‌లను ఉంచింది, అయితే పూర్తి పేజీ కంటెంట్ మరియు మెటాడేటా విడిగా నిల్వ చేయబడ్డాయి. అయితే, మా వర్క్‌లోడ్ పెరిగేకొద్దీ, మూడు పరిమితులు ముఖ్యమైనవిగా మారాయి.

మొదటిది, వినియోగ-ఆధారిత ధర చదివిన లేదా వ్రాసిన ప్రతి బైట్‌కు ఛార్జ్ చేస్తుంది. ఒకే సెర్చ్ API అభ్యర్థనలో మనం పొందవలసిన పేజీలకు అనుగుణంగా 100-120 కీలు ఉంటాయి. డేటా పునరుద్ధరణ ప్రక్రియ అభ్యర్థనను 10-20 పేజీ కీలు ఉండే చిన్న బ్యాచ్‌లుగా విభజిస్తుంది, సగటు అంశం పరిమాణం సుమారు 50 KB ఉంటుంది. ఆ రికార్డ్‌లను పదే పదే చదవడం గణనీయమైన సామర్థ్యాన్ని వినియోగించుకుంది, అయితే నిరంతర క్రాల్‌లు మరియు చంకింగ్ లేదా ఎంబెడ్డింగ్ మోడళ్లకు మార్పులు ఎక్కువ వ్రాతలను సృష్టించాయి. API కాల్‌ల సంఖ్యపై మాత్రమే కాకుండా రికార్డ్‌ల పరిమాణం మరియు ఫ్రీక్వెన్సీపై కూడా ఎకనామిక్స్ ఆధారపడి ఉంటుంది.

రెండవది, managed serviceకు performance tuning కోసం మనకు అవసరమైన flexibility లేదు. మాకు అవసరమైన operation పరిమితమైనది: page identifiers యొక్క batch ఇచ్చినప్పుడు, వాటి prepared contents‌ను త్వరగా తిరిగి ఇవ్వడం. partition‌ను ఏ machine హోస్ట్ చేయాలి, దాని cache‌కు ఎంత memory కేటాయించాలి, మరియు request‌ను ఏ replica నిర్వహించాలి అనే వాటిపై మాకు control కావాలి. ఈ controls ముఖ్యమైనవి, ఎందుకంటే uncached read, cross-zone hop, లేదా slow replica మొత్తం batch‌ను ఆలస్యం చేయగలవు. DynamoDB API వెనుక తన own storage మరియు replica behavior‌ను నిర్వహిస్తుంది. మేము service‌ను configure చేయగలిగినా, మా workload చుట్టూ దాని internal placement, storage-engine caches, లేదా replica-selection policy‌ను tune చేయలేకపోయాం.

మూడవది, processing నేరుగా hot-store writes‌తో అనుసంధానించబడింది. మా గత processing pipeline ప్రతి prepared page‌ను నేరుగా DynamoDBలో వ్రాసేది. అందువల్ల పెద్ద reprocessing job అనేది individual hot-store updates యొక్క తరంగంలా మారేది, మరియు processing hot store యొక్క throughput limits మరియు retry behavior‌కు అనుగుణంగా ఉండాల్సి వచ్చేది. కొత్త chunking పద్ధతిని ప్రయత్నించడానికి, మా embedding model‌ను మార్చడానికి, లేదా కొత్త field జోడించడానికి, మొత్తం database‌పై 1-2 రోజుల్లో MapReduce నడపడం మేము చేయలేకపోయాం. వేరే service hot store‌కు తన స్వంత వేగంతో batch చేసి deliver చేయగల saved page updates యొక్క స్వతంత్ర stream ఏదీ లేదు.

ఈ పరిమితులను పరిష్కరించడానికి డేటాబేస్‌ను భర్తీ చేయడం కంటే ఎక్కువ అవసరం. మన్నికైన డాక్యుమెంట్ స్థితి మరియు అప్‌డేట్ డెలివరీని క్వెరీ-టైమ్ నిల్వ నుండి వేరు చేయడం, ఆపై వేగవంతమైన బ్యాచ్డ్ రీడ్‌ల కోసం ప్రత్యేకంగా హాట్ స్టోర్‌ను ఆప్టిమైజ్ చేయడం మాకు అవసరం.

ప్రత్యేక డాక్యుమెంట్ స్థితి, అప్‌డేట్ డెలివరీ మరియు సర్వింగ్

కొత్త ఆర్కిటెక్చర్ ప్రతి బాధ్యతను వేర్వేరు భాగానికి కేటాయిస్తుంది. Pillar మన్నికైన డాక్యుమెంట్ స్థితిని నిర్వహిస్తుంది మరియు ఏమి ప్రచురించాలో నిర్ణయిస్తుంది. Lorry ఆ ఎగుమతులను విభజించబడిన బ్యాచ్‌లుగా మారుస్తుంది. CobbleDB బ్యాచ్‌లను ఇన్‌జెస్ట్ చేస్తుంది మరియు పేజీ కీ ద్వారా ప్రిపేర్డ్ రికార్డ్‌లను అందిస్తుంది.

విస్తరించు

CobbleDB: సర్దుబాటు చేయగల రీడ్ పాత్

CobbleDB అనేది క్వెరీ సమయంలో ప్రిపేర్డ్ రికార్డ్‌లను అందించడానికి ఆప్టిమైజ్ చేయబడిన మా హాట్ స్టోర్. ఇది డిస్ట్రిబ్యూటెడ్ కీ-వాల్యూ స్టోర్: కీలు పేజీ ఐడెంటిఫైయర్‌లు (హాష్ చేయబడిన URLలు), మరియు విలువలు పేజీ యొక్క ప్రాసెస్ చేయబడిన ప్రాతినిధ్యం (వాటి ప్రీ-చంక్డ్ పాసేజ్‌లు మరియు పర్-చంక్ వెక్టర్ ఎంబెడ్డింగ్‌లు).

ముఖ్యమైన మార్పు ఏమిటంటే నిల్వ కాన్ఫిగరేషన్‌పై మా నియంత్రణ.

డేటా విభజించబడి మరియు డేటా నోడ్‌ల জুড়ে విభజించబడింది. ఈ డిస్ట్రిబ్యూటెడ్ ఫార్మాట్ డేటాబేస్ ప్రాసెస్ చేయబడిన పేజీల యొక్క విపరీతమైన కార్పస్‌కు వసతి కల్పించడానికి అడ్డంగా స్కేల్ చేయగలదని నిర్ధారిస్తుంది. ప్రతి విభజన మూడు వేర్వేరు నోడ్‌లలో మూడు ప్రతిరూపాలను కలిగి ఉంటుంది; ఒక కాపీ అందుబాటులో లేకపోతే, మిగిలినవి రీడ్‌లను అందించడం కొనసాగించవచ్చు.

ప్రతి డేటా నోడ్‌కు విభజనల ఉపసమితి కేటాయించబడుతుంది. నోడ్ తన డేటాను RocksDB ఉపయోగించి నిల్వ చేస్తుంది, ఇది బ్యాచ్ ఇన్‌జెషన్ ద్వారా అందించబడే రీడ్-హెవీ వర్క్‌లోడ్‌లకు బాగా సరిపోయే ఓపెన్ సోర్స్ ఎంబడెడ్ కీ-వాల్యూ స్టోరేజ్ ఇంజిన్.

Cached data‌ను memory నుండే serve చేయవచ్చు, అయితే uncached reads local NVMe storage‌ను ఉపయోగిస్తాయి. ఇది managed service యొక్క internal cache policy‌ను అంగీకరించకుండా, observed workload కోసం memory-to-disk balance‌ను నేరుగా tune చేయడానికి మాకు అవకాశం ఇస్తుంది.

స్టేట్‌లెస్ క్వెరీ రౌటర్ కీలను పార్టీషన్‌లకు హాష్ చేస్తుంది మరియు అభ్యర్థనలను సమాంతరంగా నోడ్‌లకు రూట్ చేస్తుంది. ఆర్కిటెక్చర్‌లో PostgreSQL-బ్యాక్డ్ మెటాడేటా సర్వీస్ మరియు మన్నికైన ఆబ్జెక్ట్ స్టోరేజ్ కూడా ఉన్నాయి.

ఈ design మన workload కోరే read patterns‌కు మద్దతు ఇస్తుంది. ఒక query retrieval మరియు ranking గుండా వెళ్లి relevant pages యొక్క candidate set‌ను పొందిన తర్వాత, ఆ pages యొక్క contents కోసం hot store‌ను bulk‌గా query చేస్తారు. ఈ read requests router వద్దకు వస్తాయి మరియు corresponding data node‌కు route చేయబడతాయి. వీలైతే cross-zone latencyను తగ్గించడానికి router అదే availability zoneలో ఉన్న node‌కు requests పంపడాన్ని ప్రాధాన్యంగా చూస్తుంది. ప్రతి data node MultiGet‌ను ఉపయోగించి page contents‌ను fetch చేయగలదు; ఇది తక్కువ latencyతో అనేక keys‌ను ఒకేసారి fetch చేయడానికి రూపొందించబడిన RocksDB batch-read API. ఒక node స్పందించడంలో నెమ్మదిగా ఉంటే, system వేరే node‌లో ఉన్న మరో partition replica‌ను కూడా query చేయగలదు, తద్వారా tail latency మెరుగుపడుతుంది.

మన వర్క్‌ఫ్లోకు అవసరం లేని సాధారణ ఫీచర్లను అమలు చేయకుండానే ఉండవచ్చు. ఉదాహరణకు, చాలా డేటాబేస్‌లు consistency guarantees మరియు transaction support అందిస్తాయి, కానీ మా hot store‌కు transactions లేదా synchronized replicas అవసరం లేదు. ఒక డాక్యుమెంట్ వ్రాయబడిన సమయం మరియు అది reads‌కు అందుబాటులో అయ్యే సమయం మధ్య చిన్న అంతరం ఉండటం సమంజసం, అలాగే ఒక replica మరొకటి కంటే వేగంగా డేటాను ingest చేయడం కూడా పరవాలేదు. మనకు అవసరం లేని ఫీచర్లను వదిలేయడం వల్ల మా సిస్టమ్‌లో overhead మరియు cost తగ్గుతాయి.

విస్తరించు

Pillar మరియు Lorry: మన్నికైన రైట్ పాత్

మనం క్రాల్ చేసే మరియు ప్రాసెస్ చేసే ప్రతిదానిని ఒక ప్రత్యేక నిల్వ లేయర్ ట్రాక్ చేస్తుంది, అప్‌డేట్‌లను వెర్షన్ చేసిన డాక్యుమెంట్ స్థితిలో విలీనం చేస్తుంది మరియు అవసరమైన ప్రాతినిధ్యాలను CobbleDB మరియు సెర్చ్ ఇండెక్స్‌కు ప్రచురిస్తుంది. మేము ఈ ప్రయోజనం కోసం మా డాక్యుమెంట్ స్థితి మరియు ప్రచురణ లేయర్ అయిన Pillarను రూపొందించాము.

Pillar‌కు YTsaurus మద్దతుగా ఉంది. ఇది page components (such as metadata, chunks, and embeddings)ను వేర్వేరు YTsaurus table familiesలో నిల్వ చేస్తుంది. ఇది chunks మరియు embeddings యొక్క versions‌ను కూడా track చేస్తుంది, తద్వారా underlying models మారగలిగేలా, ఒకటి మరొకదాన్ని overwrite చేయకుండా multiple representations coexist అవ్వగలవు. Pillar మరియు YTsaurus cheap HDD storageను ఉపయోగిస్తున్నందున, మేము ముందు DynamoDBలో నిల్వ చేసిన దానికంటే చాలా ఎక్కువ documents‌ను నిల్వ చేయగలుగుతున్నాం.

Pillar ఉపసమితులను ట్రాక్ చేస్తుంది, లేదా తాజా పేజీలు లేదా అధిక-విలువ పేజీల వంటి పాలసీ-నిర్వచించబడిన పేజీల సమూహాలను ట్రాక్ చేస్తుంది. ఉపసమితి సభ్యత్వం ఏ అప్‌డేట్‌లను CobbleDB వంటి డౌన్‌స్ట్రీమ్ భాగాలకు పండాలో నిర్ణయిస్తుంది. CobbleDB మరింత ఖరీదైన NVMe నిల్వను ఉపయోగిస్తుంది, కాబట్టి మేము శోధన ఫలితాలలో ఉపయోగించాలనుకుంటున్న డాక్యుమెంట్‌లను మాత్రమే ఎగుమతి చేస్తాము. పేజీ కంటెంట్‌లు అప్‌డేట్ చేయబడినప్పుడు, లేదా అది ఉపసమితి నుండి జోడించబడినా లేదా తీసివేయబడినా, తదితర ఎగుమతి పనిని క్యూలో ఉంచడానికి Pillar బాధ్యత వహిస్తుంది.

అటామిక్ YTsaurus ట్రాన్సాక్షన్‌లు స్థితి, ఎగుమతి ఉద్దేశాలు, మరియు వినియోగించిన ఇన్‌పుట్‌ను క్రమంగా కవర్ చేస్తాయి, తద్వారా సరిైనతను నిర్ధారించవచ్చు. ఒక ట్రాన్సాక్షన్ విజయవంతంగా పూర్తవ్వాలంటే, సిస్టమ్ నిలకడైన స్థితిని అప్డేట్ చేయాలి, ఇన్‌పుట్‌ను లెక్కలోకి తీసుకున్నదిగా గుర్తించాలి, మరియు అవసరమైన అన్ని ఎగుమతులను క్యూలో పెట్టాలి; ట్రాన్సాక్షన్ అబోర్ట్ అయితే, ఏ పొరలోనూ ఎలాంటి మార్పు జరగదు.

CobbleDB అప్‌డేట్‌లు విభజన ప్రకారం బ్యాచ్ చేయబడతాయని ఆశిస్తుంది. Pillar ఎగుమతులు Lorry అని పిలిచే స్టేట్‌లెస్ సర్వీస్ ద్వారా ఈ ఆకృతికి మార్చబడతాయి. పర్సిస్టెంట్ పార్టీషన్-అలైన్డ్ క్యూ నుండి ఎగుమతి రికార్డ్‌లను చదవడం, వాటిని ప్రతి-పార్టిషన్ బ్యాచ్ ఫైళ్లుగా పేరుకుపోవడం మరియు వాటిని CobbleDBకి అందించడం దీని ఏకైక పని.

Lorry మరియు Cobble మధ్య, అదనపు ప్రోటోకాల్ డేటా ప్లేన్ (S3) నుండి కంట్రోల్ ప్లేన్‌ను విభజిస్తుంది. Lorry ప్రత్యేక ఐడెంటిఫైయర్ కింద S3కి బ్యాచ్‌ను వ్రాస్తుంది మరియు Cobbleలో బ్యాచ్‌ను రిజిస్టర్ చేస్తుంది. Cobble పార్టీషన్ ప్రతిరూపాలు ఇన్‌జెస్ట్ చేయడానికి తదుపరి S3 బ్యాచ్ కోసం బ్యాచ్ లేదా కంట్రోల్ ప్లేన్ APIని స్వతంత్రంగా క్వెరీ చేస్తాయి మరియు కాలక్రమానుసారంగా బ్యాచ్ అప్‌డేట్‌లను అసమకాలికంగా వర్తింపజేస్తాయి. దీని అర్థం నెమ్మదిగా ఉన్న లేదా కోలుకుంటున్న నోడ్ మిగిలిన సిస్టమ్‌ను నెమ్మదింపజేయకుండా, దాని స్వంత వేగంతో అందుకోగలదు.

విస్తరించు

కొత్త మార్గం తక్షణ ప్రాసెసింగ్ ట్రాన్సాక్షన్‌ను hot-store ingestion నుండి వేరు చేస్తుంది మరియు incremental updates అలాగే bulk rebuilds కోసం replay చేయగల మార్గాన్ని అందిస్తుంది. ఈ బాధ్యతల విభజన వల్ల durable document state‌కు జరిగే అప్డేట్‌లు read path latencyతో అంతరాయం కలిగించవు.

ధృవీకరణ

5x వేగంగా

హాట్ స్టోర్‌ను మైగ్రేట్ చేసిన తర్వాత, మధ్యస్థ బ్యాచ్-రీడ్ లేటెన్సీ 31.4 ms నుండి 5.60 msకి పడిపోయింది. p90 56.7 ms నుండి 9.77 msకి పడిపోయింది మరియు p99 123 ms నుండి 24.2 msకి పడిపోయింది. సాధారణ అభ్యర్థనలు మరియు టెయిల్ రెండింటిలోనూ మెరుగుదలలతో నిష్పత్తులు 5.08× నుండి 5.80× వరకు ఉన్నాయి.

విస్తరించు

ఈ సంఖ్యలు బ్యాచ్డ్ రీడ్‌ల నుండి తీసుకోబడ్డాయి, ఇక్కడ ప్రతి క్వెరీ దాదాపు 10-15 కీలను అభ్యర్థిస్తుంది. సగటు పేలోడ్ అంశం పరిమాణం 50KB. 500k rps వరకు లోడ్ పరీక్షలను మేము అమలు చేసినప్పటికీ, రెండు సిస్టమ్‌లు సుమారు 200k rps వద్ద క్వెరీ చేయబడ్డాయి.

CobbleDB యొక్క సహకారాన్ని వేరు చేయడానికి, సెటప్‌లోని ఇతర అంశాలన్నీ స్థిరంగా ఉంచబడ్డాయి. అయితే, ఇది పరిశీలనాత్మక బిఫోర్-అండ్-ఆఫ్టర్ పోలికగానే మిగిలిపోయింది; నియంత్రిత పరిస్థితులలో అదే అభ్యర్థనలకు బదులుగా సిస్టమ్‌లు వేర్వేరు సమయాల్లో లైవ్ ప్రొడక్షన్ ట్రాఫిక్‌ను అందించాయి. అందువల్ల మేము సింథటిక్ బెంచ్‌మార్క్‌పై రెండు సిస్టమ్‌ల పనితీరును కూడా కొలిచాము. ప్రొడక్షన్‌లో కనిపించే అభ్యర్థనలను అంచనా వేయడానికి, మేము 10-15 కీలు మరియు 100B నుండి 100 KiB వరకు ఉండే విలువలతో కూడిన బ్యాచ్‌లతో రెండింటిని క్వెరీ చేసాము.

విస్తరించు

DynamoDB ఈ సందర్భంలో ఇబ్బంది పడుతుంది ఎందుకంటే దాని మేనేజ్డ్ రీడ్ పాత్ ఈ పరిమాణంలోని బ్యాచ్డ్ రీడ్స్ కోసం ట్యూన్ చేయబడదు. దీనికి విరుద్ధంగా, CobbleDB సరిగ్గా ఈ సెట్టింగ్ కోసం ఆప్టిమైజ్ చేయబడింది, ఎందుకంటే మేము ప్లేస్‌మెంట్, క్యాచింగ్ మరియు రెప్లికా నియంత్రణలను నిర్వహిస్తాము. ఇది పార్టీషన్ ద్వారా కీలను సమూహపరుస్తుంది, పార్టీషన్ ప్రతిరూపాలకు వ్యతిరేకంగా సమాంతరంగా రీడ్‌లను అమలు చేస్తుంది మరియు ఇతర ప్రతిరూపాలకు వ్యతిరేకంగా నెమ్మదిగా ఉండే రీడ్‌లను హెడ్జ్ చేయగలదు. ఈ డిజైన్ ఎంపికలు ప్రొడక్షన్ వాతావరణంలో వేగవంతమైన రీడ్‌లకు అనువదించబడతాయని మా ఫలితాలు నిరూపిస్తున్నాయి.

20% చౌకైనది

CobbleDB కూడా DynamoDB కంటే గణనీయంగా చౌకైనది. నిల్వతో పాటు, DynamoDB చదివిన లేదా వ్రాసిన ప్రతి బైట్‌కు కూడా ఛార్జ్ చేస్తుంది. మా కార్పస్ మరియు సర్వింగ్ ట్రాఫిక్ స్థాయిలో, ఈ వినియోగ-ఆధారిత ఛార్జీలు మొత్తం ఖర్చులో గణనీయమైన భాగంగా మారుతాయి. నిరంతర అప్‌డేట్‌లు రైట్ కెపాసిటీని వినియోగిస్తాయి, అయితే క్వెరీ కోసం తెచ్చిన ప్రతి ప్రిపేర్డ్ పేజీల బ్యాచ్ రీడ్ కెపాసిటీని వినియోగిస్తుంది.

నిల్వ పరిమాణం, రైట్ కెపాసిటీ యూనిట్లు మరియు రీడ్ కెపాసిటీ యూనిట్ల అంతర్గత అంచనాల ఆధారంగా మేము ఖర్చు ఆదాను లెక్కించాము. ప్రతి కమిట్‌మెంట్ శ్రేణిలో, CobbleDB DynamoDB కంటే కనీసం 20% చౌకైనది. ఈ ఫలితాలు కుదింపు నుండి వచ్చే సంభావ్య బ్యాకప్ ఆదాను పరిగణనలోకి తీసుకోనందున, వాస్తవ ఆదా బహుశా ఇంకా ఎక్కువగా ఉంటుంది.

AI ఏజెంట్ల సమూహం దీన్ని నిర్మించడంలో మాకు ఎలా సహాయపడుతుంది

CobbleDB మరియు దాని చుట్టూ ఉన్న infrastructure‌ను నిర్మించడం చాలా కష్టం. CobbleDB యొక్క core database మాత్రమే సుమారు 40,000 lines of Rust, మరియు ఈ migration‌కు production scaleలో correctness మరియు failure behavior‌ను నిర్ధారించడానికి, CobbleDB‌ను processing మరియు serving paths రెండింటితో integrate చేయడానికి, అలాగే live traffic‌ను సురక్షితంగా transition చేయడానికి కూడా విస్తృతమైన పని అవసరమైంది.

కోడింగ్ ఏజెంట్ల సమూహాన్ని నడిపే అంతర్గత వ్యవస్థను ఉపయోగించి మేము ఈ ప్రయత్నాన్ని వేగవంతం చేసాము. ఈ వ్యవస్థ అత్యంత నిరంతరంగా ఉండేలా రూపొందించబడింది; ఇది సెషన్‌లలో ప్రాజెక్ట్ లక్ష్యాలు, క్రియాశీల నష్టాలు, రిపోజిటరీ చరిత్ర మరియు మునుపటి నిర్ణయాలను నిలుపుకుంటుంది.

మేము అటువంటి చొరవతో కూడిన, ఎల్లప్పుడూ ఆన్‌లైన్‌లో ఉండే ఏజెంట్ల సముదాయాన్ని CobbleDB ప్రాజెక్ట్‌కి కేటాయించాము. ఇప్పటికే నడుస్తున్న పని యొక్క ఖచ్చితమైన మోడల్‌ను రూపొందించడం వారి మొదటి పని. వారు ప్రాజెక్ట్ ఛానెల్ మరియు క్రియాశీల థ్రెడ్‌లను ఆడిట్ చేశారు, అత్యుత్తమ అంశాలను వాటి pull requestలు మరియు యజమానులకు కనెక్ట్ చేసారు మరియు సిస్టమ్ ఆరోగ్యం మరియు తదుపరి చర్యల యొక్క ప్రస్తుత రీడ్‌అవుట్‌ను ఉత్పత్తి చేశారు. అక్కడి నుండి, వారు ఇంజనీరింగ్ లూప్‌లోని అనేక భాగాలలో పనిచేశారు:

• కోడ్ మరియు ఇన్‌ఫ్రాస్ట్రక్చర్ మార్పులను సమీక్షించింది.
• సురక్షితం కాని రీస్టోర్ అంచనాలు, పాత బిల్డ్ రిఫరెన్స్‌లు మరియు రన్‌టైమ్‌లో విఫలమయ్యే కాన్ఫిగరేషన్‌లతో సహా సులభంగా మిస్ అయ్యే బ్లాకర్‌లను గుర్తించింది.
• నిర్దిష్ట పరిష్కారాలు, పరీక్షలు, పర్యవేక్షణ మార్పులు మరియు కార్యాచరణ డాక్యుమెంటేషన్‌ను సిద్ధం చేసింది.
• ఉత్పత్తి చర్యలు స్పష్టంగా మానవ యాజమాన్యంలో ఉండేలా చూసేటప్పుడు CI, సమీక్ష మరియు మౌలిక సదుపాయాల గేట్‌లను ట్రాక్ చేసింది.
• పర్యవేక్షించబడిన రోల్‌అవుట్‌లు మరియు బ్యాకప్ లేదా రీస్టోర్ వ్యాయామాలు, ఆపై గమనించిన సిస్టమ్ స్థితిని రోల్‌అవుట్ విజయ ప్రమాణాలతో పోల్చాయి.
• ఇంజనీర్లు ఏమి షిప్ చేయబడింది, ఏది బ్లాక్ చేయబడి ఉంది మరియు మానవ తీర్పు ఎక్కడ ఇప్పటికీ అవసరమో చూడగలగడానికి ప్రాజెక్ట్ రీడ్‌అవుట్‌లను నిర్వహించారు.

ఇంజనీర్లు ఇప్పటికీ ఆర్కిటెక్చర్‌ను సెట్ చేస్తారు, ప్రభావవంతమైన మార్పులను సమీక్షించారు మరియు ప్రొడక్షన్ కార్యకలాపాలను అధికారం చేస్తారు. ఆ నిర్ణయాల మధ్య నిరంతర తనిఖీ మరియు ఫాలో-త్రూలో ఎక్కువ భాగం ఏజెంట్లు నిర్వహించారు. ఇది చిన్న teams ప్రాజెక్ట్‌ను సమర్థవంతంగా నడిపించడానికి అనుమతించింది - కోర్ CobbleDB ఇన్‌ఫ్రాస్ట్రక్చర్ ఇద్దరు మానవ ఇంజనీర్లు మరియు వందలాది AI ఏజెంట్ల ద్వారా రెండు నెలల్లో నిర్మించబడింది.

ముగింపు

CobbleDB అనేది జనరల్-పర్పస్ డేటాబేస్ కాదు; ఇది అసమకాలిక ప్రాసెసింగ్ పైప్‌లైన్ ద్వారా అందించబడిన ప్రిపేర్డ్ పేజీ రికార్డ్‌ల పునరావృత బ్యాచ్ రీడ్‌ల యొక్క మా నిర్దిష్ట వర్క్‌లోడ్ కోసం ఉద్దేశపూర్వకంగా రూపొందించబడింది. మన్నికైన స్థితి, అప్‌డేట్ డెలివరీ మరియు క్వెరీ-టైమ్ సర్వింగ్‌లను వేరు చేయడం ద్వారా, సింగిల్ డేటాబేస్ ఇంటర్‌ఫేస్ అన్నింటికీ వసతి కల్పించమని బలవంతం చేయకుండా లేదా లైవ్ క్వెరీ మార్గంలో మెయింటెనెన్స్ పనులను నెట్టకుండా మేము ప్రతి బాధ్యతను స్వతంత్రంగా ఆప్టిమైజ్ చేయవచ్చు. CobbleDBకి మైగ్రేట్ చేయడం వల్ల ఇన్‌ఫ్రాస్ట్రక్చర్ ఖర్చులు తగ్గుతూనే మధ్యస్థ మరియు టెయిల్ లేటెన్సీ రెండూ గణనీయంగా మెరుగుపడ్డాయి.

మేము ఇన్‌హౌస్‌లో AI-నేటివ్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ను అభివృద్ధి చేస్తూనే ఉన్నందున, మూడవ పక్షం అమలులు మరియు ధరల మోడళ్లకు కట్టుబడి ఉన్నప్పుడు సాధ్యం కాని మార్గాల్లో మేము పనితీరు మరియు ఖర్చును ఆప్టిమైజ్ చేయవచ్చు. శక్తివంతమైన AI ఏజెంట్లు కొనడం కంటే బిల్డింగ్ వైపు గణనను మరింత అనుకూలంగా మారుస్తాయి.

మేము త్వరలో CobbleDB‌ను open-source చేయాలని యోచిస్తున్నాం, తద్వారా AI-native search systems‌ను నిర్మిస్తున్న ఇతర teams కూడా మా products‌లో search‌ను వేగంగా మరియు తక్కువ ఖర్చుతో చేసే అదే storage layer నుండి ప్రయోజనం పొందగలరు.

ఉదాహరణ

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