CobbleDB: കുറഞ്ഞ ലേറ്റൻസിക്കും ചെലവിനുമായി AI സെർച്ച് സ്റ്റോറേജ് പുനർനിർമ്മിക്കുന്നു

വെബ് ഉള്ളടക്കം എങ്ങനെ പ്രോസസ്സ് ചെയ്യണം, സംഭരിക്കണം, സെർവ് ചെയ്യണം എന്നതിൽ AI-നേറ്റീവ് സെർച്ച് വ്യത്യസ്ത ആവശ്യകതകൾ ചുമത്തുന്നു. ആ ആവശ്യങ്ങൾ വലിയ തോതിൽ നിറവേറ്റുന്നതിനായി, പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിനും ചെലവ് കുറയ്ക്കുന്നതിനുമായി ഞങ്ങൾ മുഴുവൻ സ്റ്റാക്കും ആദ്യം മുതൽ പുനർനിർമ്മിക്കുകയാണ്.

കാര്യക്ഷമമായ പ്രോസസ്സിംഗും വേഗത്തിലുള്ള സെർവിംഗും നൽകുന്നതിനായി ഞങ്ങൾ ഞങ്ങളുടെ സ്വന്തം ക്രാളിംഗ്, ഇൻഡക്സിംഗ്, റാങ്കിംഗ് ഇൻഫ്രാസ്ട്രക്ചർ, എംബെഡിംഗ് മോഡലുകൾ, ഇൻഫറൻസ് എഞ്ചിനുകൾ എന്നിവ നിർമ്മിച്ചു. പ്രോസസ്സിംഗ് എഴുതുകയും സെർവിംഗ് റീഡ് ചെയ്യുകയും ചെയ്യുന്ന കണക്റ്റീവ് ടിഷ്യു ആയ സ്റ്റോറേജിലേക്ക് ഞങ്ങൾ ഇപ്പോൾ ആ സമീപനം വ്യാപിപ്പിക്കുകയാണ്.

DynamoDB പോലുള്ള മാനേജഡ് ഡാറ്റാബേസുകൾ വിശ്വസനീയമായ സ്റ്റോറേജ് നൽകി, എന്നാൽ ഡാറ്റ എങ്ങനെ സൂക്ഷിക്കുന്നുവെന്നും റീഡുകൾ എങ്ങനെ നൽകുന്നുവെന്നും നിയന്ത്രിക്കുന്നതിൽ ഞങ്ങൾക്ക് പരിമിതമായ നിയന്ത്രണമേ ഉണ്ടായിരുന്നുള്ളൂ, കൂടാതെ ഉപയോഗത്തെ അടിസ്ഥാനമാക്കിയുള്ള വിലനിർണ്ണയം ഞങ്ങളുടെ ഇൻഡക്സ് വലുപ്പത്തിനും ക്വറി വോള്യത്തിനും അനുസരിച്ച് വർദ്ധിച്ചു. പ്രത്യേകം, ഞങ്ങളുടെ മുൻ പൈപ്പ്‌ലൈൻ ഡോക്യുമെന്റ് പ്രോസസ്സിംഗിനെ സെർവിംഗ് ഡാറ്റാബേസുമായി നേരിട്ട് ബന്ധിപ്പിച്ചു, ഇത് തത്സമയ റീഡുകളിൽ നിന്ന് സ്വതന്ത്രമായി അപ്ഡേറ്റുകൾ കൈകാര്യം ചെയ്യുന്നത് ബുദ്ധിമുട്ടാക്കി.

പുതിയ ആന്തരിക കോഡിംഗ് ഏജന്റ് സ്വോംന്റെ സഹായത്തോടെ, Pillar ദീർഘകാല ഡോക്യുമെന്റ് സ്റ്റേറ്റിനും പ്രസിദ്ധീകരണത്തിനും, Lorry ബാച്ച് ചെയ്ത അപ്‌ഡേറ്റുകൾക്കുമായി പിന്തുണയ്ക്കുന്ന CobbleDB എന്ന കീ-വാല്യൂ ഹോട്ട് സ്റ്റോർ ചുറ്റിപ്പറ്റി ഞങ്ങൾ ഈ പാളിയെ പുനർനിർമ്മിച്ചു. ഈ പുനർരൂപകൽപ്പന ഡോക്യുമെന്റ് പ്രോസസ്സിംഗിനെ ഹോട്ട്-സ്റ്റോർ ഇൻജെഷനിൽ നിന്ന് വേർതിരിക്കുകയും നമ്മുടെ വർക്ക്‌ലോഡിന് അനുയോജ്യമായി സർവിംഗ് ട്യൂൺ ചെയ്യാൻ അനുവദിക്കുകയും ചെയ്യുന്നു. പ്രൊഡക്ഷനിൽ മുൻപ്-ശേഷം നടത്തിയ അളവുകൾ ബാച്ച്-റീഡ് ലേറ്റൻസിയിൽ ഏകദേശം 5× കുറവ് കാണിക്കുന്നു, കൂടാതെ ഞങ്ങളുടെ ആഭ്യന്തര ചെലവ് മോഡൽ DynamoDB-യുമായി താരതമ്യം ചെയ്യുമ്പോൾ കുറഞ്ഞത് 20% ലാഭം കണക്കാക്കുന്നു.

AI-നേറ്റീവ് സെർച്ചിനുള്ള സ്റ്റോറേജ് ഇൻഫ്രാസ്ട്രക്ചർ

ഒരു ക്ലാസിക് സെർച്ച് സ്റ്റാക്ക് നിർമ്മിച്ചിരിക്കുന്നത് ഒരു മനുഷ്യ വായനക്കാരന് വേണ്ടിയാണ്, ഭാഷാ മാതൃകയ്ക്കല്ല. ആ വ്യത്യാസം സിസ്റ്റം വെബ് ഉള്ളടക്കം തയ്യാറാക്കേണ്ട, സംഭരിക്കേണ്ട, സേവിക്കേണ്ട ഗ്രാനുലാരിറ്റിയെ മാറ്റുന്നു.

റോ ആയ HTML-നെ മോഡലിന് തയ്യാറായ ഉള്ളടക്കമാക്കി മാറ്റാൻ, ഞങ്ങളുടെ പ്രോസസ്സിംഗ് പൈപ്പ്‌ലൈൻ ഓരോ പേജും ക്ലീൻ ചെയ്യുകയും, അർത്ഥവത്തായ പാസേജുകളായി വിഭജിക്കുകയും, അവയുടെ എംബെഡിംഗുകൾ കണക്കാക്കുകയും, പാസേജുകളും എംബെഡിംഗുകളും ഡാറ്റാബേസിൽ ഒരുമിച്ച് സൂക്ഷിക്കുകയും ചെയ്യുന്നു. ക്വറി സമയത്ത്, സെർവിംഗ് പൈപ്പ്‌ലൈൻ ക്വറിയുമായി ഏറ്റവും പ്രസക്തമായ ടെക്സ്റ്റ് തിരഞ്ഞെടുത്ത് അത് മോഡലിന് കൈമാറുന്നു.

