ഏജന്റ് ബക്കറ്റ്: ട്രില്യൺ-ലെവൽ ഏജന്റ് നേറ്റീവ് സ്റ്റോറേജ് ബക്കറ്റ്

ഇന്ന് AI ഏജന്റുകൾ കൂൺ പോലെ മുളച്ചുപൊന്തുന്ന ഈ കാലത്ത്, ഡെവലപ്പർമാർ അഭൂതപൂർവമായ വേഗത്തിൽ ഭാവനാത്മകമായ സ്മാർട്ട് ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുകയാണ്. കോഡ് എഴുതാൻ സഹായിക്കുന്ന പ്രോഗ്രാമിംഗ് അസിസ്റ്റന്റുകൾ മുതൽ ഒരു വാക്യം കൊണ്ട് ഒരു സിനിമ നിർമ്മിക്കുന്ന ക്രിയേറ്റീവ് ടൂളുകൾ വരെ, എപ്പോഴും തയ്യാറായിരിക്കുന്ന വ്യക്തിഗത സ്മാർട്ട് അസിസ്റ്റന്റുകൾ വരെ, ഏജന്റുകൾ നമ്മൾ ഡിജിറ്റൽ ലോകവുമായി ഇടപെടുന്ന രീതിയെ മാറ്റിയെഴുതുകയാണ്. ഈ തരംഗത്തിന് പിന്നിൽ, ഒരു പൊതുധാരണ കൂടുതൽ വ്യക്തമാവുകയാണ്: സെർവർലെസ് ആർക്കിടെക്ചറുകൾ (Lambda പോലുള്ളവ), വലിയ ഭാഷാ മോഡലുകൾ (LLM), ക്ലൗഡ് സ്റ്റോറേജ് (S3, TOS പോലുള്ളവ), Vibe Coding എന്നിവയുടെ സഹായത്തോടെ ആർക്കും 30 മിനിറ്റിനുള്ളിൽ സ്വന്തമായി ഒരു AI ഏജന്റിനെ വേഗത്തിൽ നിർമ്മിക്കാൻ കഴിയും.

"ഉപയോഗിക്കാൻ കഴിയുന്നത്" മുതൽ "നല്ല രീതിയിൽ ഉപയോഗിക്കാൻ കഴിയുന്നത്" എന്നതിലേക്ക് വരുമ്പോൾ, ഏജന്റ് ഡെവലപ്പർമാർ "കളിപ്പാട്ടങ്ങളിൽ" നിന്ന് "പ്രൊഡക്ഷൻ-ഗ്രേഡ് ആപ്ലിക്കേഷനുകളിലേക്ക്" മാറാൻ ശ്രമിക്കുമ്പോൾ ഇപ്പോളും ചില പ്രശ്നങ്ങളെ അഭിമുഖീകരിക്കേണ്ടി വരുന്നു. ബിസിനസ്സ് വലിയ തോതിലുള്ള ഉപയോക്താക്കളിലേക്ക് എത്തുമ്പോൾ, ഡെവലപ്പർമാർ വളരെ സങ്കീർണ്ണമായ ഒരു വെല്ലുവിളി നേരിടേണ്ടിവരുന്നു: വലിയ അളവിലുള്ള അന്തിമ ഉപയോക്താക്കൾക്കായി ഒബ്ജക്റ്റ് സ്റ്റോറേജിൽ എങ്ങനെ പൂർണ്ണമായ സ്റ്റോറേജ് പരിഹാരം നിർമ്മിക്കാം? മിക്ക ഡെവലപ്പർമാരെയും സംബന്ധിച്ചിടത്തോളം, ഇത് ഒരു സാങ്കേതിക പ്രശ്നം മാത്രമല്ല, ഏജന്റിന്റെ വലിയ തോതിലുള്ള വിതരണത്തെ തടസ്സപ്പെടുത്തുന്ന ഒരു വലിയ തടസ്സം കൂടിയാണ്. AI-യുടെ സഹായത്തോടെയുള്ള സ്റ്റോറേജ് ഡിസൈനിലൂടെ മൾട്ടി-ടെനന്റ് സിസ്റ്റങ്ങളുടെ നിർമ്മാണ പ്രക്രിയയെ ലളിതമാക്കാനും കൂടുതൽ മികച്ച ഏജന്റ് ശേഷി നൽകാനും Agent Bucket ലക്ഷ്യമിടുന്നു.

കോടിക്കണക്കിന് ഉപയോക്താക്കൾ എത്തുമ്പോൾ, പരമ്പരാഗത ഒബ്ജക്റ്റ് സ്റ്റോറേജ് "മതിയാകാതെ വരുന്നു"

നിങ്ങൾ ഒരു തരംഗം സൃഷ്ടിച്ച ഒരു AIGC ആപ്ലിക്കേഷൻ വികസിപ്പിച്ചെന്ന് കരുതുക. ഓരോ ഉപയോക്താവും ധാരാളം ചിത്രങ്ങളും വീഡിയോകളും താൽക്കാലിക ഫയലുകളും ഉണ്ടാക്കുകയും സംഭരിക്കുകയും ചെയ്യും. ഒരു ഡെവലപ്പർ എന്ന നിലയിൽ, S3, TOS പോലുള്ള വിശ്വസനീയവും എളുപ്പം ഉപയോഗിക്കാനാവുന്നതുമായ ഒബ്ജക്റ്റ് സ്റ്റോറേജ് സേവനങ്ങൾ നിങ്ങൾ തിരഞ്ഞെടുക്കും. എന്നാൽ ഇവിടെയാണ് പ്രശ്നം വരുന്നത്: വലിയ അളവിലുള്ള ഉപയോക്താക്കളുടെ ഡാറ്റ എങ്ങനെ കൈകാര്യം ചെയ്യും?

