एजंट बकेट: अब्जावधी-स्केल एजंट मूळ स्टोरेज बकेट

# एजंट बकेट: अब्जावधी-स्केल एजंट मूळ स्टोरेज बकेट आज AI एजंट्स वेगाने वाढत आहेत, विकासक पूर्वी कधी नव्हे इतक्या कल्पकतेने स्मार्ट ॲप्लिकेशन्स तयार करत आहेत. कोड लिहिण्यास मदत करणार्‍या प्रोग्रामिंग सहाय्यकापासून, एका वाक्यात चित्रपट तयार करणार्‍या सर्जनशील साधनांपर्यंत, वैयक्तिक स्मार्ट सहाय्यकांपर्यंत, एजंट्स आपल्या डिजिटल जगाशी संवाद साधण्याच्या पद्धतीत बदल घडवत आहेत. या लाटेमागे एक गोष्ट स्पष्ट आहे: सर्व्हरलेस आर्किटेक्चर (जसे की Lambda), मोठे भाषिक मॉडेल (LLM) आणि क्लाउड स्टोरेज (जसे की S3, TOS) यांच्या मदतीने, व्हायब कोडिंग (Vibe Coding) वापरून, कोणीही 30 मिनिटांत स्वतःचा AI एजंट तयार करू शकतो. "उपलब्ध" असण्यापासून "उपयुक्त" बनण्यापर्यंत, एजंट विकासकांना "खेळण्या" पासून "उत्पादन-दर्जाचे ॲप्लिकेशन" बनवण्यासाठी अजूनही अडचणी पार कराव्या लागतात. जेव्हा व्यवसाय मोठ्या प्रमाणात वापरकर्त्यांपर्यंत पोहोचतो, तेव्हा विकासकांना एक अत्यंत गुंतागुंतीच्या आव्हानाचा सामना करावा लागतो: मोठ्या प्रमाणात अंतिम वापरकर्त्यांसाठी ऑब्जेक्ट स्टोरेजवर संपूर्ण स्टोरेज सोल्यूशन कसे तयार करावे? बहुतेक विकासकांसाठी, हे केवळ तांत्रिक आव्हान नाही, तर एजंटच्या मोठ्या प्रमाणावर वितरणातही अडथळा आहे. एजंट बकेट AI- मूळ स्टोरेज डिझाइनद्वारे मल्टी-टेनंट सिस्टम (Multi-tenant system) तयार करण्याची प्रक्रिया सुलभ करणे आणि अधिक सोयीस्कर एजंट क्षमता प्रदान करणे हे आहे. ## जेव्हा कोट्यवधी वापरकर्ते येतात, तेव्हा पारंपरिक ऑब्जेक्ट स्टोरेज "अपुरे" ठरते. कल्पना करा, तुम्ही एक लोकप्रिय AIGC ॲप्लिकेशन विकसित केले आहे. प्रत्येक वापरकर्ता मोठ्या प्रमाणात चित्रे, व्हिडिओ आणि तात्पुरत्या फाइल्स तयार करतो आणि साठवतो. एक विकासक म्हणून, तुम्ही S3 आणि TOS सारख्या परिपक्व आणि स्केलेबल ऑब्जेक्ट स्टोरेज सेवा निवडाल. पण प्रश्न असा आहे: मोठ्या प्रमाणात वापरकर्त्यांसाठी डेटा कसा व्यवस्थापित करायचा? 2022 मध्ये S3 च्या ब्लॉग पोस्टमध्ये "ॲमेझॉन S3 सह मल्टी-टेनंट SaaS डेटाचे विभाजन आणि आयसोलेट करणे" (Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3) मध्ये दोन पद्धती स्पष्ट केल्या आहेत, "प्रत्येक भाडेकरूसाठी स्वतंत्र S3 बकेट" आणि "उपसर्ग (Prefix) आधारित वेगळे केलेल्या सामायिक S3 बकेट": - प्रत्येक वापरकर्त्यासाठी एक स्वतंत्र "बकेट" तयार करा: हे कमी वापरकर्त्यांसाठी ठीक आहे, परंतु जेव्हा वापरकर्त्यांची संख्या हजारो किंवा लाखोंपर्यंत वाढते, तेव्हा बकेटची संख्या झपाट्याने वाढते आणि व्यवस्थापन खर्च आणि संसाधनांवरील मर्यादा असह्य होतात. S3 संपूर्ण प्रदेशात एकूण 10000 बकेट कोटा (Bucket quota) प्रदान करते, परंतु लोकप्रिय AI क्षमतांसाठी, 10,000 पुरेसे नाहीत.  - एकाच बकेटमध्ये "उपसर्ग" वापरून वापरकर्त्यांना वेगळे करा: ही मुख्य योजना बनली आहे. उदाहरणार्थ, वापरकर्ता A च्या फाइल्स user-a/ ने सुरू होतात, तर वापरकर्ता B च्या फाइल्स user-b/ ने सुरू होतात, जसे की कॉम्प्युटरवर फोल्डर वापरून फाइल्स व्यवस्थापित करणे. तथापि, ऑब्जेक्ट स्टोरेजमध्ये मूळ फोल्डर्स (Folders) अस्तित्वात नाहीत, ही योजना "K-V" स्टोरेज सिस्टममध्ये "सार्वजनिक उपसर्ग" (Prefix) वापरून अनेक भाडेकरूंना वेगळे करते.  ही "बकेट" किंवा "उपसर्ग" आधारित योजना गेल्या दशकात मोठ्या प्रमाणावर वापरली गेली आहे. पण यात खालील समस्या आहेत: - मल्टी-टेनंट आयसोलेशन (Multi-tenant isolation): सर्व वापरकर्त्यांचा डेटा एकाच बकेटमध्ये मिसळलेला असतो, त्यामुळे एका वापरकर्त्याच्या असामान्य वारंवारतेच्या ॲक्सेसमुळे इतर सर्व वापरकर्त्यांवर परिणाम होऊ शकतो, ज्यामुळे "शेजारी प्रभाव" (Neighbor effect) निर्माण होतो. कार्यक्षमतेचे आयसोलेशन (Performance isolation) आणि दोष आयसोलेशन (Fault isolation) शक्य नाही. - परवानग्यांचे नियंत्रण (Permissions control): जटिल परवानगी धोरणे (IAM Policy) राखणे कठीण आहे आणि कॉन्फिगरेशनमध्ये त्रुटी होण्याची शक्यता असते, ज्यामुळे वापरकर्त्यांच्या डेटावर अनपेक्षितपणे प्रवेश केला जाऊ शकतो, विशेषत: जेव्हा इतर क्लाउड सेवांशी संवाद साधण्याची आवश्यकता असते, तेव्हा धोका अधिक वाढतो. - खर्चाची स्पष्टता: प्रत्येक वापरकर्त्याने नेमकी किती स्टोरेज स्पेस वापरली आणि किती डेटा खर्च झाला हे तुम्हाला अचूकपणे सांगणे कठीण आहे. जेव्हा तुम्ही वापरावर आधारित सशुल्क वापरकर्त्यांकडून शुल्क आकारू इच्छिता, तेव्हा बिलिंग आणि मोजणी गोंधळात टाकणारी ठरते.यामागचे कारण सखोलपणे पाहिल्यास, सध्याच्या क्लाउड-नेटिव्ह आर्किटेक्चरमध्ये, S3 सारखे 'ऑब्जेक्ट स्टोरेज' आणि पारंपरिक 'फाइल सिस्टम' यांच्यात एक मोठी पोकळी आहे. ऑब्जेक्ट स्टोरेज (S3/TOS) चा मूळ उद्देश 'सपाट' (Flat) आहे, मोठ्या प्रमाणात डेटा साध्या पद्धतीने साठवणे, जसे एक मोठे गोदाम. जरी क्षमता जवळजवळ अमर्याद असली, तरी लॉजिकल स्ट्रक्चर अत्यंत सोपे आहे. यात मूळ उच्च-स्तरीय डिरेक्टरी व्यवस्थापन, बारीक-बारीक मेटाडेटा नियंत्रण आणि खऱ्या अर्थाने भाडेकरूंची जाणीव नसते. जेव्हा डेव्हलपर 'सपाट' S3 वर, हार्ड-कोडेड उपसर्ग वापरून 'त्रिमितीय' मल्टी-टेनंट फाइल सिस्टमचे अनुकरण करण्याचा प्रयत्न करतात, तेव्हा आपण प्रत्यक्षात 'स्टॅटिक KV स्टोरेज' वापरून 'डिरेक्टरी सिमेंटिक्स, मजबूत आयसोलेशन' असलेल्या Agent ऍप्लिकेशनच्या फाइल ऍक्सेस पद्धतीला सामावून घेत आहोत. म्हणजेच, Agent ला फाइल व्यवस्थापित करण्यासाठी अतिरिक्त टोकन वापरण्याची आणि मल्टी-टेनंट परवानग्या आणि आयसोलेशन नियंत्रित करण्याची आवश्यकता आहे. हे अतिरिक्त टोकन दर्शवतात की S3 द्वारे परिभाषित केलेली साधी स्टोरेज सेवा Agent साठी पुरेशी सोपी नाही.  2025 च्या S3 ब्लॉग 'ॲमेझॉन S3 वर मल्टी-टेनंट ऍक्सेस कंट्रोलसाठी डिझाइन पॅटर्न' मध्ये S3 ऍक्सेस पॉइंटचे अधिक स्पष्टीकरण दिले आहे. याचा अर्थ असा आहे की अनेक व्हर्च्युअल नेटवर्क ऍक्सेस पॉइंट तयार केले जाऊ शकतात आणि प्रत्येक ऍक्सेस पॉइंटसाठी सानुकूल ऍक्सेस पॉइंट पॉलिसी कॉन्फिगर केली जाऊ शकते, ज्यामुळे नेटवर्क शेड्युलिंग स्तरावर मल्टी-टेनंट परिस्थितींसाठी काही उपाय आहेत. ## Agent वंडरलँड  एका आदर्श Agent डेव्हलपरला AI Agent विकसित करताना, 'Agent SDK + स्टोरेज + MaaS सेवा' यावर आधारित पूर्णपणे सर्व्हरलेस Agent तयार करता आला पाहिजे: - Agent पूर्णपणे सर्व्हरलेसपणे चालू शकतो. - Vibe Coding च्या माध्यमातून, विद्यमान उत्पादन क्षमता एकत्रित करून Agent तयार करता येतो. - फक्त 'ADK' ची पायथन स्क्रिप्ट मेंटेन करण्याची आवश्यकता आहे. - स्टोरेजसाठी ऑब्जेक्ट स्टोरेजचा वापर. - AI क्षमतेसाठी Doubao चा वापर. - सैद्धांतिकदृष्ट्या ECS किंवा इतर इंस्टन्स-आधारित उत्पादने नसावीत. त्याच वेळी, स्टोरेजने खालील क्षमता प्रदान करणे आवश्यक आहे: - Agent कडे ऑब्जेक्ट सिमेंटिक्स स्टोरेज (फाइल्स सेव्ह करण्यासाठी) असावे, जे मल्टी-टेनंट ऍक्सेस क्षमता प्रदान करते, जे 10 लाखांपासून सुरू होऊन 100 दशलक्षांपर्यंत वाढवता येऊ शकते. - Agent प्रत्येक वापरकर्त्याला स्वतंत्र जागा देऊ शकते (एकाधिक व्यवसायांमध्ये, व्यवसाय किंवा UID चे नाव डुप्लिकेट असू शकते). - Agent प्रत्येक वापरकर्त्यासाठी थेट बँडविड्थ कॉन्फिगर करू शकते, वापरकर्त्याच्या ऑब्जेक्टच्या एकूण आकाराची मर्यादा कॉन्फिगर करू शकते. - Agent वापरकर्त्यानुसार बिलिंग, मॉनिटरिंग आणि निरीक्षण करू शकते. - Agent प्रत्येक वापरकर्त्याच्या फाइलसाठी ऍक्सेस पॉलिसी कॉन्फिगर करू शकते. ## Agent Bucket: AI Agent मध्ये 'मल्टी-टेनंट मूळ' जनुके इंजेक्ट करणे या समस्येचे समूळ निराकरण करण्यासाठी, आम्ही ऑब्जेक्ट स्टोरेजचा एक नवीन दृष्टिकोन प्रस्तावित करतो - Agent Bucket. याचे मुख्य नविन म्हणजे, पारंपरिक 'बकेट' आणि 'ऑब्जेक्ट' यांच्यामध्ये, एक नवीन मूळ संसाधन स्तर सादर करणे: ऑब्जेक्ट संच.  या डिझाइनचा मूळ विचार अत्यंत सोपा आहे: तुमच्या प्रत्येक अंतिम वापरकर्त्यासाठी, एक खास ObjectSet जुळवा. तुम्ही ObjectSet ला प्रत्येक वापरकर्त्यासाठी तयार केलेले 'डेटा सेफ' किंवा 'क्लाउड पर्सनल स्पेस' समजू शकता. हे लॉजिकली तुमच्या (डेव्हलपरच्या) Bucket चे आहे, परंतु भौतिक आणि व्यवस्थापनाच्या दृष्टीने, त्याची स्वतःची स्वतंत्र 'ओळख' आणि 'लाइफसायकल' आहे.एजंट बकेट प्रत्येक बकेटमध्ये 10 कोटी ऑब्जेक्टसेटला सपोर्ट करते, याचा अर्थ असा आहे की तुम्ही करोडो अंतिम वापरकर्त्यांना सहजपणे सेवा देऊ शकता, जणू प्रत्येक अंतिम वापरकर्ता त्यांच्या स्वतंत्र स्टोरेज स्पेसमध्ये 'राहत' आहे आणि तुम्हाला मल्टी-टेनंट स्टोरेज मॅनेजमेंटची काळजी करण्याची गरज नाही. ## ऑब्जेक्टसेट डिझाइन - एजंट-फ्रेंडली क्षमता एजंट बकेटमधील ऑब्जेक्टसेट केवळ एक स्तर वाढवत नाही, तर मल्टी-टेनंट परिस्थितीत सर्वात कठीण गरजांना वापरण्यासाठी तयार असलेल्या मूळ क्षमतांमध्ये रूपांतरित करते. ऑब्जेक्टसेट स्तरावर डेटा मालकी निश्चित झाल्यावर, भूतकाळात अंमलात आणणे कठीण असलेल्या क्षमता नैसर्गिकरित्या उपलब्ध होतात. - मूळ अलगीकरण: ऑब्जेक्टसेट स्तरावर, तुम्ही प्रत्येक वापरकर्त्यासाठी स्वतंत्र QPS, बँडविड्थ मर्यादा आणि क्षमता कोटा सेट करू शकता. पैसे देणाऱ्या वापरकर्त्यांचा अनुभव सुनिश्चित केला जाऊ शकतो आणि विनामूल्य वापरकर्त्यांच्या असामान्य वर्तनाचा इतरांवर परिणाम होणार नाही. हे खरे फॉल्ट डोमेन अलगीकरण आहे, जेणेकरून 'शेजारी' एकमेकांना त्रास देणार नाहीत. - मूळ अधिकार: प्रत्येक ऑब्जेक्टसेटचा स्वतःचा डोमेन असू शकतो. याचा अर्थ असा आहे की तुम्ही वापरकर्ता A ला user-a.yourapp.com चा अनन्य ॲक्सेस ॲड्रेस देऊ शकता आणि संपूर्ण स्टोरेज बकेटचा डोमेन उघड करण्याची गरज नाही. 'दोन लॉक' डिझाइन अधिक चातुर्याचे आहे: पहिले लॉक क्लाउड सर्व्हिस प्रोव्हायडरने जारी केलेले तात्पुरते ॲक्सेस क्रेडेन्शियल (STS) आहे, जे ॲप्लिकेशन स्तरावरील ॲक्सेस अधिकारांना नियंत्रित करते; दुसरे लॉक ऑब्जेक्टसेटचा स्वतंत्र डोमेन आहे, जो नेटवर्क स्तरावरून वापरकर्त्याच्या स्वतःच्या डेटा स्पेसमध्ये ॲक्सेस विनंती लॉक करतो. हे डेटा सुरक्षितता मोठ्या प्रमाणात वाढवते. - मूळ मॉनिटरिंग: मॉनिटरिंग डॅशबोर्डवर, तुम्ही आता फक्त संपूर्ण बकेटचा डेटा पाहू शकत नाही. तुम्ही ऑब्जेक्टसेटने मॉनिटरिंग चार्टचे विश्लेषण करू शकता आणि कोणता अंतिम वापरकर्ता मोठ्या प्रमाणात ॲक्सेस करत आहे हे स्पष्टपणे पाहू शकता, ज्यामुळे अचूक ऑपरेशन आणि ऑप्टिमायझेशन निर्णय घेतले जाऊ शकतात. - मूळ क्षमता कमी करणे: पूर्वी फक्त बकेट स्तरावर सेट करता येणारी धोरणे आता प्रत्येक वापरकर्त्यासाठी कमी केली जाऊ शकतात. तुम्ही वेगवेगळ्या स्तरावरील वापरकर्त्यांसाठी डेटा लाइफसायकल वेगळे सेट करू शकता किंवा प्रत्येक ऑब्जेक्टसेटसाठी वेगळी एन्क्रिप्शन की वापरू शकता, ज्यामुळे अधिक तपशीलवार आणि सुरक्षित डेटा व्यवस्थापन शक्य होते. - मूळ मोजमाप: प्रत्येक वापरकर्त्याने किती स्टोरेज स्पेस वापरली आहे हे जाणून घ्यायचे आहे? प्रत्येक वापरकर्त्यावर स्टोरेज खर्च अचूकपणे वाटून घ्यायचा आहे? आता हे करणे खूप सोपे झाले आहे. एजंट बकेट आपोआप प्रत्येक ऑब्जेक्टसेटची क्षमता आणि वापर आकडेवारी मोजेल, ज्यामुळे तुमचे बिलिंग आणि वाटप स्पष्ट होईल. - मूळ बिलिंग: डेव्हलपर सहजपणे खर्चाचे वाटप करू शकतात आणि स्टोरेजमुळे निर्माण होणारा खर्च अचूकपणे प्रत्येक अंतिम वापरकर्त्याला परत देऊ शकतात. उदाहरणार्थ, A, B आणि C या वेगवेगळ्या वापरकर्त्यांनी केलेल्या वास्तविक खर्चाच्या प्रमाणात आधारित शुल्क आकारले जाऊ शकते, जे एजंटच्या व्यापारीकरणासाठी डेटा सपोर्ट प्रदान करते. - मूळ क्षमता मर्यादा: एजंटच्या ऑपरेशनल खर्चावर नियंत्रण ठेवण्यासाठी, तुम्ही प्रत्येक ऑब्जेक्टसेटसाठी कोटा (कमाल क्षमता) सेट करू शकता. एकदा पूर्वनिर्धारित मूल्यावर पोहोचल्यानंतर, सिस्टम त्या वापरकर्त्याला नवीन फाइल्स तयार करण्यापासून प्रतिबंधित करेल, ज्यामुळे मल्टी-टेनंट परिस्थितीत संसाधनांचा गैरवापर टाळता येईल. - मूळ बुद्धिमत्ता: एजंट बकेट एजंटला पारंपारिक फाइल 'स्टोरेज आणि ॲक्सेस'च्या मर्यादेतून बाहेर काढते आणि ऑब्जेक्टला मूळ बुद्धिमत्ता देते, ज्यामुळे एजंटच्या वन-स्टॉप डेव्हलपमेंटला अधिक प्रभावीपणे सपोर्ट मिळतो. ऑब्जेक्टसेट एका क्लिकवर इंटेलिजेंट इंडेक्सिंग सुरू करू शकते, एजंटला मूळ फ्रेंडली मल्टीमॉडल प्रश्न-उत्तर क्षमता प्रदान करते, पारंपारिक ऑब्जेक्ट CRUD च्या यांत्रिक ऑपरेशनला बदलते; एजंटसेल्फ मोड एका क्लिकवर सुरू करण्यास देखील सपोर्ट करते, वेक्टर, ज्ञान, मॉडेल आणि प्रॉम्प्ट एकत्र करते आणि थेट दृश्यावर आधारित सब-एजंट फंक्शन्स दर्शवते, ज्यामुळे उच्च-स्तरीय एजंट डेव्हलपर मुख्य व्यवसाय वर्कफ्लो निर्मितीवर लक्ष केंद्रित करू शकतात आणि बुद्धिमत्तेच्या कमाईची कार्यक्षमता पूर्णपणे वाढवू शकतात. ## ॲप्लिकेशन स्केलच्या वाढीमुळे निर्माण होणारी तांत्रिक आव्हाने एजंट बकेट ऑब्जेक्टसेट ही मूळ संकल्पना सादर करून, ॲप्लिकेशन डेव्हलपरला करोडो अंतिम वापरकर्त्यांच्या डेटाचे व्यवस्थापन करण्याचा एक सुंदर आणि कार्यक्षम मार्ग प्रदान करते. प्रत्येक वापरकर्त्याची डिजिटल मालमत्ता त्यांच्या अनन्य ऑब्जेक्टसेटमध्ये सुरक्षितपणे साठवली जाते, जी नैसर्गिकरित्या अलगीकरण, बिलिंग आणि कोटा व्यवस्थापन सक्षम करते. ॲप्लिकेशन स्केलच्या झपाट्याने होणाऱ्या विस्तारामुळे, मोठ्या प्रमाणात सेटचे व्यवस्थापन, अलगीकरणाची अडचण आणि भौतिक मर्यादा एकाच वेळी दिसून येतात: - मोठ्या प्रमाणात वापरकर्त्यांचे श्रेणीनुसार व्यवस्थापन: मोठ्या प्रमाणात वेगवेगळ्या स्तरावरील वापरकर्त्यांचे संसाधने आणि वैशिष्ट्ये वेगळे व्यवस्थापित करताना, ॲप्लिकेशनला वापरकर्त्यांचे श्रेणीनुसार मेटाडेटा स्वतः डिझाइन आणि अंमलात आणावे लागतात आणि ऑब्जेक्ट स्टोरेज वैशिष्ट्ये स्विच करावी लागतात. सेटच्या मूळ संकल्पनेवर आधारित डेव्हलपरला वापरकर्त्यांचे श्रेणीनुसार व्यवस्थापन करण्यास मदत करणे हे ॲप्लिकेशनच्या अंमलबजावणीला गती देण्यासाठी महत्त्वाचे आहे.- सिंगल क्लस्टर क्षमता मर्यादा: जरी Agent Bucket तार्किकदृष्ट्या अमर्यादितपणे वाढवता येत असले, तरी त्याचे मेटाडेटा डीफॉल्टनुसार एकाच भौतिक क्लस्टरमध्ये साठवले जातात. जेव्हा bucket मधील ऑब्जेक्टची एकूण संख्या अब्जावधी किंवा अगदी खरबोपर्यंत पोहोचते, तेव्हा एका क्लस्टरची भौतिक क्षमता ओलांडता न येणारी मर्यादा बनते. - ऍक्सेस पॉईंट शेअरिंग समस्या: Agent च्या व्यवसायातील विविधता आणि मोठ्या संख्येने वापरकर्ते ऍक्सेस पॉईंटसाठी मोठे सुरक्षा धोके आणि स्फोट त्रिज्या (blast radius) निर्माण करतात. मोठ्या प्रमाणात विविध व्यवसाय आणि वापरकर्त्यांच्या आधारावर डायनॅमिक शेड्युलिंग कसे करावे, तसेच सुरक्षा, आयसोलेशन (विलगता) आणि वेग वाढवण्याची क्षमता कशा प्रकारे मिळवावी, हे एक आव्हान आहे. ## सेट टॅगिंग: वापरकर्ता वर्गीकरणासाठी टॅग-आधारित व्यवस्थापन ObjectSet मूळ टॅग-आधारित व्यवस्थापन प्रदान करते, ज्यामुळे Agent डेव्हलपरला सेट टॅगिंग क्षमतेचा वापर करून वापरकर्त्यांचे वर्गीकरण करणे सोपे होते. डेव्हलपर प्रत्येक परिभाषित केलेल्या वापरकर्ता स्तरासाठी एक टॅग तयार करू शकतात आणि प्रत्येक टॅगसाठी वेगवेगळे कोटा आणि वैशिष्ट्ये सुरू करू शकतात. या टॅग लावलेल्या सर्व ObjectSet वर संबंधित कोटा आणि वैशिष्ट्ये लागू होतील. V1, V2 आणि V3 या तीन स्तरांची उदाहरणे खालीलप्रमाणे आहेत: - V1: डीफॉल्ट स्तर, विनामूल्य वापरकर्ते. सर्व ObjectSet साठी डीफॉल्ट टॅग. जास्तीत जास्त 1GiB डेटा साठवण्यासाठी कॉन्फिगर केले जाऊ शकते. सार्वजनिक नेटवर्क वितरण 100mbps पेक्षा जास्त नसावे आणि सिंगल-स्ट्रीम डाउनलोड गती 1mbps पर्यंत नियंत्रित केली जाते. - V2: एंट्री-लेव्हल सशुल्क सदस्य. जास्तीत जास्त 10GiB डेटा साठवण्यासाठी कॉन्फिगर केले जाऊ शकते. सार्वजनिक नेटवर्क वितरण 10gbps पेक्षा जास्त नसावे आणि सिंगल-स्ट्रीम डाउनलोड गती 10mbps पर्यंत नियंत्रित केली जाते. - V3: प्रीमियम सशुल्क सदस्य. जास्त स्टोरेज आणि सार्वजनिक नेटवर्क वितरणाव्यतिरिक्त, अतिरिक्त सार्वजनिक नेटवर्क (कमकुवत नेटवर्क) प्रवेग आणि उच्च-कार्यक्षमता माध्यम प्रवेग क्षमता देखील कॉन्फिगर करण्यास समर्थन देते. Agent डेव्हलपर वेगवेगळ्या वापरकर्त्यांच्या विकासानुसार V1/V2/V3 टॅगिंगचा वापर करून वापरकर्त्यांसाठी संसाधने आणि अतिरिक्त वैशिष्ट्ये व्यवस्थापित करू शकतात.  ## सेट स्लाइस: मोठ्या प्रमाणात वापरकर्ता डेटाचे मूळ विलगीकरण जेव्हा Agent Bucket मधील Set ची संख्या अब्जावधींपर्यंत पोहोचते आणि ऑब्जेक्टची संख्या अब्जावधी किंवा खरबोपर्यंत पोहोचते, तेव्हा "सिंगल Bucket मधील सर्व मेटाडेटा एका KV क्लस्टरमध्ये केंद्रित असतो" ही वस्तुस्थिती क्षमता आणि कार्यक्षमतेच्या दृष्टीने धोके निर्माण करते. सेट स्लाइस "तार्किकदृष्ट्या विभाजन न करता, भौतिक विभाजन" करण्याचा दृष्टीकोन प्रदान करते: - तार्किकदृष्ट्या, तुम्ही अजूनही फक्त एक Agent Bucket व्यवस्थापित करता. - भौतिकदृष्ट्या, Set आणि Set मधील ऑब्जेक्ट नावांच्या श्रेणीनुसार, मेटाडेटा अनेक स्लाइसमध्ये विभागलेला आहे. प्रत्येक स्लाइस वेगवेगळ्या क्लस्टरमध्ये साठवला जाऊ शकतो. अनेक Set नैसर्गिकरित्या वेगळे केले जातात आणि सिंगल Set क्षैतिजरित्या वाढवता येतात.  सेट स्लाइस हे ObjectSet क्षमतेचे पुढील विस्तार आणि संरक्षण आहे. हे मूलभूत स्तरावर भौतिक क्षमतेच्या अमर्याद विस्ताराची समस्या सोडवते, तसेच ObjectSet व्यवस्थापन मॉडेलची स्थिरता आणि सातत्य सुनिश्चित करते. - व्यवस्थापन सीमा स्थिर: जरी Agent Bucket चा डेटा अनेक भौतिक क्लस्टर्समध्ये पसरलेला असला तरी, ObjectSet हे परवानग्या, कोटा, बिलिंग आणि मॉनिटरिंगसाठी एकमेव मूलभूत एकक आहे. डेव्हलपरने ObjectSet साठी कॉन्फिगर केलेली धोरणे (जसे की ऍक्सेस कंट्रोल, क्षमता मर्यादा) आपोआप सर्व संबंधित स्लाइसवर लागू होतात आणि डेटा वितरणाची काळजी घेण्याची आवश्यकता नाही. - सिंगल Set लीनियर पद्धतीने वाढवता येते: जेव्हा एखाद्या ObjectSet च्या डेटाचे प्रमाण वेगाने वाढते, तेव्हा त्याचा डेटा अनेक स्लाइसमध्ये नैसर्गिकरित्या वितरीत होतो. संपूर्ण क्लस्टरच्या विस्तारासह, ObjectSet ची क्षमता अखंडपणे आणि लीनियर पद्धतीने वाढते. डेव्हलपरला ObjectSet मध्ये कोणतेही विभाजन किंवा स्थलांतर करण्याची आवश्यकता नाही. - क्रॉस Set संसाधन विलगीकरण: वेगवेगळ्या श्रेणीतील ऑब्जेक्ट्स वेगवेगळ्या भौतिक क्लस्टरमध्ये वितरीत करून, SetSlice उच्च-स्तरीय संसाधन विलगीकरण सक्षम करते. ObjectSet च्या कोटा व्यवस्थापनाच्या संयोगाने, हे एखाद्या "सुपर-लार्ज" ObjectSet च्या डेटा वाढीमुळे एकाच क्लस्टरमधील सर्व संसाधने व्यापण्यापासून प्रभावीपणे प्रतिबंधित करते, ज्यामुळे इतर ObjectSet च्या स्थिरतेवर परिणाम होतो आणि एकूण क्षमतेचा धोका नियंत्रणात राहतो.- तार्किक सुसंगतता आणि सुसंगतता: व्यवसाय आणि विकासकांसाठी, अंतर्निहित स्लाइस कितीही असले तरी, ते नेहमी एका तार्किकदृष्ट्या एकत्रित असलेल्या Agent Bucket चा सामना करतात. बकेट, ऑब्जेक्टसेट आणि ऑब्जेक्ट्ससाठीच्या सर्व ऑपरेशन पद्धती अपरिवर्तित राहतात, ज्यामुळे भौतिक विस्ताराचे उच्च-स्तरीय ऍप्लिकेशन्ससाठी पूर्णपणे पारदर्शक होते. ## सेट ऍक्सेस पॉइंट: प्रत्येक वापरकर्त्याच्या ऍक्सेस एंट्री पॉइंटला अलग ठेवणे एजेंट बकेट प्रत्येक ऑब्जेक्टसेटसाठी स्वतंत्र ऍक्सेस पॉइंट (स्वतंत्र डोमेन नेम) सुरू करण्यास समर्थन देते आणि ऍक्सेस पॉइंटवर, ते भिन्न सुरक्षा, अलगीकरण आणि प्रवेग क्षमता वाढवते. यासाठी सिस्टमला अब्जावधी स्वतंत्र ऍक्सेस पॉइंट शेड्युलिंग आणि भिन्न कॉन्फिगरेशन क्षमतांना समर्थन देणे आवश्यक आहे. स्वतंत्र ऍक्सेस डोमेन नेम {$apid}.tos-objectset-ap.volces.com: दुहेरी सुरक्षा - पहिला स्तर अस्पष्टता (Obscurity): वापरकर्ता/ऑब्जेक्टसेटनुसार स्वतंत्र सबडोमेन, apid उच्च एंट्रॉपी हॅशिंग, अत्यंत कमी टक्कर संभाव्यता, ऍक्सेस डोमेन नेमच्या दृष्टिकोनातून विशिष्ट वापरकर्ता एंट्री पॉइंटचा अंदाज लावणे आणि त्यांची गणना करणे शक्य नाही; - दुसरा स्तर प्रतिबंध (Containment): एजेंट डेव्हलपर sts वापरून ऑब्जेक्टसेट स्तरावरील ऍक्सेस परवानग्या वितरीत करतात, जरी sts चा गैरवापर झाला तरी, ते विशिष्ट ऑब्जेक्टसेटच्या मर्यादित वैधतेमध्ये ऍक्सेसची व्याप्ती नियंत्रित करू शकतात; अनुमानित शेड्युलिंग सिस्टम: अब्जावधी डोमेन नेम शेड्युलिंग धोरण गणना - वापरकर्ता/ऑब्जेक्टसेट: टॅगनुसार भिन्न ऍक्सेस धोरण - अनेक वापरकर्ते/ऑब्जेक्टसेट आपोआप वेगवेगळ्या सार्वजनिक नेटवर्क एंट्री पॉइंटवर विखुरलेले आहेत, सिंगल एंट्री पॉइंटच्या बिघाडामुळे प्रभावित वापरकर्त्यांची संख्या नियंत्रणात आहे - संपूर्ण प्रदेशात लवचिक शेड्युलिंग, कोणताही सिंगल एंट्री पॉइंट बिघाड/ओव्हरलोड झाल्यास आपोआप रहदारीची व्यवस्था पूर्ण होते - सार्वजनिक नेटवर्क प्रवेग वितरण प्रकारातील वापरकर्ते, सार्वजनिक नेटवर्क ट्रांसमिशन प्रवेग टॅग लावा, आपोआप प्रवेग एंट्री पॉइंट शेड्युल करा - सार्वजनिक नेटवर्क धोकादायक वापरकर्ते, धोकादायक टॅग लावा, आपोआप सार्वजनिक नेटवर्क अलगीकरण एंट्री पॉइंट शेड्युल करा आणि सार्वजनिक नेटवर्क बँडविड्थ कोटा कमी करा - अंतर्गत नेटवर्क क्रॉस-डोमेन वापरकर्ते, क्रॉस-डोमेन टॅग लावा, आपोआप अंतर्गत नेटवर्क समर्पित लाइन प्रवेग मार्ग शेड्युल करा - स्थानिक प्रवेगक वापरकर्ते, प्रवेगक टॅग लावा, आपोआप स्थानिक प्रवेगक माउंट करा  ## प्रोग्रामिंग सहाय्यकापासून AI क्लाउड ड्राइव्हपर्यंत, एजेंट बकेटची अमर्याद शक्यता एजेंट बकेट एजंटसाठी एक परिपूर्ण समाधान प्रदान करते आणि ऑब्जेक्टसेटची डिझाइन ऍप्लिकेशनची दृश्ये याहूनही अधिक आहेत, हे मोठ्या संख्येने अंतिम वापरकर्त्यांना सेवा प्रदान करण्याची आवश्यकता असलेल्या सर्व ऍप्लिकेशन्समध्ये सहजपणे विस्तारित केले जाऊ शकते: - कोड रिपॉझिटरी: पूर्वी, जेव्हा एखादी कंपनी किंवा व्यक्ती क्लाउडमध्ये कोड होस्ट करते, तेव्हा खाते अलगीकरण आणि परवानग्या नियंत्रणासाठी ऑब्जेक्ट स्टोरेजच्या वर 'भाडेकरू प्रणाली' तयार करणे आवश्यक होते. आता, प्रत्येक विकासकाला एक खास ऑब्जेक्टसेट दिला जाऊ शकतो, ज्यामध्ये कोड रिपॉझिटरी, बिल्ड आर्टिफॅक्ट्स आणि अवलंबित्व एकत्रितपणे साठवले जाऊ शकतात. एजेंट स्किल्स देखील नैसर्गिकरित्या ऑब्जेक्टसेटशी जुळवून घेतात. स्किल्सचे अपलोड आणि डाउनलोड वितरण ऑब्जेक्टसेटद्वारे मजबूत अलगीकरण प्रदान करते, ज्यामुळे एजेंट रनटाइममध्ये शेजारच्या समस्या टाळता येतात. - एंटरप्राइज फोटो अल्बम नेटवर्क ड्राइव्ह: पारंपारिक फोटो अल्बम किंवा नेटवर्क ड्राइव्ह सेवा सहसा सर्व वापरकर्त्यांचे फोटो एकाच बकेटमध्ये मिसळतात आणि वापरकर्त्यांना वेगळे करण्यासाठी उपसर्ग वापरतात, ज्यामुळे केवळ व्यवस्थापनच गुंतागुंतीचे होत नाही, तर 'शेजारचा प्रभाव' देखील दिसू शकतो. ऑब्जेक्टसेटवर आधारित प्रत्येक वापरकर्त्याचे फोटो आणि व्हिडिओ त्यांच्या स्वतःच्या सेटमध्ये येतात, ऍक्सेस पीक एकमेकांना हस्तक्षेप करत नाहीत आणि वापरकर्त्यानुसार क्षमता मर्यादा, बॅकअप धोरण आणि एन्क्रिप्शन पद्धती सेट केल्या जाऊ शकतात, जेणेकरून 'प्रत्येकाला एक सुरक्षित आणि नियंत्रित क्लाउड फोटो अल्बम' मिळेल. - Hadoop डेटा वेअरहाउस: एंटरप्राइज डेटा वेअरहाउसमध्ये, विविध व्यवसाय लाइन आणि डेटाबेस अनेकदा समान अंतर्निहित स्टोरेजवर संसाधने सामायिक करतात. प्रत्येक डेटाबेसला ऑब्जेक्टसेटमध्ये मॅप करून, कंपन्या युनिफाइड स्टोरेजवर डेटाबेसनुसार अलगीकरण आणि कोटा नियंत्रण मिळवू शकतात. विशेषतः ऑब्जेक्टसेट TOS वर अतिरिक्त स्तरावरील परवानग्या प्रदान करते, विद्यमान प्रोटॉन TOS वर बदल न करता, TOS वर साठवलेल्या डेटाबेस आणि टेबल्ससाठी अलगीकरण आणि परवानग्या नियंत्रण प्रदान करते.- मॉडेल होस्टिंग प्लॅटफॉर्म: मोठ्या मॉडेल होस्टिंगच्या परिस्थितीत, प्रत्येक मॉडेल केवळ आकारानेच मोठा नसतो, तर त्याचे विविध व्हर्जन, वेट आणि अनुमान कॉन्फिगरेशन देखील असू शकतात. प्रत्येक मॉडेलसाठी ObjectSet तयार केल्याने, मॉडेल वेट, Tokenizer, कॉन्फिगरेशन फाइल्स आणि संबंधित मूल्यांकन डेटा एकाच ठिकाणी पॅक करून होस्ट करता येतो. ऑपरेशन आणि मेंटेनन्स टीम प्रत्येक मॉडेलसाठी वेगवेगळे एन्क्रिप्शन धोरण, बॅकअप धोरण आणि बँडविड्थ नियंत्रण सेट करू शकते. त्याच वेळी, मूळ मीटरिंग क्षमतेद्वारे प्रत्येक मॉडेलच्या वास्तविक वापराच्या खर्चाची आकडेवारी ठेवली जाऊ शकते, ज्यामुळे मॉडेलनुसार बिलिंग आणि संसाधन शेड्युलिंगसाठी आधार मिळतो. - डेटा SaaS सेवा: मोठ्या प्रमाणात अंतिम वापरकर्त्यांसाठी डेटा वितरण प्लॅटफॉर्मला अनेक डेटा प्रदात्यांशी एकाच वेळी कनेक्ट करणे आवश्यक असते. डेटा प्रदात्यांच्या सीमा स्पष्ट ठेवणे आणि "एका मोठ्या बादलीमुळे सर्वांना त्रास होऊ नये" असा परफॉरमन्सचा धोका टाळणे आवश्यक आहे. Agent Bucket च्या मदतीने, प्रत्येक डेटा प्रदात्याला स्वतःचा ObjectSet ठेवता येतो, ज्यामुळे कच्चा डेटा आणि प्रक्रिया केलेले निकाल एकत्रितपणे व्यवस्थापित केले जाऊ शकतात. स्वतंत्र डोमेन आणि बँडविड्थ, QPS कोट्याद्वारे, विविध प्रदात्यांसाठी वेगवेगळ्या सेवांची हमी आणि दर मर्यादा (rate limiting) दिली जाऊ शकते, ज्यामुळे "एक प्लॅटफॉर्म, अनेक प्रदाते, एकमेकांपासून वेगळे आणि नियंत्रित सहकार्य" अशा डेटा वितरणाच्या पायाभूत सुविधा तयार होतात. संदर्भ: - https://aws.amazon.com/cn/blogs/apn/partitioning-and-isolating-multi-tenant-saas-data-with-amazon-s3/ - https://aws.amazon.com/cn/blogs/storage/design-patterns-for-multi-tenant-access-control-on-amazon-s3/