വ്യത്യസ്തമായ രണ്ട് വർക്ക്ഫ്ലോകൾ

അതിനാൽ സ്റ്റോറേജ് ലെയർ വ്യത്യസ്ത ആവശ്യങ്ങളുള്ള രണ്ട് വർക്ക്ഫ്ലോകളെ പിന്തുണയ്ക്കണം: പ്രോസസ്സിംഗ് പൈപ്പ്‌ലൈനിൽ നിന്നുള്ള അപ്ഡേറ്റുകൾ ഇൻജസ്റ്റ് ചെയ്യുകയും കുറഞ്ഞ ലേറ്റൻസിയിലുള്ള റീഡുകൾ സെർവ് ചെയ്യുകയും ചെയ്യുക.

റൈറ്റ് വശത്ത്, പുതിയ പേജുകൾ തുടർച്ചയായി എത്തിച്ചേരുന്നു, നിലവിലുള്ള പേജുകൾ മാറുന്നു, കൂടാതെ ചങ്കിംഗ് രീതികളിലെ മാറ്റങ്ങൾ അല്ലെങ്കിൽ എംബെഡിംഗ് മോഡലുകൾ കോർപ്പസിന്റെ വലിയ ഭാഗങ്ങൾ വീണ്ടും പ്രോസസ്സ് ചെയ്യാൻ ആവശ്യപ്പെട്ടേക്കാം. സ്റ്റോറേജ് ലെയർ ഈ അപ്ഡേറ്റുകൾ ഡ്യൂറബിൾ ഡോക്യുമെന്റ് സ്റ്റേറ്റിൽ ഉൾപ്പെടുത്തുകയും, നിലവിലെ പതിപ്പുകൾ ട്രാക്ക് ചെയ്യുകയും, ശരിയായ റെപ്രസന്റേഷനുകൾ ഡൗൺസ്ട്രീം സിസ്റ്റങ്ങളിലേക്ക് പബ്ലിഷ് ചെയ്യുകയും, റോ ക്രാളിൽ നിന്നുള്ള മുഴുവൻ പൈപ്പ്‌ലൈനും ആവർത്തിക്കാതെ വലിയ ബാക്ക്ഫില്ലുകളെ പിന്തുണയ്ക്കുകയും വേണം.

ഇതിന് വിപരീതമായി, ക്വറി-ടൈം റീഡുകൾ റാങ്കിംഗിനും പാസേജ് തിരഞ്ഞെടുക്കലിനുമായി പേജ് കികളുടെ ബാച്ചുകൾ അഭ്യർത്ഥിക്കുകയും ബന്ധപ്പെട്ട പാസേജ് ടെക്സ്റ്റും എംബെഡിംഗുകളും വീണ്ടെടുക്കുകയും ചെയ്യുന്നു. ഈ റീഡുകൾ അന്തിമ ഉത്തരത്തിലേക്കുള്ള പാതയിലാണ്, അതിനാൽ അവ വേഗത്തിൽ പൂർത്തിയാക്കേണ്ടതുണ്ട്.

ഈ വർക്ക്‌ലോഡുകൾക്ക് വ്യത്യസ്ത ഡിസൈനുകൾ ആവശ്യമാണ്. ഡ്യൂറബിൾ ക്യൂകളിൽ നിന്നും അപ്ഡേറ്റുകൾ കാര്യക്ഷമമായി ഡെലിവർ ചെയ്യാനും, പരാജയങ്ങൾ റിട്രൈ ചെയ്യാനും, നിലവിലുള്ള റെക്കോർഡുകൾ സ്കെയിലിൽ അപ്-ടു-ഡേറ്റ് ആയി കൊണ്ടുവരാനുമുള്ള കഴിവിൽ നിന്ന് പ്രോസസ്സിംഗ് പ്രയോജനം നേടുന്നു. പ്രീകമ്പ്യൂട്ട് ചെയ്ത റെക്കോർഡുകൾ, വാം കാഷുകൾ, കുറഞ്ഞ ക്വറി-ടൈം ജോലിയുള്ള വേഗത്തിലുള്ള ബാച്ച്ഡ് റീഡുകൾ എന്നിവയിൽ നിന്ന് സെർവിംഗ് പ്രയോജനം നേടുന്നു. ഇവ രണ്ടും തമ്മിലുള്ള ഇറുകിയ കപ്ലിംഗ് റിക്കവറി ജോലികളെയും വലിയ അപ്ഡേറ്റുകളെയും ലേറ്റൻസി-സെൻസിറ്റീവ് റീഡുകളുമായി മത്സരിക്കാൻ ഇടയാക്കും.

മാനേജഡ് ഡാറ്റാബേസ് എവിടെയാണ് പരാജയപ്പെടുന്നത്

ഡിസ്ട്രിബ്യൂട്ടഡ് ഡാറ്റാബേസ് പ്രവർത്തിപ്പിക്കുന്നതിന്റെ ഭാരമില്ലാതെ ഉയർന്ന ലഭ്യതയുള്ള സ്റ്റോറേജ് DynamoDB ഞങ്ങൾക്ക് നൽകി. ഒരു പ്രത്യേക പ്രിപ്പേർഡ്-പേജസ് ടേബിൾ ക്വറി-ടൈം റീഡുകൾക്കായി പാസേജുകളും എംബെഡിംഗുകളും സൂക്ഷിച്ചു, അതേസമയം മുഴുവൻ പേജ് ഉള്ളടക്കവും മെറ്റാഡാറ്റയും പ്രത്യേകം സൂക്ഷിച്ചു. എന്നിരുന്നാലും, ഞങ്ങളുടെ വർക്ക്‌ലോഡ് വളർന്നപ്പോൾ, മൂന്ന് പരിമിതികൾ പ്രധാനമായിത്തീർന്നു.