2022-ൽ S3 പ്രസിദ്ധീകരിച്ച "Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3" എന്ന ബ്ലോഗിൽ രണ്ട് വഴികൾ പറയുന്നുണ്ട്, "ഓരോ ടെനന്റിനും പ്രത്യേക S3 ബക്കറ്റുകൾ ഉപയോഗിക്കുക", അല്ലെങ്കിൽ "പ്രിഫിക്സ് അടിസ്ഥാനമാക്കി S3 ബക്കറ്റുകൾ പങ്കിടുക":

ഓരോ ഉപയോക്താവിനും ഒരു പ്രത്യേക "ബക്കറ്റ്" ഉണ്ടാക്കുക: ഉപയോക്താക്കളുടെ എണ്ണം കുറവായിരിക്കുമ്പോൾ ഇത് സാധ്യമാണ്, എന്നാൽ ഉപയോക്താക്കളുടെ എണ്ണം പതിനായിരക്കണക്കിനോ ലക്ഷക്കണക്കിനോ ആയി ഉയരുമ്പോൾ, ബക്കറ്റുകളുടെ എണ്ണം പെട്ടെന്ന് വർദ്ധിക്കുകയും മാനേജ്മെന്റ് ചിലവുകളും റിസോഴ്സ് പരിമിതികളും താങ്ങാൻ കഴിയാത്ത അവസ്ഥയിലേക്ക് എത്തുകയും ചെയ്യും. S3 ഒരു റീജിയണിൽ മൊത്തം 10000 ബക്കറ്റുകൾക്കുള്ള ക്വാട്ട നൽകുന്നു, എന്നാൽ പ്രചാരത്തിലുള്ള AI ശേഷികൾക്ക്, 10000 എന്നത് വളരെ കുറഞ്ഞ അളവാണ്.

AWS S3 Bucket-Per-Tenant Model

ഒരേ ബക്കറ്റിൽ തന്നെ "പ്രിഫിക്സ്" ഉപയോഗിച്ച് ഉപയോക്താക്കളെ വേർതിരിക്കുക: ഇതാണ് പ്രധാനപ്പെട്ട പരിഹാരം. ഉദാഹരണത്തിന്, ഉപയോക്താവ് A-യുടെ ഫയലുകൾ user-a/ എന്നതിൽ തുടങ്ങുന്നു, ഉപയോക്താവ് B-യുടെ ഫയലുകൾ user-b/ എന്നതിൽ തുടങ്ങുന്നു, ഇത് കമ്പ്യൂട്ടറിൽ ഫോൾഡറുകൾ ഉപയോഗിച്ച് ഫയലുകൾ കൈകാര്യം ചെയ്യുന്നതുപോലെയാണ്. എന്നാൽ ഒബ്ജക്റ്റ് സ്റ്റോറേജിൽ ഫോൾഡറുകൾ ഇല്ലാത്തതിനാൽ, ഈ രീതിയിൽ "K-V" സ്റ്റോറേജ് സിസ്റ്റത്തിൽ "പൊതുവായ പ്രിഫിക്സ്" (Prefix) ഉപയോഗിച്ച് മൾട്ടി-ടെനന്റുകളെ വേർതിരിക്കുന്നു.

AWS S3 Object Key Prefix-Per-Tenant Model

"ബക്കറ്റ്" അല്ലെങ്കിൽ "പ്രിഫിക്സ്" അടിസ്ഥാനമാക്കിയുള്ള ഈ രീതി കഴിഞ്ഞ പത്ത് വർഷമായി വ്യാപകമായി ഉപയോഗിക്കുന്നു. എന്നാൽ ഇതിന് ചില പ്രശ്നങ്ങളുണ്ട്:

മൾട്ടി-ടെനന്റ് ഐസൊലേഷൻ: എല്ലാ ഉപയോക്താക്കളുടെയും ഡാറ്റ ഒരേ ബക്കറ്റിൽ മിക്സ് ആയിരിക്കും, ഒരു ഉപയോക്താവിന്റെ അസാധാരണമായ ഉയർന്ന ഫ്രീക്വൻസിയിലുള്ള ആക്സസ് മറ്റ് എല്ലാ ഉപയോക്താക്കളെയും ബാധിക്കുകയും "നെയിബർ ഇഫക്റ്റ്" ഉണ്ടാക്കുകയും ചെയ്യും. പെർഫോമൻസ് ഐസൊലേഷനും, തകരാറുകൾ ഐസൊലേറ്റ് ചെയ്യുന്നതും ഇവിടെ സാധ്യമല്ല.
പെർമിഷൻ നിയന്ത്രണം: സങ്കീർണ്ണമായ പെർമിഷൻ പോളിസികൾ (IAM Policy) പരിപാലിക്കാൻ ബുദ്ധിമുട്ടാണ്, കൂടാതെ കോൺഫിഗറേഷനിൽ പിഴവുകൾ സംഭവിക്കാനുള്ള സാധ്യത കൂടുതലാണ്, ഇത് ഉപയോക്താക്കളുടെ ഡാറ്റ അപ്രതീക്ഷിതമായി ആക്സസ് ചെയ്യാൻ ഇടയാക്കും, പ്രത്യേകിച്ചും മറ്റ് ക്ലൗഡ് സേവനങ്ങളുമായി സംവദിക്കുമ്പോൾ അപകടസാധ്യതകൾ കൂടുതലാണ്.
ചിലവ് വ്യക്തത: ഓരോ ഉപയോക്താവും എത്ര സ്റ്റോറേജ് സ്പേസ് ഉപയോഗിച്ചു, എത്ര ട്രാഫിക് ചിലവ് ഉണ്ടായി എന്നതിനെക്കുറിച്ച് കൃത്യമായി അറിയാൻ കഴിയില്ല. ഉപയോഗത്തിനനുസരിച്ച് പണം ഈടാക്കാൻ ആഗ്രഹിക്കുമ്പോൾ, ബില്ലിംഗും അളവെടുപ്പും ഒരുപോലെ ആശയക്കുഴപ്പത്തിലാകും.എന്തുകൊണ്ടാണ് ഈ അടിസ്ഥാന ആവശ്യകതകൾ Agent ഡെവലപ്പർമാർക്ക് ഒബ്ജക്റ്റ് സ്റ്റോറേജിൽ നടപ്പിലാക്കാൻ അൽപ്പം \Agent Bucket ഓരോ ബക്കറ്റിലും 10 കോടി ObjectSet-കളെ പിന്തുണയ്ക്കുന്നു. ഇത്, ഓരോ അന്തിമ ഉപയോക്താവിനും അവരവരുടെ സംഭരണ ഇടം ഉള്ളത് പോലെ, കോടിക്കണക്കിന് ഉപയോക്താക്കൾക്ക് സേവനം നൽകാൻ നിങ്ങളെ സഹായിക്കുന്നു. മൾട്ടി-ടെനന്റ് സംഭരണത്തിന്റെ തലവേദനയില്ലാതെ ഇത് സാധ്യമാക്കുന്നു.