രണ്ടാമതായി, ഉപയോഗത്തെ അടിസ്ഥാനമാക്കിയുള്ള വിലനിർണ്ണയം വായിക്കുന്നതോ എഴുതുന്നതോ ആയ ഓരോ ബൈറ്റിനും ഈടാക്കുന്നു. ഒരൊറ്റ സെർച്ച് API അഭ്യർത്ഥനയിൽ നമ്മൾ ഫെച്ച് ചെയ്യേണ്ട പേജുകളുമായി ബന്ധപ്പെട്ട 100-120 കികൾ അടങ്ങിയിരിക്കുന്നു. ഡാറ്റ വീണ്ടെടുക്കൽ പ്രക്രിയ ഒരു അഭ്യർത്ഥനയെ 10-20 പേജ് കികളുടെ ചെറിയ ബാച്ചുകളായി വിഭജിക്കുന്നു, ശരാശരി ഐറ്റം വലുപ്പം ഏകദേശം 50 KB ആണ്. ആ റെക്കോർഡുകൾ ആവർത്തിച്ച് വായിക്കുന്നത് ഗണ്യമായ കപ്പാസിറ്റി ഉപഭോഗം ചെയ്തു, അതേസമയം തുടർച്ചയായ ക്രാളുകളും ചങ്കിംഗിലോ എംബെഡിംഗ് മോഡലുകളിലോ ഉള്ള മാറ്റങ്ങളും കൂടുതൽ റൈറ്റുകൾ സൃഷ്ടിച്ചു. API കോളുകളുടെ എണ്ണം മാത്രമല്ല, റെക്കോർഡുകളുടെ വലുപ്പവും ആവൃത്തിയും സാമ്പത്തികശാസ്ത്രത്തെ ആശ്രയിച്ചിരിക്കുന്നു.

രണ്ടാമതായി, പ്രകടന ട്യൂണിംഗിന് ഞങ്ങൾക്ക് ആവശ്യമുള്ള ഫ്ലെക്സിബിലിറ്റി മാനേജഡ് സർവീസിന് ഇല്ല. ഞങ്ങൾക്ക് ആവശ്യമുള്ള പ്രവർത്തനം ചെറുതായിരുന്നു: പേജ് ഐഡന്റിഫയറുകളുടെ ഒരു ബാച്ച് നൽകിയാൽ, അവയുടെ തയ്യാറാക്കിയ ഉള്ളടക്കങ്ങൾ വേഗത്തിൽ നൽകുക. ഏത് മെഷീനാണ് പാർട്ടീഷൻ കൈവശം വെച്ചിരിക്കുന്നത്, അതിന്റെ കാഷിനായി എത്ര മെമ്മറി നീക്കിവെച്ചിട്ടുണ്ട്, ഏത് റെപ്ലിക്കയാണ് അഭ്യർത്ഥന കൈകാര്യം ചെയ്തത് എന്നിവയിൽ നിയന്ത്രണം വേണമെന്ന് ഞങ്ങൾ ആഗ്രഹിച്ചു. കാഷ് ചെയ്യാത്ത റീഡ്, ക്രോസ്-സോൺ ഹോപ്പ്, അല്ലെങ്കിൽ പതുക്കെ പ്രതികരിക്കുന്ന റെപ്ലിക്ക എന്നിവ മുഴുവൻ ബാച്ചും വൈകിപ്പിക്കാൻ കഴിയുമെന്നതിനാൽ ആ നിയന്ത്രണങ്ങൾ പ്രധാനമാണ്. DynamoDB API-ക്ക് പിന്നിൽ സ്വന്തം സ്റ്റോറേജും റെപ്ലിക്ക ബിഹേവിയറും കൈകാര്യം ചെയ്യുന്നു. ഞങ്ങൾക്ക് സർവീസ് കോൺഫിഗർ ചെയ്യാൻ കഴിഞ്ഞു, എന്നാൽ ഞങ്ങളുടെ വർക്ക്‌ലോഡിന് ചുറ്റുമുള്ള ആന്തരിക പ്ലേസ്‌മെന്റ്, സ്റ്റോറേജ്-എഞ്ചിൻ കാഷുകൾ, അല്ലെങ്കിൽ റെപ്ലിക്ക-സെലക്ഷൻ പോളിസി എന്നിവ ട്യൂൺ ചെയ്യാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞില്ല.

മൂന്നാമതായി, പ്രോസസ്സിംഗ് ഹോട്ട്-സ്റ്റോർ റൈറ്റുകളുമായി നേരിട്ട് ബന്ധപ്പെട്ടിരുന്നു. ഞങ്ങളുടെ മുൻ പ്രോസസ്സിംഗ് പൈപ്പ്‌ലൈൻ തയ്യാറാക്കിയ ഓരോ പേജും നേരിട്ട് DynamoDB-യിലേക്ക് എഴുതി. അതിനാൽ ഒരു വലിയ റീപ്രോസസ്സിംഗ് ജോലി വ്യക്തിഗത ഹോട്ട്-സ്റ്റോർ അപ്ഡേറ്റുകളുടെ ഒരു തരംഗമായി മാറി, കൂടാതെ പ്രോസസ്സിംഗിന് ഹോട്ട് സ്റ്റോറിന്റെ ത്രൂപുട്ട് പരിധികളും റിട്രൈ ബിഹേവിയറും ഉൾക്കൊള്ളേണ്ടിവന്നു. ഒരു പുതിയ ചങ്കിംഗ് രീതി പരീക്ഷിക്കുന്നതിനോ, ഞങ്ങളുടെ എംബെഡിംഗ് മോഡൽ മാറ്റുന്നതിനോ, അല്ലെങ്കിൽ ഒരു പുതിയ ഫീൽഡ് ചേർക്കുന്നതിനോ ഞങ്ങൾക്ക് മുഴുവൻ ഡാറ്റാബേസിലും 1-2 ദിവസത്തിനുള്ളിൽ MapReduce പ്രവർത്തിപ്പിക്കാൻ കഴിഞ്ഞില്ല. ഹോട്ട് സ്റ്റോറിലേക്ക് സ്വന്തം വേഗതയിൽ ബാച്ച് ചെയ്ത് ഡെലിവർ ചെയ്യാൻ ഒരു പ്രത്യേക സേവനത്തിന് കഴിയുന്ന സേവ് ചെയ്ത പേജ് അപ്ഡേറ്റുകളുടെ സ്വതന്ത്ര സ്ട്രീം ഉണ്ടായിരുന്നില്ല.

ഈ പരിമിതികൾ പരിഹരിക്കുന്നതിന് ഡാറ്റാബേസ് മാറ്റിസ്ഥാപിക്കുന്നതിനേക്കാൾ കൂടുതൽ ആവശ്യമാണ്. ഡ്യൂറബിൾ ഡോക്യുമെന്റ് സ്റ്റേറ്റും അപ്ഡേറ്റ് ഡെലിവറിയും ക്വറി-ടൈം സ്റ്റോറേജിൽ നിന്ന് ഞങ്ങൾ വേർപെടുത്തേണ്ടതുണ്ട്, തുടർന്ന് വേഗതയേറിയ ബാച്ച്ഡ് റീഡുകൾക്കായി ഹോട്ട് സ്റ്റോർ പ്രത്യേകം ഒപ്റ്റിമൈസ് ചെയ്യണം.

ഡോക്യുമെന്റ് സ്റ്റേറ്റ്, അപ്ഡേറ്റ് ഡെലിവറി, സെർവിംഗ് എന്നിവ പ്രത്യേകം സൂക്ഷിക്കുക

പുതിയ ആർക്കിടെക്ചർ ഓരോ ഉത്തരവാദിത്തവും വ്യത്യസ്ത ഘടകത്തിന് നൽകുന്നു. Pillar ഡ്യൂറബിൾ ഡോക്യുമെന്റ് സ്റ്റേറ്റ് നിലനിർത്തുകയും എന്ത് പ്രസിദ്ധീകരിക്കണമെന്ന് തീരുമാനിക്കുകയും ചെയ്യുന്നു. Lorry ആ എക്സ്പോർട്ടുകളെ പാർട്ടീഷൻ ചെയ്ത ബാച്ചുകളാക്കി മാറ്റുന്നു. CobbleDB ബാച്ചുകൾ ഇൻജസ്റ്റ് ചെയ്യുകയും പേജ് കീ വഴി തയ്യാറാക്കിയ റെക്കോർഡുകൾ സെർവ് ചെയ്യുകയും ചെയ്യുന്നു.

വലുതാക്കുക

CobbleDB: ട്യൂൺ ചെയ്യാവുന്ന റീഡ് പാത്ത്

ക്വറി സമയത്ത് തയ്യാറാക്കിയ റെക്കോർഡുകൾ സെർവ് ചെയ്യുന്നതിനായി ഒപ്റ്റിമൈസ് ചെയ്ത ഞങ്ങളുടെ ഹോട്ട് സ്റ്റോറാണ് CobbleDB. ഇതൊരു ഡിസ്ട്രിബ്യൂട്ടഡ് കീ-വാല്യൂ സ്റ്റോറാണ്: കികൾ പേജ് ഐഡന്റിഫയറുകളാണ് (ഹാഷ് ചെയ്ത URL-കൾ), കൂടാതെ മൂല്യങ്ങൾ പേജിന്റെ പ്രോസസ്സ് ചെയ്ത റെപ്രസന്റേഷനാണ് (അവയുടെ പ്രീ-ചങ്ക്ഡ് പാസേജുകളും പെർ-ചങ്ക് വെക്ടർ എംബെഡിംഗുകളും).

സ്റ്റോറേജ് കോൺഫിഗറേഷനിലുള്ള ഞങ്ങളുടെ നിയന്ത്രണമാണ് പ്രധാനപ്പെട്ട മാറ്റം.

ഡാറ്റ പാർട്ടീഷൻ ചെയ്ത് ഡാറ്റാ നോഡുകളിലായി വിഭജിച്ചിരിക്കുന്നു. പ്രോസസ്സ് ചെയ്ത പേജുകളുടെ വലിയൊരു ശേഖരത്തെ ഉൾക്കൊള്ളാൻ ഡാറ്റാബേസിന് തിരശ്ചീനമായി സ്കെയിൽ ചെയ്യാൻ കഴിയുമെന്ന് ഈ ഡിസ്ട്രിബ്യൂട്ടഡ് ഫോർമാറ്റ് ഉറപ്പാക്കുന്നു. ഓരോ പാർട്ടീഷനും വ്യത്യസ്ത മൂന്ന് നോഡുകളിൽ മൂന്ന് റെപ്ലിക്കകൾ ഉണ്ട്; ഒരു പകർപ്പ് ലഭ്യമല്ലാതായി തീർന്നാൽ, മറ്റുള്ളവയ്ക്ക് റീഡുകൾ നൽകുന്നത് തുടരാം.

ഓരോ ഡാറ്റാ നോഡിനും പാർട്ടീഷനുകളുടെ ഒരു ഉപസെറ്റ് നൽകിയിരിക്കുന്നു. ബാച്ച് ഇൻജഷൻ വഴി നൽകുന്ന റീഡ്-ഹെവി വർക്ക്‌ലോഡുകൾക്ക് ഏറ്റവും അനുയോജ്യമായ ഓപ്പൺ സോഴ്സ് എംബഡഡ് കീ-വാല്യൂ സ്റ്റോറേജ് എഞ്ചിനായ RocksDB ഉപയോഗിച്ചാണ് നോഡ് അതിൻ്റെ ഡാറ്റ സൂക്ഷിക്കുന്നത്.

കാഷ് ചെയ്ത ഡാറ്റ മെമ്മറിയിൽ നിന്ന് സെർവ് ചെയ്യാൻ കഴിയും, അതേസമയം കാഷ് ചെയ്യാത്ത റീഡുകൾ ലോക്കൽ NVMe സ്റ്റോറേജ് ഉപയോഗിക്കുന്നു. മാനേജഡ് സർവീസിന്റെ ആന്തരിക കാഷ് പോളിസി അംഗീകരിക്കുന്നതിന് പകരം, നിരീക്ഷിച്ച വർക്ക്‌ലോഡിനായി മെമ്മറി-ടു-ഡിസ്ക് ബാലൻസ് ട്യൂൺ ചെയ്യാൻ ഇത് ഞങ്ങൾക്ക് നേരിട്ടുള്ള വഴി നൽകുന്നു.

സ്റ്റേറ്റ്‌ലെസ്സ് ആയ ഒരു ക്വറി റൂട്ടർ കികളെ പാർട്ടീഷനുകളിലേക്ക് ഹാഷ് ചെയ്യുകയും അഭ്യർത്ഥനകൾ നോഡുകളിലേക്ക് സമാന്തരമായി റൂട്ട് ചെയ്യുകയും ചെയ്യുന്നു. ആർക്കിടെക്ചറിൽ PostgreSQL-അടിസ്ഥാനമാക്കിയുള്ള മെറ്റാഡാറ്റ സേവനവും ഡ്യൂറബിൾ ഒബ്ജക്റ്റ് സ്റ്റോറേജും ഉൾപ്പെടുന്നു.