ObjectSet ഡിസൈൻ - ഏജന്റ് സൗഹൃദപരമായ കഴിവുകൾ

Agent Bucket-ലെ ObjectSet ഒരു ലെയർ കൂട്ടിച്ചേർക്കുക മാത്രമല്ല ചെയ്യുന്നത്, മറിച്ച് മൾട്ടി-ടെനന്റ് സാഹചര്യങ്ങളിലെ ഏറ്റവും വലിയ ആവശ്യകതകളെല്ലാം എളുപ്പത്തിൽ ഉപയോഗിക്കാവുന്ന ഫീച്ചറുകളാക്കുന്നു. ObjectSet എന്ന ലെയറിൽ ഡാറ്റയുടെ ഉടമസ്ഥാവകാശം ഉറപ്പിച്ചു കഴിഞ്ഞാൽ, മുൻപ് നടപ്പിലാക്കാൻ ബുദ്ധിമുട്ടുണ്ടായിരുന്ന പല കാര്യങ്ങളും സാധ്യമാകും.

സ്വാഭാവികമായ ഐസൊലേഷൻ (Native Isolation): ObjectSet തലത്തിൽ, ഓരോ ഉപയോക്താവിനും പ്രത്യേക QPS, ബാൻഡ്‌വിഡ്ത്ത് പരിധികൾ, സംഭരണ ശേഷി എന്നിവ നൽകാം. പണം നൽകുന്ന ഉപയോക്താക്കൾക്ക് മികച്ച അനുഭവം ഉറപ്പാക്കാം, സൗജന്യ ഉപയോക്താക്കളുടെ അസാധാരണമായ പ്രവർത്തനങ്ങൾ മറ്റുള്ളവരെ ബാധിക്കില്ല. ഇത് യഥാർത്ഥ Fault Domain Isolation ആണ്, 'അയൽക്കാർ' തമ്മിൽ ഇടപെടില്ല.
സ്വാഭാവികമായ അനുമതികൾ (Native Permission): ഓരോ ObjectSet-നും ഒരു പ്രത്യേക ഡൊമെയ്ൻ ഉണ്ടാകും. ഉപയോക്താവ് A-ക്ക് user-a.yourapp.com എന്ന ഒരു പ്രത്യേക അക്‌സസ്സ് അഡ്രസ്സ് നൽകാനാകും, മുഴുവൻ സ്റ്റോറേജ് ബക്കറ്റിന്റെയും ഡൊമെയ്ൻ വെളിപ്പെടുത്തേണ്ടതില്ല. ഇതിലുള്ള 'രണ്ട് പൂട്ട്' ഡിസൈൻ ശ്രദ്ധേയമാണ്: ആദ്യത്തെ പൂട്ട് ക്ലൗഡ് സർവീസ് പ്രൊവൈഡർ നൽകുന്ന താൽക്കാലിക അക്‌സസ്സ് ക്രെഡൻഷ്യൽ (STS) ആണ്, ഇത് ആപ്ലിക്കേഷൻ ലെയറിലെ അക്‌സസ്സ് നിയന്ത്രിക്കുന്നു; രണ്ടാമത്തെ പൂട്ട് ObjectSet-ന്റെ പ്രത്യേക ഡൊമെയ്നാണ്, ഇത് നെറ്റ്‌വർക്ക് ലെയറിൽ നിന്ന് തന്നെ ഉപയോക്താവിൻ്റെ ഡാറ്റാ സ്പേസിലേക്ക് അക്‌സസ്സ് പരിമിതപ്പെടുത്തുന്നു. ഇത് ഡാറ്റാ സുരക്ഷ വർദ്ധിപ്പിക്കുന്നു.
സ്വാഭാവികമായ മോണിറ്ററിംഗ് (Native Monitoring): മോണിറ്ററിംഗ് ഡാഷ്ബോർഡിൽ, നിങ്ങൾക്ക് മുഴുവൻ ബക്കറ്റിന്റെയും ഡാറ്റ മാത്രമേ കാണാൻ കഴിയൂ എന്ന സ്ഥിതി മാറുന്നു. ഓരോ ObjectSet അനുസരിച്ചും മോണിറ്ററിംഗ് ചാർട്ടുകൾ തരംതിരിക്കാനാകും, ഏത് ഉപയോക്താവാണ് കൂടുതൽ അക്‌സസ്സ് ചെയ്യുന്നതെന്ന് കണ്ടെത്താനും കൃത്യമായ പ്രവർത്തന തീരുമാനങ്ങൾ എടുക്കാനും കഴിയും.
സ്വാഭാവികമായ കഴിവുകൾ (Native Capability Down): മുൻപ് ബക്കറ്റ് തലത്തിൽ മാത്രം ക്രമീകരിക്കാൻ കഴിഞ്ഞിരുന്ന പോളിസികൾ, ഇപ്പോൾ ഓരോ ഉപയോക്താവിനും നൽകാനാകും. വ്യത്യസ്ത ലെവലിലുള്ള ഉപയോക്താക്കൾക്ക് വ്യത്യസ്ത ഡാറ്റാ ലൈഫ് സൈക്കിളുകൾ നൽകാം, അല്ലെങ്കിൽ ഓരോ ObjectSet-നും വ്യത്യസ്ത എൻക്രിപ്ഷൻ കീകൾ ഉപയോഗിക്കാം. ഇത് കൂടുതൽ കൃത്യവും സുരക്ഷിതവുമായ ഡാറ്റാ മാനേജ്മെൻ്റ് നൽകുന്നു.
സ്വാഭാവികമായ അളവ് (Native Metering): ഓരോ ഉപയോക്താവും എത്ര സ്റ്റോറേജ് ഉപയോഗിക്കുന്നുണ്ടെന്ന് അറിയണോ? സ്റ്റോറേജ് ചിലവ് ഓരോ ഉപയോക്താവിനും കൃത്യമായി വീതിക്കണോ? ഇപ്പോൾ ഇത് വളരെ എളുപ്പമാണ്. ഓരോ ObjectSet-ന്റെയും ശേഷിയും ഉപയോഗവും Agent Bucket സ്വയം കണക്കാക്കുന്നു, ഇത് നിങ്ങളുടെ ബില്ലിംഗും വിഹിതവും വ്യക്തമാക്കുന്നു.
സ്വാഭാവികമായ ബില്ലിംഗ് (Native Billing): ഡെവലപ്പർമാർക്ക് ചിലവ് എളുപ്പത്തിൽ വീതിക്കാം, സ്റ്റോറേജ് ഉപയോഗിക്കുന്നതിന്റെ ചിലവ് ഓരോ ഉപയോക്താവിൽ നിന്നും ഈടാക്കാം. ഉദാഹരണത്തിന്, A, B, C എന്നീ ഉപയോക്താക്കൾ ഉപയോഗിച്ചതിനനുസരിച്ച് വ്യത്യസ്ത നിരക്കുകൾ ഈടാക്കാം, ഇത് Agent-ൻ്റെ വാണിജ്യവൽക്കരണത്തിന് സഹായിക്കുന്നു.
സ്വാഭാവികമായ ശേഷി പരിധി (Native Capacity Limit): Agent-ൻ്റെ പ്രവർത്തന ചിലവ് നിയന്ത്രിക്കുന്നതിന്, ഓരോ ObjectSet-നും Quota (ശേഷി പരിധി) നിശ്ചയിക്കാം. പരിധി എത്തുന്നതോടെ, പുതിയ ഫയലുകൾ ഉണ്ടാക്കുന്നത് സിസ്റ്റം തടയും, ഇത് മൾട്ടി-ടെനന്റ് സാഹചര്യങ്ങളിൽ അമിതമായ ഉപയോഗം തടയുന്നു.
സ്വാഭാവികമായ ബുദ്ധി (Native Intelligence): Agent Bucket, Agent-നെ പരമ്പരാഗത ഫയൽ 'സേവ്', 'എടുക്കുക' എന്ന രീതിയിൽ നിന്ന് മാറ്റി, Object-കൾക്ക് സ്വാഭാവികമായ ബുദ്ധി നൽകുന്നു. ഇത് Agent-ൻ്റെ ഒറ്റത്തവണ ഡെവലപ്മെൻ്റിനെ പിന്തുണയ്ക്കുന്നു. ObjectSet-ന് ഒറ്റ ക്ലിക്കിൽ സ്മാർട്ട് ഇൻഡെക്സിംഗ് ആരംഭിക്കാൻ കഴിയും, ഇത് Agent-ന് മൾട്ടിമോഡൽ ചോദ്യോത്തര ശേഷി നൽകുന്നു, പരമ്പരാഗത Object CRUD പ്രവർത്തനങ്ങൾക്ക് പകരമാണിത്. Agentself മോഡ് ഒറ്റ ക്ലിക്കിൽ ആരംഭിക്കാനും വെക്റ്റർ, നോളജ്, മോഡൽ, പ്രോംപ്റ്റ് എന്നിവയെ ബന്ധിപ്പിച്ച്, സാഹചര്യത്തിനനുസരിച്ചുള്ള സബ്-ഏജന്റ് ഫംഗ്ഷനുകൾ നൽകാനും കഴിയും. ഇത് Agent ഡെവലപ്പർമാരെ പ്രധാന ബിസിനസ്സ് വർക്ക്ഫ്ലോയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ അനുവദിക്കുകയും സ്മാർട്ട് വരുമാനം വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു.

ആപ്ലിക്കേഷൻ വളർച്ചയുടെ സാങ്കേതിക വെല്ലുവിളികൾ

ObjectSet എന്ന ആശയം അവതരിപ്പിക്കുന്നതിലൂടെ, കോടിക്കണക്കിന് ഉപയോക്താക്കളുടെ ഡാറ്റ കൈകാര്യം ചെയ്യാൻ Agent Bucket ആപ്ലിക്കേഷൻ ഡെവലപ്പർമാർക്ക് മികച്ചതും കാര്യക്ഷമവുമായ ഒരു മാർഗ്ഗം നൽകുന്നു. ഓരോ ഉപയോക്താവിൻ്റെയും ഡിജിറ്റൽ ആസ്തികൾ സുരക്ഷിതമായി അവരുടെ ObjectSet-ൽ സൂക്ഷിക്കുന്നു, ഇത് സ്വാഭാവികമായി ഐസൊലേഷൻ, ബില്ലിംഗ്, ക്വാട്ട മാനേജ്മെൻ്റ് എന്നിവ നൽകുന്നു.

ആപ്ലിക്കേഷനുകളുടെ എണ്ണം വർധിക്കുന്നതിനനുസരിച്ച്, സെറ്റുകളുടെ എണ്ണത്തിലുള്ള വർധനവ്, ഐസൊലേഷനിലെ ബുദ്ധിമുട്ടുകൾ, ഫിസിക്കൽ തടസ്സങ്ങൾ എന്നിവ വെല്ലുവിളികളായി ഉയർന്നു വരുന്നു:

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