ഈ ഡിസൈൻ ഞങ്ങളുടെ വർക്ക്‌ലോഡ് ആവശ്യപ്പെടുന്ന റീഡ് പാറ്റേണുകളെ പിന്തുണയ്ക്കുന്നു. പ്രസക്തമായ പേജുകളുടെ കാൻഡിഡേറ്റ് സെറ്റ് ലഭിക്കുന്നതിന് ഒരു ക്വറി റിട്രീവലിലൂടെയും റാങ്കിംഗിലൂടെയും കടന്നുപോയ ശേഷം, ആ പേജുകളുടെ ഉള്ളടക്കത്തിനായി ഹോട്ട് സ്റ്റോറിലേക്ക് ബൾക്കായി ക്വറി ചെയ്യുന്നു. ഈ റീഡ് അഭ്യർത്ഥനകൾ റൂട്ടറിൽ എത്തിച്ചേരുകയും അനുബന്ധ ഡാറ്റാ നോഡിലേക്ക് റൂട്ട് ചെയ്യപ്പെടുകയും ചെയ്യുന്നു. സാധ്യമെങ്കിൽ ക്രോസ്-സോൺ ലേറ്റൻസി കുറയ്ക്കുന്നതിന് ഒരേ അവൈലബിലിറ്റി സോണിലെ ഒരു നോഡിലേക്ക് അഭ്യർത്ഥനകൾ അയക്കുന്നതിന് റൂട്ടർ മുൻഗണന നൽകുന്നു. കുറഞ്ഞ ലേറ്റൻസിയിൽ ഒന്നിലധികം കികൾ ഒരേസമയം ഫെച്ച് ചെയ്യാൻ രൂപകൽപ്പന ചെയ്തിട്ടുള്ള RocksDB ബാച്ച്-റീഡ് API ആയ MultiGet ഉപയോഗിച്ച് ഓരോ ഡാറ്റാ നോഡിനും പേജ് ഉള്ളടക്കങ്ങൾ ഫെച്ച് ചെയ്യാൻ കഴിയും. ഒരു നോഡിന് പ്രതികരിക്കാൻ വൈകുകയാണെങ്കിൽ, സിസ്റ്റത്തിന് മറ്റൊരു നോഡിലെ മറ്റൊരു പാർട്ടീഷൻ റെപ്ലിക്കയും ക്വറി ചെയ്യാൻ കഴിയും, ഇത് ടെയിൽ ലേറ്റൻസി മെച്ചപ്പെടുത്തുന്നു.

ഞങ്ങളുടെ വർക്ക്ഫ്ലോ ആവശ്യമില്ലാത്ത പൊതുവായ സവിശേഷതകൾ നടപ്പിലാക്കുന്നത് ഒഴിവാക്കാനും ഞങ്ങൾക്ക് കഴിയും. ഉദാഹരണത്തിന്, മിക്ക ഡാറ്റാബേസുകളും സ്ഥിരത ഉറപ്പുകളും (consistency guarantees) ഇടപാട് പിന്തുണയും വാഗ്ദാനം ചെയ്യുന്നു, എന്നാൽ ഞങ്ങളുടെ ഹോട്ട് സ്റ്റോറിന് ഇടപാടുകളോ സിൻക്രണൈസ് ചെയ്ത റെപ്ലിക്കകളോ ആവശ്യമില്ല. ഒരു ഡോക്യുമെന്റ് എഴുതപ്പെടുന്നതും അത് റീഡുകൾക്കായി ലഭ്യമാകുന്നതും തമ്മിൽ ചെറിയ ഇടവേള ഉണ്ടാകുന്നത് സ്വീകാര്യമാണ്, കൂടാതെ ഒരു റെപ്ലിക്ക മറ്റൊതിനേക്കാൾ വേഗത്തിൽ ഡാറ്റ ഇൻജസ്റ്റ് ചെയ്യുന്നതും കുഴപ്പമില്ല. ഞങ്ങൾക്ക് ആവശ്യമില്ലാത്ത സവിശേഷതകൾ ഒഴിവാക്കുന്നത് ഞങ്ങളുടെ സിസ്റ്റത്തിന്റെ ഓവർഹെഡും ചെലവും കുറയ്ക്കുന്നു.

വലുതാക്കുക

Pillar-ഉം Lorry-യും: ഡ്യൂറബിൾ റൈറ്റ് പാത്ത്

ഞങ്ങൾ ക്രാൾ ചെയ്യുകയും പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്ന എല്ലാ കാര്യങ്ങളുടെയും ട്രാക്ക് ഒരു പ്രത്യേക സ്റ്റോറേജ് ലെയർ സൂക്ഷിക്കുന്നു, അപ്ഡേറ്റുകൾ വെർഷൻ ചെയ്ത ഡോക്യുമെന്റ് സ്റ്റേറ്റിലേക്ക് ലയിപ്പിക്കുകയും ആവശ്യമായ റെപ്രസന്റേഷനുകൾ CobbleDB-യിലേക്കും സെർച്ച് ഇൻഡക്സിലേക്കും പബ്ലിഷ് ചെയ്യുകയും ചെയ്യുന്നു. ഈ ആവശ്യത്തിനായി ഞങ്ങൾ ഞങ്ങളുടെ ഡോക്യുമെന്റ് സ്റ്റേറ്റും പബ്ലിഷിംഗ് ലെയറുമായ Pillar നിർമ്മിച്ചു.

Pillar-ന് പിന്നിൽ YTsaurus പ്രവർത്തിക്കുന്നു. ഇത് പേജ് ഘടകങ്ങൾ (മെറ്റാഡാറ്റ, ചങ്കുകൾ, എംബെഡിംഗുകൾ പോലുള്ളവ) പ്രത്യേക YTsaurus ടേബിൾ ഫാമിലികളിൽ സൂക്ഷിക്കുന്നു. അടിസ്ഥാന മോഡലുകൾക്ക് മാറാൻ കഴിയുന്ന തരത്തിൽ ഒന്നിനെ മറ്റൊന്ന് ഓവർറൈറ്റ് ചെയ്യാതെ ഒന്നിലധികം റെപ്രസന്റേഷനുകൾ സഹവർത്തിക്കാൻ അനുവദിച്ചുകൊണ്ട് ഇത് ചങ്കുകളുടെയും എംബെഡിംഗുകളുടെയും പതിപ്പുകൾ ട്രാക്ക് ചെയ്യുന്നു. Pillar-ഉം YTsaurus-ഉം കുറഞ്ഞ ചെലവിലുള്ള HDD സ്റ്റോറേജ് ഉപയോഗിക്കുന്നതിനാൽ, ഞങ്ങൾക്ക് മുമ്പ് DynamoDB-യിൽ സൂക്ഷിച്ചിരുന്നതിനേക്കാൾ വളരെ বেশি ഡോക്യുമെന്റുകൾ സൂക്ഷിക്കാൻ കഴിയും.

Pillar ഉപസെറ്റുകൾ, അല്ലെങ്കിൽ പുതിയ പേജുകൾ അല്ലെങ്കിൽ ഉയർന്ന മൂല്യമുള്ള പേജുകൾ പോലെയുള്ള പോളിസി-നിർവചിച്ച പേജ് ഗ്രൂപ്പുകൾ ട്രാക്ക് ചെയ്യുന്നു. CobbleDB പോലുള്ള ഡൗൺസ്ട്രീം ഘടകങ്ങളിലേക്ക് ഏതൊക്കെ അപ്ഡേറ്റുകളാണ് കൈമാറേണ്ടതെന്ന് ഉപസെറ്റ് അംഗത്വം നിർണ്ണയിക്കുന്നു. CobbleDB കൂടുതൽ ചെലവേറിയ NVMe സ്റ്റോറേജ് ഉപയോഗിക്കുന്നു, അതിനാൽ സെർച്ച് ഫലങ്ങളിൽ ഞങ്ങൾ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുന്ന ഡോക്യുമെന്റുകൾ മാത്രമാണ് ഞങ്ങൾ എക്സ്പോർട്ട് ചെയ്യുന്നത്. ഒരു പേജിന്റെ ഉള്ളടക്കം അപ്ഡേറ്റ് ചെയ്യപ്പെടുമ്പോൾ, അല്ലെങ്കിൽ അത് ഒരു ഉപസെറ്റിലേക്ക് ചേർക്കുകയോ നീക്കം ചെയ്യുകയോ ചെയ്യുമ്പോൾ, ബന്ധപ്പെട്ട എക്സ്പോർട്ട് ജോലി ക്യൂ ചെയ്യേണ്ട ചുമതല Pillar-നാണ്.