Set Tagging: ഉപയോക്താക്കളെ ഗ്രേഡ് ചെയ്യുന്നതിനുള്ള ടാഗ് മാനേജ്മെൻ്റ്

ObjectSet, നേറ്റീവ് ടാഗ് മാനേജ്മെൻ്റ് രീതികൾ നൽകുന്നു, ഇത് Agent ഡെവലപ്പർമാരെ ഉപയോക്താക്കളെ ഗ്രേഡ് ചെയ്യാൻ സഹായിക്കുന്നു. ഓരോ ഉപയോക്തൃ ലെവലിനും ഒരു ടാഗ് നൽകാനും ഓരോ ടാഗിനും വ്യത്യസ്ത ക്വാട്ടകളും ഫീച്ചറുകളും നൽകാനും കഴിയും. ഈ ടാഗ് നൽകിയിട്ടുള്ള എല്ലാ ObjectSet-നും ഈ ക്വാട്ടകളും ഫീച്ചറുകളും ലഭിക്കും. V1, V2, V3 എന്നീ മൂന്ന് ലെവലുകൾ ഉദാഹരണമായി എടുക്കാം:

V1: സ്ഥിര ലെവൽ, സൗജന്യ ഉപയോക്താക്കൾ, എല്ലാ ObjectSet-കളുടെയും സ്ഥിര ടാഗ്. പരമാവധി 1GiB ഡാറ്റ സംഭരിക്കാൻ കഴിയും. പബ്ലിക് നെറ്റ്‌വർക്ക് വിതരണം 100mbps-ൽ കൂടാൻ പാടില്ല, കൂടാതെ സിംഗിൾ സ്ട്രീം ഡൗൺലോഡ് വേഗത 1mbps ആയി നിയന്ത്രിക്കണം.
V2: തുടക്കക്കാർക്കുള്ള പെയ്ഡ് മെമ്പർമാർ, പരമാവധി 10GiB ഡാറ്റ സംഭരിക്കാൻ കഴിയും. പബ്ലിക് നെറ്റ്‌വർക്ക് വിതരണം 10gbps-ൽ കൂടാൻ പാടില്ല, കൂടാതെ സിംഗിൾ സ്ട്രീം ഡൗൺലോഡ് വേഗത 10mbps ആയി നിയന്ത്രിക്കണം.
V3: ഉയർന്ന തലത്തിലുള്ള പെയ്ഡ് മെമ്പർമാർ, കൂടുതൽ സംഭരണ ശേഷിക്കും പബ്ലിക് നെറ്റ്‌വർക്ക് വിതരണത്തിനുമുള്ള സൗകര്യങ്ങൾക്ക് പുറമെ, അധിക പബ്ലിക് നെറ്റ്‌വർക്ക് ആക്സിലറേഷനും ഉയർന്ന പ്രകടനമുള്ള മീഡിയ ആക്സിലറേഷൻ ശേഷിയും നൽകുന്നു.

വ്യത്യസ്ത ഉപയോക്താക്കളുടെ വളർച്ചയുടെ വിവിധ ഘട്ടങ്ങളിൽ, V1/V2/V3 ടാഗിംഗ് ഉപയോഗിച്ച് ഈ ഉപയോക്താക്കൾക്ക് ഉപയോഗിക്കാവുന്ന റിസോഴ്സുകളും അധിക ഫീച്ചറുകളും Agent ഡെവലപ്പർമാർക്ക് നിയന്ത്രിക്കാനാകും.

Set Tagging ഉപയോക്തൃ ഗ്രേഡിംഗ് മാനേജ്മെൻ്റ്

Set Slice: വലിയ ഉപയോക്തൃ ഡാറ്റയുടെ നേറ്റീവ് ഐസൊലേഷൻ

ഒരു Agent Bucket-ലെ Set-കളുടെ എണ്ണം കോടികളിലെത്തുമ്പോളും ഒബ്ജക്റ്റുകളുടെ എണ്ണം നൂറുകണക്കിന് കോടിയോ ആയിരക്കണക്കിന് കോടിയോ ആകുമ്പോളും, "ഒരു Bucket-ലെ എല്ലാ മെറ്റാഡാറ്റയും ഒരു KV ക്ലസ്റ്ററിൽ കേന്ദ്രീകരിക്കുന്നത്" ശേഷിക്കും പ്രകടനത്തിനും ഒരുപോലെ അപകടകരമാണ്.

Set Slice ഒരു "ലോജിക്കൽ വിഭജനം ഇല്ലാത്തതും ഫിസിക്കൽ വിഭജനം ഉള്ളതുമായ" സമീപനം നൽകുന്നു:

ലോജിക്കലായി നോക്കിയാൽ, നിങ്ങൾ ഒരു Agent Bucket മാത്രമാണ് കൈകാര്യം ചെയ്യുന്നത്.
ഫിസിക്കലായി, Set-കളുടെയും Set-നുള്ളിലെ ഒബ്ജക്റ്റുകളുടെ പേരിന്റെ പരിധിക്കുമനുസരിച്ച്, മെറ്റാഡാറ്റയെ ഒന്നിലധികം Slice-കളായി (കഷണങ്ങൾ) വിഭജിക്കുന്നു. ഓരോ Slice-ഉം വ്യത്യസ്ത ക്ലസ്റ്ററുകളിൽ സംഭരിക്കാൻ കഴിയും. ഒന്നിലധികം Set-കൾ സ്വാഭാവികമായി ഐസൊലേറ്റ് ചെയ്യപ്പെടുന്നു, കൂടാതെ ഒരൊറ്റ Set തിരശ്ചീനമായി വികസിപ്പിക്കാൻ കഴിയും.

Set Slice ഫിസിക്കൽ വിഭജനം

Set Slice എന്നത് ObjectSet കഴിവിൻ്റെ കൂടുതൽ വിപുലീകരണവും ഉറപ്പുവരുത്തലുമാണ്. ഇത് ഫിസിക്കൽ ശേഷിയുടെ പരിമിതികളില്ലാത്ത വികാസത്തിനുള്ള പ്രശ്നം പരിഹരിക്കുന്നു, അതേസമയം ObjectSet മാനേജ്മെൻ്റ് മോഡലിൻ്റെ സ്ഥിരതയും സ്ഥിരതയും ഉറപ്പാക്കുന്നു.

മാനേജ്മെൻ്റ് അതിർത്തി സ്ഥിരമാണ്: ഒരു Agent Bucket-ലെ ഡാറ്റ ഒന്നിലധികം ഫിസിക്കൽ ക്ലസ്റ്ററുകളിലായി വ്യാപിച്ചു കിടക്കുകയാണെങ്കിൽ പോലും, ObjectSet എന്നത് അനുമതികൾ, ക്വാട്ടകൾ, ബില്ലിംഗ്, മോണിറ്ററിംഗ് എന്നിവയുടെ അടിസ്ഥാന യൂണിറ്റായി തുടരുന്നു. ഡെവലപ്പർമാർ ObjectSet-നായി കോൺഫിഗർ ചെയ്യുന്ന പോളിസികൾ (ആക്സസ് കൺട്രോൾ, ശേഷി പരിധി പോലുള്ളവ) ബന്ധപ്പെട്ട എല്ലാ Slice-കളിലും സ്വയമേവ ബാധകമാകും. ഡാറ്റയുടെ അടിസ്ഥാന വിതരണത്തെക്കുറിച്ച് അവർ വിഷമിക്കേണ്ടതില്ല.
ഒരൊറ്റ Set-ന് രേഖീയമായി വികസിക്കാൻ കഴിയും: ഒരു ObjectSet-ലെ ഡാറ്റ അതിവേഗം വർദ്ധിക്കുമ്പോൾ, അതിൻ്റെ ഡാറ്റ സ്വാഭാവികമായി ഒന്നിലധികം Slice-കളിലേക്ക് വിതരണം ചെയ്യപ്പെടും. മൊത്തത്തിലുള്ള ക്ലസ്റ്റർ വികസിക്കുന്നതിനനുസരിച്ച്, ObjectSet-ൻ്റെ ശേഷിയും തടസ്സമില്ലാതെ രേഖീയമായി വർദ്ധിക്കുന്നു. ഡെവലപ്പർമാർ ഈ ObjectSet-നെ വിഭജിക്കുകയോ മാറ്റം വരുത്തുകയോ ചെയ്യേണ്ടതില്ല.
ക്രോസ്-Set റിസോഴ്സ് ഐസൊലേഷൻ: വ്യത്യസ്ത പരിധികളിലുള്ള ഒബ്ജക്റ്റുകളെ വ്യത്യസ്ത ഫിസിക്കൽ ക്ലസ്റ്ററുകളിൽ വിതരണം ചെയ്യുന്നതിലൂടെ, SetSlice ഉയർന്ന തലത്തിലുള്ള റിസോഴ്സ് ഐസൊലേഷൻ നടപ്പിലാക്കുന്നു. ObjectSet-ൻ്റെ ക്വാട്ട മാനേജ്മെൻ്റുമായി ചേർന്ന്, ഒരു വലിയ ObjectSet-ൻ്റെ ഡാറ്റാ വർദ്ധനവ് ഒരു ക്ലസ്റ്ററിലെ മുഴുവൻ റിസോഴ്സുകളും കൈവശപ്പെടുത്തുന്നത് ഫലപ്രദമായി തടയാൻ കഴിയും. ഇത് മറ്റ് ObjectSet-കളുടെ സ്ഥിരതയെ ബാധിക്കാതെ മൊത്തത്തിലുള്ള ശേഷിയുടെ അപകടസാധ്യത നിയന്ത്രിക്കാൻ സഹായിക്കുന്നു.- ലോജിക്കൽ ഏകീകരണം, അനുയോജ്യത: ബിസിനസ്സിനും ഡെവലപ്പർമാർക്കും, അടിയിൽ എത്ര സ്ലൈസുകൾ ഉണ്ടെങ്കിലും, അവർ അഭിമുഖീകരിക്കുന്നത് എല്ലായ്പ്പോഴും യുക്തിപരമായി ഏകീകൃതമായ ഒരു ഏജന്റ് ബക്കറ്റാണ്. ബക്കറ്റുകൾ, ഒബ്ജക്റ്റ് സെറ്റുകൾ, ഒബ്ജക്റ്റുകൾ എന്നിവയ്‌ക്കായുള്ള എല്ലാ പ്രവർത്തന രീതികളും മാറ്റമില്ലാതെ നിലനിർത്തുന്നു, ഇത് മുകളിലെ ലെയർ ആപ്ലിക്കേഷനുകൾക്ക് ശാരീരിക വിപുലീകരണം പൂർണ്ണമായും സുതാര്യമാക്കുന്നു.\n\n## സെറ്റ് ആക്സസ് പോയിന്റ്: ഓരോ ഉപയോക്താവിൻ്റെയും ആക്സസ് പോയിൻ്റുകൾ വേർതിരിക്കുക\n\nഓരോ ഒബ്ജക്റ്റ് സെറ്റിനും സ്വതന്ത്രമായ ആക്സസ് പോയിന്റുകൾ (സ്വതന്ത്ര ഡൊമെയ്‌നുകൾ) തുറക്കാൻ ഏജന്റ് ബക്കറ്റ് പിന്തുണയ്ക്കുന്നു, കൂടാതെ ആക്സസ് പോയിന്റുകളിൽ, വ്യത്യസ്ത സുരക്ഷ, ഐസൊലേഷൻ, ആക്സിലറേഷൻ കഴിവുകൾ വികസിപ്പിക്കുന്നു. ഇതിനായി, സിസ്റ്റം ദശലക്ഷക്കണക്കിന് സ്വതന്ത്ര ആക്സസ് പോയിന്റ് ഷെഡ്യൂളിംഗിനെയും വ്യത്യസ്ത കോൺഫിഗറേഷൻ കഴിവുകളെയും പിന്തുണയ്ക്കേണ്ടതുണ്ട്.\n\nസ്വതന്ത്ര ആക്സസ് ഡൊമെയ്ൻ {$apid}.tos-objectset-ap.volces.com: രണ്ട്-ലെയർ സുരക്ഷാ സംരക്ഷണം\n\n - ഒന്നാമത്തെ ലെയർ ഒബ്സ്ക്യൂരിറ്റി (Obscurity): ഉപയോക്താവ്/ഒബ്ജക്റ്റ് സെറ്റ് സ്വതന്ത്ര സബ്ഡൊമെയ്ൻ, apid ഉയർന്ന എൻട്രോപ്പി ഹാഷിംഗ്, വളരെ കുറഞ്ഞ കൂട്ടിയിടി സാധ്യത, ആക്സസ് ഡൊമെയ്ൻ കാഴ്ചപ്പാടിൽ നിന്ന് ഒരു പ്രത്യേക ഉപയോക്താവിൻ്റെ എൻട്രി ഊഹിക്കാനോ എണ്ണിയെടുക്കാനോ കഴിയില്ല;\n\n - രണ്ടാമത്തെ ലെയർ കണ്ടെയ്ൻമെൻ്റ് (Containment): ഏജൻ്റ് ഡെവലപ്പർമാർ sts ഉപയോഗിച്ച് ഒബ്ജക്റ്റ് സെറ്റ് ലെവൽ ആക്സസ് പെർമിഷനുകൾ വിതരണം ചെയ്യുന്നു, sts ചോർന്നാൽ പോലും, ഒരു നിശ്ചിത ഒബ്ജക്റ്റ് സെറ്റിൻ്റെ പരിമിതമായ സാധുത കാലയളവിനുള്ളിൽ അതിൻ്റെ ആക്സസ് വ്യാപ്തി നിയന്ത്രിക്കാനാകും;\n\nഹ്യൂറിസ്റ്റിക് ഷെഡ്യൂളിംഗ് സിസ്റ്റം: ദശലക്ഷക്കണക്കിന് ഡൊമെയ്ൻ ഷെഡ്യൂളിംഗ് തന്ത്രങ്ങളുടെ കണക്കുകൂട്ടൽ\n\n - ഉപയോക്താവ്/ഒബ്ജക്റ്റ് സെറ്റ്: ടാഗ് അനുസരിച്ച് വ്യത്യസ്ത ആക്സസ് തന്ത്രം\n\n - ഒന്നിലധികം ഉപയോക്താക്കൾ/ഒബ്ജക്റ്റ് സെറ്റുകൾ വ്യത്യസ്ത പബ്ലിക് നെറ്റ്‌വർക്ക് എൻട്രികളിൽ സ്വയമേവ ചിതറിക്കിടക്കുന്നു, ഒരൊറ്റ എൻട്രിയുടെ തകരാർ ഉപയോക്താക്കളുടെ എണ്ണത്തെ നിയന്ത്രിക്കുന്നു\n\n - പൂർണ്ണമായ റീജിയൻ ഇലാസ്റ്റിക് ഷെഡ്യൂളിംഗ്, ഏതെങ്കിലും ഒരൊറ്റ എൻട്രി പോയിൻ്റിൻ്റെ തകരാർ/ഓവർലോഡ് സ്വയമേവ ട്രാഫിക് ബോക്സിംഗ് പൂർത്തിയാക്കുന്നു\n\n - പബ്ലിക് നെറ്റ്‌വർക്ക് ആക്സിലറേഷൻ ഡിസ്ട്രിബ്യൂഷൻ ക്ലാസ് ഉപയോക്താക്കൾ, പബ്ലിക് നെറ്റ്‌വർക്ക് ട്രാൻസ്മിഷൻ ആക്സിലറേഷൻ ടാഗ് അടയാളപ്പെടുത്തുക, സ്വയമേവ ആക്സിലറേഷൻ എൻട്രി ഷെഡ്യൂൾ ചെയ്യുക\n\n - പബ്ലിക് നെറ്റ്‌വർക്ക് റിസ്ക് ക്ലാസ് ഉപയോക്താക്കൾ, റിസ്ക് ടാഗ് അടയാളപ്പെടുത്തുക, സ്വയമേവ പബ്ലിക് നെറ്റ്‌വർക്ക് ഐസൊലേഷൻ എൻട്രി ഷെഡ്യൂൾ ചെയ്യുക, കൂടാതെ പബ്ലിക് നെറ്റ്‌വർക്ക് ബാൻഡ്‌വിഡ്ത്ത് ക്വാട്ട കുറയ്ക്കുക\n\n - ഇൻട്രാനെറ്റ് ക്രോസ്-ഡൊമെയ്ൻ ക്ലാസ് ഉപയോക്താക്കൾ, ക്രോസ്-ഡൊമെയ്ൻ ടാഗ് അടയാളപ്പെടുത്തുക, സ്വയമേവ ഇൻട്രാനെറ്റ് ഡെഡിക്കേറ്റഡ് ലൈൻ ആക്സിലറേഷൻ പാത്ത് ഷെഡ്യൂൾ ചെയ്യുക\n\n - ലോക്കൽ ആക്സിലറേറ്റർ ഉപയോക്താക്കൾ, ആക്സിലറേറ്റർ ടാഗ് അടയാളപ്പെടുത്തുക, സ്വയമേവ ലോക്കൽ ആക്സിലറേറ്റർ മൌണ്ട് ചെയ്യുക\n\n\n\n## പ്രോഗ്രാമിംഗ് അസിസ്റ്റൻ്റ് മുതൽ AI ക്ലൗഡ് ഡിസ്ക് വരെ, ഏജൻ്റ് ബക്കറ്റിന് അനന്തമായ സാധ്യതകൾ\n\nഏജൻ്റ് ബക്കറ്റ് ഏജൻ്റുമാർക്ക് മികച്ച പരിഹാരങ്ങൾ നൽകുന്നു, കൂടാതെ ഒബ്ജക്റ്റ് സെറ്റിൻ്റെ ഡിസൈൻ ആപ്ലിക്കേഷൻ സാഹചര്യങ്ങൾ ഇതിൽ മാത്രം ഒതുങ്ങുന്നില്ല. വലിയ തോതിലുള്ള ടെർമിനൽ ഉപയോക്താക്കൾക്ക് സേവനങ്ങൾ നൽകേണ്ട എല്ലാ ആപ്ലിക്കേഷനുകളിലേക്കും ഇത് എളുപ്പത്തിൽ വികസിപ്പിക്കാൻ കഴിയും:\n\n - കോഡ് ശേഖരം: മുമ്പ്, ഒരു കമ്പനിയോ വ്യക്തിയോ ക്ലൗഡിൽ കോഡ് ഹോസ്റ്റ് ചെയ്യുമ്പോൾ, അക്കൗണ്ട് ഐസൊലേഷനും പെർമിഷൻ നിയന്ത്രണവും നേടുന്നതിന് ഒബ്ജക്റ്റ് സ്റ്റോറേജിന് മുകളിൽ ഒരു - മോഡൽ ഹോസ്റ്റിംഗ് പ്ലാറ്റ്‌ഫോം: വലിയ മോഡലുകൾ ഹോസ്റ്റ് ചെയ്യുന്ന സാഹചര്യങ്ങളിൽ, ഓരോ മോഡലിനും വലിയ വലുപ്പം മാത്രമല്ല, വ്യത്യസ്ത പതിപ്പുകൾ, വെയ്റ്റുകൾ, ഇൻഫറൻസ് കോൺഫിഗറേഷനുകൾ എന്നിവയും ഉണ്ടാകാം. ഓരോ മോഡലിനും ObjectSet ഉണ്ടാക്കുന്നതിലൂടെ, മോഡൽ വെയ്റ്റുകൾ, Tokenizer, കോൺഫിഗറേഷൻ ഫയലുകൾ, അനുബന്ധ വിലയിരുത്തൽ ഡാറ്റ എന്നിവ ഒരേ സ്പേസിൽ പാക്കേജ് ചെയ്ത് ഹോസ്റ്റ് ചെയ്യാൻ കഴിയും. പ്രവർത്തനപരമായ കാര്യങ്ങളിൽ, വ്യത്യസ്ത മോഡലുകൾക്കായി വ്യത്യസ്ത എൻക്രിപ്ഷൻ പോളിസികൾ, ബാക്കപ്പ് പോളിസികൾ, ബാൻഡ്‌വിഡ്ത്ത് നിയന്ത്രണം എന്നിവ സജ്ജീകരിക്കാൻ കഴിയും. അതേസമയം, ഓരോ മോഡലിൻ്റെയും യഥാർത്ഥ ഉപയോഗ ചിലവ് കണക്കാക്കാൻ നേറ്റീവ് മീറ്ററിംഗ് ശേഷി ഉപയോഗിക്കാം, ഇത് മോഡൽ അടിസ്ഥാനത്തിലുള്ള ബില്ലിംഗിനും റിസോഴ്സ് ഷെഡ്യൂളിംഗിനും അടിസ്ഥാനം നൽകുന്നു.
ഡാറ്റ SaaS സേവനം: വലിയ തോതിലുള്ള അന്തിമ ഉപയോക്താക്കൾക്കുള്ള ഡാറ്റാ വിതരണ പ്ലാറ്റ്‌ഫോമുകൾക്ക് ഒരേസമയം നിരവധി ഡാറ്റാ ദാതാക്കളുമായി ബന്ധപ്പെടേണ്ടി വന്നേക്കാം. എല്ലാ കക്ഷികളുടെയും ഡാറ്റാ അതിരുകൾ വ്യക്തമായി ഉറപ്പാക്കുകയും "ഒരു വലിയ ബക്കറ്റ് എല്ലാവരെയും പിന്നോട്ട് വലിക്കുന്ന" പ്രകടന അപകടസാധ്യത ഒഴിവാക്കുകയും വേണം. Agent Bucket ഉപയോഗിച്ച്, ഓരോ ഡാറ്റാ ദാതാവിനും അവരവരുടെ ObjectSet ഉണ്ടാക്കാം. ഇത് ഉപയോഗിച്ച്, ഒറിജിനൽ ഡാറ്റയും പ്രോസസ് ചെയ്ത ഫലങ്ങളും ഏകീകൃതമായി കൈകാര്യം ചെയ്യാൻ കഴിയും. കൂടാതെ, പ്രത്യേക ഡൊമെയ്‌നുകൾ, ബാൻഡ്‌വിഡ്ത്ത്, QPS ക്വാട്ട എന്നിവ വഴി വ്യത്യസ്ത ദാതാക്കൾക്ക് സേവന ഗ്യാരണ്ടിയും പരിധിയും നൽകാനാകും. ഇത് "ഒരു പ്ലാറ്റ്‌ഫോം, നിരവധി ദാതാക്കൾ, പരസ്പരം വേർതിരിക്കപ്പെട്ടതും നിയന്ത്രിക്കാവുന്നതുമായ സഹകരണം" എന്ന ഡാറ്റാ വിതരണ ഇൻഫ്രാസ്ട്രക്ചർ നടപ്പിലാക്കുന്നു.