കൃത്യത ഉറപ്പാക്കുന്നതിനായി ആറ്റോമിക് YTsaurus ഇടപാടുകൾ സ്റ്റേറ്റ്, എക്സ്പോർട്ട് ഇൻ്റെന്റുകൾ, ഉപയോഗിച്ച ഇൻപുട്ട് എന്നിവ ഉൾക്കൊള്ളുന്നു. ഒരു ഇടപാട് വിജയകരമായി പൂർത്തിയാകുന്നതിന്, സിസ്റ്റം ഡ്യൂറബിൾ സ്റ്റേറ്റ് അപ്ഡേറ്റ് ചെയ്യണം, ഇൻപുട്ട് അക്കൗണ്ട് ചെയ്തതായി അടയാളപ്പെടുത്തണം, കൂടാതെ ആവശ്യമായ എല്ലാ എക്സ്പോർട്ടുകളും ക്യൂ ചെയ്യണം; ഇടപാട് അബോർട്ട് ചെയ്യുകയാണെങ്കിൽ, ഒരു ലെയറിലും മാറ്റങ്ങൾ വരുത്തില്ല.

പാർട്ടീഷന് അനുസരിച്ച് അപ്ഡേറ്റുകൾ ബാച്ച് ചെയ്യണമെന്ന് CobbleDB പ്രതീക്ഷിക്കുന്നു. Lorry എന്ന് ഞങ്ങൾ വിളിക്കുന്ന സ്റ്റേറ്റ്‌ലെസ്സ് സേവനം Pillar എക്സ്പോർട്ടുകളെ ഈ ഫോർമാറ്റിലേക്ക് പരിവർത്തനം ചെയ്യുന്നു. പെർസിസ്റ്റന്റ് ആയ പാർട്ടീഷൻ-അലൈൻഡ് ക്യൂവിൽ നിന്ന് എക്സ്പോർട്ട് റെക്കോർഡുകൾ വായിക്കുക, പാർട്ടീഷൻ തിരിച്ചുള്ള ബാച്ച് ഫയലുകളായി അവ ശേഖരിക്കുക, അവ CobbleDB-ക്ക് കൈമാറുക എന്നിവ മാത്രമാണ് ഇതിന്റെ ഏക ജോലി.

Lorry-ക്കും Cobble-നും ഇടയിൽ, ഒരു അധിക പ്രോട്ടോക്കോൾ ഡാറ്റ പ്ലെയ്‌നെ (S3) കൺട്രോൾ പ്ലെയ്‌നിൽ നിന്ന് വേർപെടുത്തുന്നു. Lorry ഒരു അദ്വിതീയ ഐഡന്റിഫയറിന് കീഴിൽ ബാച്ച് S3-ലേക്ക് എഴുതുകയും Cobble-ൽ ബാച്ച് രജിസ്റ്റർ ചെയ്യുകയും ചെയ്യുന്നു. ഇൻജസ്റ്റ് ചെയ്യേണ്ട അടുത്ത S3 ബാച്ചിനായി Cobble പാർട്ടീഷൻ റെപ്ലിക്കകൾ ബാച്ച് അല്ലെങ്കിൽ കൺട്രോൾ പ്ലേൻ API സ്വതന്ത്രമായി ക്വറി ചെയ്യുകയും കാലഗണനാ ക്രമത്തിൽ ബാച്ച് അപ്ഡേറ്റുകൾ അസിൻക്രണസ് ആയി പ്രയോഗിക്കുകയും ചെയ്യുന്നു. ഇതിനർത്ഥം പതുക്കെ വരുന്ന അല്ലെങ്കിൽ റിക്കവർ ചെയ്യുന്ന ഒരു നോഡിന് സിസ്റ്റത്തിന്റെ ബാക്കി ഭാഗങ്ങളെ മന്ദഗതിയിലാക്കുന്നതിന് പകരം സ്വന്തം വേഗതയിൽ പിടിച്ചെടുക്കാൻ കഴിയും എന്നാണ്.

വലുതാക്കുക

പുതിയ പാത്ത് തത്സമയ പ്രോസസ്സിംഗ് ഇടപാടിനെ ഹോട്ട്-സ്റ്റോർ ഇൻജഷനിൽ നിന്ന് വേർപെടുത്തുകയും ഇൻക്രിമെന്റൽ അപ്ഡേറ്റുകൾക്കും ബൾക്ക് റീബിൽഡുകൾക്കുമായി വീണ്ടും പ്ലേ ചെയ്യാൻ കഴിയുന്ന (replayable) ഒരു പാത്ത് നൽകുകയും ചെയ്യുന്നു. ഡ്യൂറബിൾ ഡോക്യുമെന്റ് സ്റ്റേറ്റിലെ അപ്ഡേറ്റുകൾ റീഡ് പാത്ത് ലേറ്റൻസിയെ തടസ്സപ്പെടുത്തുന്നില്ലെന്ന് ഈ തൊഴിൽവിഭജനം ഉറപ്പാക്കുന്നു.

വാലിഡേഷൻ

5x വേഗതയേറിയത്

ഹോട്ട് സ്റ്റോർ മൈഗ്രേറ്റ് ചെയ്തതിന് ശേഷം, മധ്യസ്ഥ ബാച്ച്-റീഡ് ലേറ്റൻസി 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-യുടെ സംഭാവന വേർതിരിച്ചറിയാൻ, സജ്ജീകരണത്തിന്റെ മറ്റ് വശങ്ങളെല്ലാം മാറ്റമില്ലാതെ നിലനിർത്തി. എന്നിരുന്നാലും, ഇതൊരു ഒബ്സർവേഷണൽ ബിഫോർ-ആൻഡ്-ആഫ്റ്റർ താരതമ്യം മാത്രമായി തുടരുന്നു; നിയന്ത്രിത സാഹചര്യങ്ങളിലെ ഒരേ അഭ്യർത്ഥനകൾക്ക് പകരം സിസ്റ്റങ്ങൾ തത്സമയ പ്രൊഡക്ഷൻ ട്രാഫിക് സേവിച്ചത് വ്യത്യസ്ത സമയങ്ങളിലാണ്. അതിനാൽ ഒരു സിന്തറ്റിക് ബെഞ്ച്മാർക്കിലും രണ്ട് സിസ്റ്റങ്ങളുടെയും പ്രകടനം ഞങ്ങൾ അളന്നു. പ്രൊഡക്ഷനിൽ കാണുന്ന അഭ്യർത്ഥനകൾ ഏകദേശമായി കണക്കാക്കാൻ, 10-15 കികളുടെ ബാച്ചുകളും 100B മുതൽ 100 KiB വരെയുള്ള വാല്യൂകളും ഉപയോഗിച്ച് ഞങ്ങൾ രണ്ടിലും ക്വറി ചെയ്തു.

വലുതാക്കുക

ഈ സന്ദർഭത്തിൽ DynamoDB ബുദ്ധിമുട്ടുന്നു, കാരണം ഇതിന്റെ മാനേജഡ് റീഡ് പാത്ത് ഈ വലിപ്പത്തിലുള്ള ബാച്ച്ഡ് റീഡുകൾക്കായി ട്യൂൺ ചെയ്യാൻ കഴിയില്ല. ഇതിനു വിപരീതമായി, പ്ലേസ്‌മെന്റ്, കാഷിംഗ്, റെപ്ലിക്ക നിയന്ത്രണങ്ങൾ എന്നിവ ഞങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിനാൽ CobbleDB കൃത്യമായി ഈ സജ്ജീകരണത്തിനായി ഒപ്റ്റിമൈസ് ചെയ്തിരിക്കുന്നു. ഇത് പാർട്ടീഷൻ അനുസരിച്ച് കികളെ ഗ്രൂപ്പ് ചെയ്യുകയും പാർട്ടീഷൻ റെപ്ലിക്കകൾക്കെതിരെ സമാന്തരമായി റീഡുകൾ പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുന്നു, കൂടാതെ മറ്റ് റെപ്ലിക്കകൾക്കെതിരെ പതുക്കെ വരുന്ന റീഡുകൾ ഹെഡ്ജ് ചെയ്യാനും കഴിയും. ഈ ഡിസൈൻ ചോയ്‌സുകൾ പ്രൊഡക്ഷൻ എൻവയോൺമെന്റിൽ വേഗത്തിലുള്ള റീഡുകളിലേക്ക് വിവർത്തനം ചെയ്യുന്നുവെന്ന് ഞങ്ങളുടെ ഫലങ്ങൾ തെളിയിക്കുന്നു.

20% വില കുറവ്

CobbleDB-ക്ക് DynamoDB-യേക്കാൾ വില വളരെ കുറവാണ്. സ്റ്റോറേജിന് പുറമേ, വായിക്കുന്നതോ എഴുതുന്നതോ ആയ ഓരോ ബൈറ്റിനും DynamoDB ഫീസ് ഈടാക്കുന്നു. ഞങ്ങളുടെ കോർപ്പസിന്റെയും സെർവിംഗ് ട്രാഫിക്കിന്റെയും സ്കെയിലിൽ, ഉപയോഗത്തെ അടിസ്ഥാനമാക്കിയുള്ള ഈ ഫീസുകൾ മൊത്തം ചെലവിന്റെ ഗണ്യമായ ഭാഗമായി മാറുന്നു. തുടർച്ചയായ അപ്ഡേറ്റുകൾ റൈറ്റ് കപ്പാസിറ്റി ഉപഭോഗം ചെയ്യുന്നു, അതേസമയം ഒരു ക്വറിക്കായി ഫെച്ച് ചെയ്ത തയ്യാറാക്കിയ പേജുകളുടെ ഓരോ ബാച്ചും റീഡ് കപ്പാസിറ്റി ഉപഭോഗം ചെയ്യുന്നു.

സ്റ്റോറേജ് വലുപ്പം, റൈറ്റ് കപ്പാസിറ്റി യൂണിറ്റുകൾ, റീഡ് കപ്പാസിറ്റി യൂണിറ്റുകൾ എന്നിവയുടെ ആന്തരിക കണക്കുകളെ അടിസ്ഥാനമാക്കി ഞങ്ങൾ ചെലവ് ലാഭം കണക്കാക്കി. എല്ലാ കമ്മറ്റ്‌മെന്റ് ടയറിലും, DynamoDB-യേക്കാൾ കുറഞ്ഞത് 20% എങ്കിലും വില കുറവാണ് CobbleDB-ക്ക്. കംപ്രഷനിൽ നിന്നുള്ള ബാക്ക്അപ്പ് ലാഭം ഈ ഫലങ്ങൾ കണക്കിലെടുക്കാത്തതിനാൽ, യഥാർത്ഥ ലാഭം ഇതിലും ഉയർന്നതായിരിക്കാം.

ഇത് നിർമ്മിക്കാൻ AI ഏജന്റുകളുടെ ഒരു കൂട്ടം ഞങ്ങളെ എങ്ങനെ സഹായിക്കുന്നു

CobbleDB-യും അനുബന്ധ ഇൻഫ്രാസ്ട്രക്ചറും നിർമ്മിക്കുന്നത് നിസ്സാരമായ കാര്യമല്ലായിരുന്നു. CobbleDB-യുടെ കോർ ഡാറ്റാബേസ് മാത്രം ഏകദേശം 40,000 വരികൾ Rust കോഡാണ്, കൂടാതെ പ്രൊഡക്ഷൻ സ്കെയിലിൽ കൃത്യതയും ഫെയിലർ ബിഹേവിയറും പരിശോധിക്കുന്നതിനും, പ്രോസസ്സിംഗ്, സെർവിംഗ് പാത്തുകൾ എന്നിവയുമായി CobbleDB സംയോജിപ്പിക്കുന്നതിനും, തത്സമയ ട്രാഫിക്കിലേക്ക് സുരക്ഷിതമായി മാറ്റുന്നതിനും മൈഗ്രേഷന് വിപുലമായ ജോലികൾ ആവശ്യമായിരുന്നു.

കോഡിംഗ് ഏജന്റുകളുടെ ഒരു സ്വാം പ്രവർത്തിപ്പിക്കുന്ന ഒരു ആന്തരിക സിസ്റ്റം ഉപയോഗിച്ച് ഞങ്ങൾ ഈ ശ്രമം വേഗത്തിലാക്കി. സിസ്റ്റം വളരെ പെർസിസ്റ്റന്റ് ആയാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്; ഇത് സെഷനുകളിലുടനീളം പ്രോജക്റ്റിന്റെ ലക്ഷ്യങ്ങൾ, സജീവമായ അപകടസാധ്യതകൾ, റെപ്പോസിറ്ററി ചരിത്രം, മുൻ തീരുമാനങ്ങൾ എന്നിവ നിലനിർത്തുന്നു.

ഇത്തരം പ്രൊആക്ടീവ് ആയ, എപ്പോഴും പ്രവർത്തിക്കുന്ന ഏജന്റുകളുടെ ഒരു കൂട്ടത്തെ ഞങ്ങൾ CobbleDB പ്രോജക്റ്റിനായി നിയോഗിച്ചു. ഇതിനകം നടന്നുകൊണ്ടിരിക്കുന്ന ജോലിയുടെ കൃത്യമായ മാതൃക നിർമ്മിക്കുക എന്നതായിരുന്നു അവരുടെ ആദ്യത്തെ ചുമതല. അവർ പ്രോജക്റ്റ് ത്രെഡ് പരിശോധിക്കുകയും സജീവമായ ത്രെഡുകൾ പരിശോധിക്കുകയും, അപൂർണ്ണമായ ഐറ്റങ്ങളെ അവയുടെ pull request-കളുമായും ഉടമകളുമായും ബന്ധിപ്പിക്കുകയും, സിസ്റ്റം ആരോഗ്യത്തിന്റെയും അടുത്ത പ്രവർത്തനങ്ങളുടെയും നിലവിലെ വിവരങ്ങൾ നൽകുകയും ചെയ്തു. അവിടെ നിന്ന്, അവർ എഞ്ചിനീയറിംഗ് ലൂപ്പിന്റെ നിരവധി ഭാഗങ്ങളിൽ പ്രവർത്തിച്ചു:

• കോഡും ഇൻഫ്രാസ്ട്രക്ചർ മാറ്റങ്ങളും അവലോകനം ചെയ്തു.
• സുരക്ഷിതമല്ലാത്ത റീസ്റ്റോർ അനുമാനങ്ങൾ, കാലഹരണപ്പെട്ട 빌드 റഫറൻസുകൾ, റൺടൈമിൽ പരാജയപ്പെടുന്ന കോൺഫിഗറേഷനുകൾ എന്നിവ ഉൾപ്പെടെ എളുപ്പത്തിൽ നഷ്ടപ്പെടാൻ സാധ്യതയുള്ള തടസ്സങ്ങൾ കണ്ടെത്തി.
• ഫോക്കസ് ചെയ്ത ഫിക്സുകൾ, ടെസ്റ്റുകൾ, മോണിറ്ററിംഗ് മാറ്റങ്ങൾ, പ്രവർത്തനപരമായ ഡോക്യുമെന്റേഷൻ എന്നിവ തയ്യാറാക്കി.
• പ്രൊഡക്ഷൻ പ്രവർത്തനങ്ങൾ മനുഷ്യർ വ്യക്തമായി സ്വന്തമാണെന്ന് നിലനിർത്തിക്കൊണ്ട് CI, റിവ്യൂ, ഇൻഫ്രാസ്ട്രക്ചർ ഗേറ്റുകൾ എന്നിവ ട്രാക്ക് ചെയ്തു.
• നിരീക്ഷിച്ച സിസ്റ്റം സ്റ്റേറ്റിനെ റോൾഔട്ടിന്റെ വിജയ മാനദണ്ഡവുമായി താരതമ്യം ചെയ്തുകൊണ്ട് നിരീക്ഷിച്ച റോൾഔട്ടുകളും ബാക്ക്അപ്പ് അല്ലെങ്കിൽ റീസ്റ്റോർ വ്യായാമങ്ങളും നടത്തി.
• എഞ്ചിനീയർമാർക്ക് എന്താണ് ഷിപ്പ് ചെയ്തത്, എന്താണ് തടസ്സപ്പെട്ടിരിക്കുന്നത്, എവിടെയാണ് മനുഷ്യന്റെ വിധിതീർപ്പ് ഇനിയും ആവശ്യമായി വരുന്നത് എന്ന് കാണാൻ കഴിയുന്ന തരത്തിൽ പ്രോജക്റ്റ് റീഡൗട്ടുകൾ പരിപാലിച്ചു.

എഞ്ചിനീയർമാർ ഇപ്പോഴും ആർക്കിടെക്ചർ സജ്ജമാക്കുകയും, പ്രത്യാഘാതമുള്ള മാറ്റങ്ങൾ അവലോകനം ചെയ്യുകയും, പ്രൊഡക്ഷൻ പ്രവർത്തനങ്ങൾക്ക് അനുമതി നൽകുകയും ചെയ്തു. ആ തീരുമാനങ്ങൾക്കിടയിലുള്ള തുടർച്ചയായ പരിശോധനയും ഫോളോ-ത്രൂവും ഏജന്റുകൾ കൈകാര്യം ചെയ്തു. ഇത് ഒരു ചെറിയ ടീമിനെ പ്രോജക്റ്റ് കാര്യക്ഷമമായി മുന്നോട്ട് കൊണ്ടുപോകാൻ അനുവദിച്ചു - കോർ CobbleDB ഇൻഫ്രാസ്ട്രക്ചർ രണ്ട് മനുഷ്യ എഞ്ചിനീയർമാരും നൂറുകണക്കിന് AI ഏജന്റുകളും ചേർന്ന് രണ്ട് മാസം കൊണ്ടാണ് നിർമ്മിച്ചത്.

ഉപസംഹാരം

CobbleDB ഒരു പൊതുപ്രയോജന ഡാറ്റാബേസ് അല്ല; അസിങ്ക്രോണസ് പ്രോസസ്സിംഗ് പൈപ്പ്‌ലൈനിലൂടെ നൽകുന്ന തയ്യാറാക്കിയ പേജ് റെക്കോർഡുകളുടെ ആവർത്തിച്ച ബാച്ച് റീഡുകൾ ഉൾക്കൊള്ളുന്ന ഞങ്ങളുടെ നിർദ്ദിഷ്ട വർക്ക്‌ലോഡിനായി പ്രത്യേകമായി നിർമ്മിച്ചതാണ് ഇത്. സ്ഥിരതയുള്ള സ്റ്റേറ്റ്, അപ്‌ഡേറ്റ് ഡെലിവറി, ക്വറി-സമയ സർവിംഗ് എന്നിവ വേർതിരിക്കുന്നതിലൂടെ, ഒരൊറ്റ ഡാറ്റാബേസ് ഇന്റർഫേസിനെ ഇവയൊക്കെയും ഉൾക്കൊള്ളാൻ നിർബന്ധിക്കാതെയും ലൈവ് ക്വറി പാതയിൽ പരിപാലന ജോലികൾ ചുമത്താതെയും ഓരോ ഉത്തരവാദിത്വവും സ്വതന്ത്രമായി ഓപ്റ്റിമൈസ് ചെയ്യാൻ ഞങ്ങൾക്ക് കഴിയും. CobbleDB-ലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുന്നത് മധ്യസ്ഥവും ടെയിൽ ലേറ്റൻസിയും ഗണ്യമായി മെച്ചപ്പെടുത്തി, ഇൻഫ്രാസ്ട്രക്ചർ ചെലവുകളും കുറച്ചു.

ഞങ്ങൾ ഇൻ-ഹൗസ് ആയി 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}
}