Agent Bucket: Agent الأصلي للتخزين على نطاق تريليون

في عصرنا الحالي، حيث تظهر وكلاء الذكاء الاصطناعي (AI Agent) كالفطر بعد المطر، يقوم المطورون ببناء تطبيقات ذكية خيالية بوتيرة غير مسبوقة. من مساعدي البرمجة الذين يساعدونك في كتابة التعليمات البرمجية، إلى أدوات الإنشاء التي تنشئ فيلمًا كاملاً بعبارة واحدة، وصولًا إلى المساعدين الشخصيين الأذكياء المتوفرين على مدار الساعة، يعيد الوكلاء تشكيل طريقة تفاعلنا مع العالم الرقمي. وراء هذا المد، يتضح إجماع متزايد: بمساعدة بنية Serverless (مثل Lambda)، ونماذج اللغة الكبيرة (LLM)، والتخزين السحابي (مثل S3 و TOS)، جنبًا إلى جنب مع Vibe Coding، يمكن لأي شخص إنشاء وكيل ذكاء اصطناعي خاص به في غضون 30 دقيقة.

للانتقال من "قابل للاستخدام" إلى "جيد للاستخدام"، لا يزال يتعين على مطوري Agent التغلب على الصعوبات في الانتقال من "لعبة" إلى "تطبيق على مستوى الإنتاج". مع انتقال الأعمال إلى عدد هائل من المستخدمين، يواجه المطورون تحديًا معقدًا للغاية: كيفية بناء حل تخزين كامل للملايين من المستخدمين النهائيين على تخزين الكائنات؟ بالنسبة لمعظم المطورين، هذا ليس مجرد عتبة تقنية، ولكنه أيضًا فجوة تعيق التوزيع واسع النطاق للوكلاء. يهدف Agent Bucket إلى تبسيط عملية بناء أنظمة متعددة المستأجرين تمامًا من خلال تصميم تخزين أصلي للذكاء الاصطناعي، وتوفير قدرات Agent أكثر سهولة.

عندما يتدفق مئات الملايين من المستخدمين، فإن تخزين الكائنات التقليدي "لم يعد كافيًا"

تخيل أنك طورت تطبيق AIGC ناجحًا للغاية. سيقوم كل مستخدم بإنشاء وتخزين عدد كبير من الصور ومقاطع الفيديو والملفات المؤقتة. كمطور، ستختار بشكل طبيعي خدمات تخزين الكائنات الناضجة والقابلة للتطوير مثل S3 و TOS. ولكن هنا يطرح السؤال: كيف تدير البيانات لعدد هائل من المستخدمين؟

في عام 2022، أوضحت مدونة S3 بعنوان "تقسيم وعزل بيانات SaaS متعددة المستأجرين باستخدام Amazon S3" طريقتين، "استخدام كل مستأجر لدلو S3 مستقل" و "دلو S3 مشترك يعتمد على عزل البادئة":

• إنشاء "دلو" (Bucket) مستقل لكل مستخدم: هذا ممكن عندما يكون عدد المستخدمين صغيرًا، ولكن عندما ينمو عدد المستخدمين إلى عشرات الآلاف أو الملايين، سينفجر عدد الدلاء بسرعة، وستصبح تكاليف الإدارة وقيود الموارد لا تطاق. توفر S3 حصة إجمالية قدرها 10000 دلو في المنطقة بأكملها، ولكن بالنسبة لقدرات الذكاء الاصطناعي الساخنة، فإن 10000 ليست كافية.

• استخدام "بادئة" للتمييز بين المستخدمين في نفس الدلو: أصبح هذا هو الحل السائد. على سبيل المثال، تبدأ ملفات المستخدم A بـ user-a/، بينما تبدأ ملفات المستخدم B بـ user-b/، تمامًا مثل إدارة الملفات باستخدام المجلدات على جهاز الكمبيوتر. ومع ذلك، لا توجد مجلدات أصلية في تخزين الكائنات، ويقوم هذا الحل بتمييز المستأجرين المتعددين من خلال "بادئة عامة" (Prefix) في نظام تخزين "K-V".

تم اعتماد هذا الحل القائم على "الدلو" أو "البادئة" على نطاق واسع على مدى السنوات العشر الماضية. ولكن هناك المشاكل التالية:

• عزل متعدد المستأجرين: يتم خلط بيانات جميع المستخدمين في نفس الدلو، وقد يؤثر الوصول عالي التردد غير الطبيعي لمستخدم واحد على جميع المستخدمين الآخرين، مما ينتج عنه "تأثير الجار". لا يمكن الحديث عن عزل الأداء وعزل الأعطال.

• التحكم في الأذونات: من الصعب الحفاظ على سياسات الأذونات المعقدة (IAM Policy)، ومن السهل ارتكاب أخطاء في التكوين، مما يؤدي إلى الوصول غير المقصود إلى بيانات المستخدم، خاصة عند الحاجة إلى التفاعل مع الخدمات السحابية الأخرى، يكون التعرض للمخاطر أكبر.

• وضوح التكلفة: من الصعب عليك أن تعرف بدقة مقدار مساحة التخزين التي يستهلكها كل مستخدم ومقدار رسوم حركة المرور التي يتم إنشاؤها. عندما تريد فرض رسوم على المستخدمين المدفوعين بناءً على الاستخدام، يصبح الفوترة والقياس حسابًا غير واضح.لماذا تبدو هذه الاحتياجات الأساسية ثقيلة بعض الشيء بالنسبة لمطوري Agent عند تنفيذها على تخزين الكائنات؟ يكمن السبب العميق في وجود فجوة كبيرة بين "تخزين الكائنات" (S3/TOS) و "نظام الملفات" التقليدي في بنية الحوسبة السحابية الأصلية الحالية. جوهر تخزين الكائنات (S3/TOS) هو "التسطيح"، وقد تم تصميمه في الأصل لتخزين كميات هائلة من البيانات ببساطة، مثل مستودع ضخم. على الرغم من أن السعة غير محدودة تقريبًا، إلا أن الهيكل المنطقي بسيط للغاية. يفتقر إلى إدارة الدليل المتقدمة الأصلية، والتحكم الدقيق في البيانات الوصفية، والإدراك الحقيقي للمستأجر. عندما يحاول المطورون محاكاة نظام ملفات متعدد المستأجرين "ثلاثي الأبعاد" على S3 "المسطح" عن طريق الترميز الثابت للبادئات، فإننا في الواقع نستخدم "تخزين KV ثابت" لدعم طريقة وصول الملفات لتطبيق Agent "الدلالات الدليلية، والمعزولة بقوة". بمعنى آخر، يحتاج Agent إلى استهلاك رموز إضافية لإدارة الملفات والتحكم في حل أذونات وعزل متعدد المستأجرين. تشير هذه الرموز الإضافية المستهلكة إلى أن خدمة التخزين البسيطة التي حددتها S3 ليست بسيطة بما يكفي لـ Agent.

توضح مدونة S3 لعام 2025 "أنماط التصميم للتحكم في الوصول متعدد المستأجرين على Amazon S3" S3 Access Point بشكل أكبر. هذا يعني أنه يمكن إنشاء نقاط وصول شبكة افتراضية متعددة، ويمكن تكوين سياسة نقطة وصول مخصصة لكل نقطة وصول، وهناك بعض الحلول لسيناريوهات متعددة المستأجرين على مستوى جدولة الشبكة.

Agent Wonderland

يمكن لمطور Agent مثالي، عند تطوير AI Agent، بناء Agent لا يعتمد على الخادم تمامًا استنادًا إلى "Agent SDK + التخزين + خدمة MaaS":

• يمكن تشغيل Agent بدون خادم تمامًا

• يمكن بناء Agent عن طريق الجمع بين قدرات المنتج الحالية من خلال Vibe Coding

• تحتاج فقط إلى صيانة برنامج python النصي "ADK"

• يستخدم التخزين تخزين الكائنات

• تستخدم قدرة الذكاء الاصطناعي Doubao

• من الناحية النظرية، لا يوجد ECS أو منتجات أخرى قائمة على المثيل

في الوقت نفسه، يحتاج التخزين إلى توفير القدرات التالية:

• يمكن أن يكون لدى Agent تخزين دلالي للكائنات (حفظ الملفات)، وتوفير قدرة وصول متعددة المستأجرين، بدءًا من مليون، وقابلة للتطوير إلى مئات الملايين

• يمكن لـ Agent توفير مساحة مستقلة لكل مستخدم (بين خدمات متعددة، قد يكون لخدمة أو uid نفس الاسم)

• يمكن لـ Agent تكوين النطاق الترددي لكل مستخدم مباشرةً، وتكوين الحد الأقصى لحجم كائن المستخدم الإجمالي

• يمكن لـ Agent إصدار الفواتير والمراقبة والمراقبة بناءً على المستخدم

• يمكن لـ Agent تكوين سياسات الوصول لملفات كل مستخدم

Agent Bucket: حقن جينات "أصلية متعددة المستأجرين" في AI Agent

من أجل حل هذه المشكلة بشكل أساسي، اقترحنا نموذجًا جديدًا تمامًا لتخزين الكائنات - Agent Bucket. ابتكاره الأساسي هو إدخال مستوى مورد أصلي جديد بين "الحاوية" و "الكائن" التقليديين: مجموعة الكائنات.

الفكرة الأساسية لهذا التصميم بسيطة للغاية: قم بمطابقة ObjectSet حصري لكل مستخدم نهائي لديك. يمكنك أن تتخيل ObjectSet على أنه "صندوق بيانات آمن" أو "مساحة شخصية سحابية" مصممة خصيصًا لكل مستخدم. من الناحية المنطقية، فإنه ينتمي إلى الحاوية الخاصة بك (المطور)، ولكن من الناحية المادية والإدارية، فإنه يتمتع بـ "شخصيته" و "دورة حياته" المستقلة.Agent Bucket يدعم 100 مليون ObjectSet لكل حاوية، مما يعني أنه يمكنك بسهولة تقديم الخدمات لملايين المستخدمين النهائيين، كما لو كان كل مستخدم نهائي "يعيش" في مساحة تخزين مستقلة خاصة به، دون الحاجة إلى القلق بشأن إدارة التخزين متعدد المستأجرين.

تصميم ObjectSet - قدرات صديقة للـ Agent

في Agent Bucket، ObjectSet ليس مجرد إضافة مستوى، بل يحول الاحتياجات الأكثر تعقيدًا في سيناريوهات متعددة المستأجرين إلى قدرات أصلية جاهزة للاستخدام. عندما يتم تحديد ملكية البيانات بوضوح على مستوى ObjectSet، يصبح من السهل تحقيق سلسلة من القدرات التي كان من الصعب تحقيقها في الماضي.

• عزل أصلي: على مستوى ObjectSet، يمكنك تعيين QPS مستقلة، وحدود النطاق الترددي، وحصص السعة لكل مستخدم. يمكن ضمان تجربة المستخدمين المدفوعين، ولن تؤثر السلوكيات غير الطبيعية للمستخدمين المجانيين على الآخرين. هذا هو عزل مجال الخطأ الحقيقي، مما يمنع "الجيران" من التدخل مع بعضهم البعض.

• أذونات أصلية: يمكن أن يكون لكل ObjectSet اسم نطاق مستقل. هذا يعني أنه يمكنك منح المستخدم A عنوان وصول حصريًا user-a.yourapp.com، بدلاً من الكشف عن اسم نطاق حاوية التخزين بأكملها. والأكثر ذكاءً هو تصميم "قفلين": القفل الأول هو بيانات اعتماد الوصول المؤقتة (STS) الصادرة عن مزود الخدمة السحابية، والتي تتحكم في أذونات الوصول على مستوى التطبيق؛ والقفل الثاني هو اسم النطاق المستقل لـ ObjectSet، والذي يقفل طلبات الوصول في مساحة بيانات المستخدم الخاصة من مستوى الشبكة. هذا يحسن بشكل كبير من أمان البيانات.

• مراقبة أصلية: على لوحة معلومات المراقبة، لم تعد مقيدًا برؤية البيانات الموجزة للحاوية بأكملها. يمكنك تقسيم مخططات المراقبة حسب ObjectSet، والحصول على رؤى واضحة حول المستخدم النهائي الذي يقوم بالكثير من الوصول، وبالتالي اتخاذ قرارات تشغيل وتحسين دقيقة.

• هبوط القدرات الأصلية: يمكن الآن نقل السياسات التي كان من الممكن تعيينها على مستوى الحاوية فقط إلى كل مستخدم. يمكنك تعيين دورات حياة بيانات مختلفة لمستخدمين مختلفين، أو استخدام مفاتيح تشفير مختلفة لكل ObjectSet لتحقيق إدارة بيانات أكثر دقة وأمانًا.

• قياس أصلي: هل تريد معرفة مقدار مساحة التخزين التي يشغلها كل مستخدم؟ هل تريد توزيع تكاليف التخزين بدقة على كل مستخدم؟ أصبح الأمر الآن سهلاً. سيقوم Agent Bucket تلقائيًا بحساب سعة واستخدام كل ObjectSet، مما يجعل الفوترة والمحاسبة الخاصة بك واضحة.

• فوترة أصلية: يمكن للمطورين بسهولة تحقيق توزيع التكاليف، ودفع التكاليف المتولدة عن التخزين بدقة إلى كل مستخدم نهائي. على سبيل المثال، فرض رسوم مختلفة بناءً على النسب الفعلية للتكاليف المتولدة من قبل المستخدمين A و B و C، وتوفير دعم البيانات لتحقيق الدخل من Agent.

• الحد الأقصى للسعة الأصلية: للتحكم في تكاليف تشغيل Agent، يمكنك تعيين حصة (الحد الأقصى للسعة) لكل ObjectSet. بمجرد الوصول إلى القيمة المحددة مسبقًا، سيقوم النظام بتقييد هذا المستخدم من إنشاء ملفات جديدة، وتجنب إساءة استخدام الموارد في سيناريوهات متعددة المستأجرين من المصدر.

• ذكاء أصلي: يتيح Agent Bucket لـ Agent الخروج من القيود التقليدية المتمثلة في "تخزين واسترجاع" الملفات البسيطة، ومنح Object ذكاءً أصليًا، ودعم تطوير Agent الشامل بشكل أكثر كفاءة. يمكن لـ ObjectSet تشغيل الفهرسة الذكية بنقرة واحدة، وتزويد Agent بقدرات أسئلة وأجوبة متعددة الوسائط صديقة للأصل، واستبدال العمليات الميكانيكية التقليدية لـ Object CRUD؛ حتى أنه يدعم تشغيل وضع Agentself بنقرة واحدة، وربط المتجهات والمعرفة والنماذج والمطالبات، والكشف المباشر عن وظائف Agent الفرعية الموجهة نحو السيناريو، مما يسمح لمطوري Agent العلويين بالتركيز على إنشاء سير عمل الأعمال الرئيسية، وإطلاق كفاءة تحقيق الدخل الذكي بالكامل.

التحديات التقنية التي تجلبها الزيادة الهائلة في حجم التطبيقات

من خلال تقديم مفهوم ObjectSet الأصلي، يوفر Agent Bucket للمطورين طريقة أنيقة وفعالة لإدارة بيانات المستخدم النهائي على نطاق واسع. يتم تخزين الأصول الرقمية لكل مستخدم بشكل آمن في ObjectSet المخصص له، مما يحقق بشكل طبيعي العزل والفوترة وإدارة الحصص.

مع التوسع السريع في حجم التطبيقات، تظهر في الوقت نفسه تعقيدات إدارة المجموعات الضخمة، وصعوبات العزل، والاختناقات المادية:

• مشكلة الإدارة الهرمية للمستخدمين بكميات كبيرة: عندما تحتاج التطبيقات إلى إدارة موارد وخصائص المستخدمين المختلفين على نطاق واسع، فإنها تحتاج إلى تصميم وتنفيذ بيانات تعريف هرمية للمستخدمين، وربط مفاتيح ميزات تخزين الكائنات. إن مساعدة المطورين على إدارة تصنيف المستخدمين بأمان على مفهوم Set الأصلي هو أمر مهم لتسريع تنفيذ التطبيقات.- عنق الزجاجة في سعة المجموعة الواحدة: على الرغم من أن Agent Bucket يمكن توسيعه منطقيًا إلى أجل غير مسمى، إلا أن البيانات الوصفية الخاصة به يتم تخزينها افتراضيًا في مجموعة فعلية واحدة. عندما يصل العدد الإجمالي للكائنات داخل الحاوية إلى مئات الملايين أو حتى تريليونات، تصبح السعة الفعلية للمجموعة الواحدة حدًا لا يمكن تجاوزه.

• مشكلة مشاركة نقاط الوصول: إن تنوع أعمال Agent وعدد المستخدمين الهائل يجلب مخاطر أمنية أكبر ونطاق انفجار لنقطة الوصول نفسها. كيف يتم إجراء جدولة ديناميكية وفقًا للاختلافات بين عدد كبير من الأعمال والمستخدمين المختلفين، وتحقيق قدرات أمان وعزل وتسريع متباينة، يصبح تحديًا.

Set Tagging: إدارة المستخدمين المصنفة باستخدام العلامات

يوفر ObjectSet طريقة إدارة أصلية تعتمد على العلامات، مما يسمح لمطوري Agent باستخدام قدرة وضع العلامات ببساطة لإكمال إدارة المستخدمين المصنفة. يمكن للمطورين تعيين علامة لكل مستوى مستخدم محدد، وتمكين حصص وميزات مختلفة لكل علامة. سيتم تطبيق الحصص والميزات المقابلة على جميع ObjectSets التي تم وضع علامة عليها. خذ V1 و V2 و V3 كمثال للتوضيح:

• V1: المستوى الافتراضي، المستخدمون المجانيون، العلامة الافتراضية لجميع ObjectSets، يمكن تهيئتها لتخزين ما يصل إلى 1GiB من البيانات، ولا يمكن أن يتجاوز التوزيع العام 100 ميجابت في الثانية من النطاق الترددي، ويتم التحكم في سرعة التنزيل أحادي التدفق لتكون 1 ميجابت في الثانية؛

• V2: أعضاء مدفوعون للمبتدئين، تم تهيئتهم لتخزين ما يصل إلى 10GiB من البيانات، ولا يمكن أن يتجاوز التوزيع العام 10 جيجابت في الثانية من النطاق الترددي، ويتم التحكم في سرعة التنزيل أحادي التدفق لتكون 10 ميجابت في الثانية؛

• V3: أعضاء مدفوعون متميزون، بالإضافة إلى توفير حصص تخزين وتوزيع عام أكبر، يدعمون أيضًا تهيئة تمكين تسريع الشبكة الضعيفة العامة وقدرات تسريع الوسائط عالية الأداء؛

يمكن لمطوري Agent استخدام علامات V1/V2/V3 بمرونة لإدارة الموارد والميزات ذات القيمة المضافة التي يمكن لهؤلاء المستخدمين استخدامها، وذلك لمواجهة دورات التطوير المختلفة للمستخدمين المختلفين.

Set Slice: عزل أصلي لبيانات المستخدمين الضخمة

عندما يصل عدد Set داخل Agent Bucket إلى مئات الملايين، ويصل عدد الكائنات إلى مئات الملايين أو تريليونات، فإن حقيقة أن "جميع البيانات الوصفية لـ Bucket واحد مركزة في مجموعة KV واحدة" ستجلب مخاطر مزدوجة للسعة والأداء.

يوفر Set Slice فكرة "عدم التقسيم المنطقي، والتقسيم الفعلي":

• من الناحية المنطقية، لا تزال تدير Agent Bucket واحدًا فقط.

• من الناحية المادية، وفقًا لنطاق Set وأسماء الكائنات داخل Set، يتم تقسيم البيانات الوصفية إلى شرائح متعددة (Slices)، ويمكن تخزين كل Slice في مجموعات مختلفة، ويتم عزل Sets المتعددة بشكل طبيعي، ويمكن توسيع Set واحد أفقيًا.

يعد Set Slice امتدادًا إضافيًا وضمانًا لقدرة ObjectSet، فهو يحل مشكلة التوسع اللانهائي للسعة المادية في الطبقة السفلية، مع ضمان استقرار واتساق نموذج إدارة ObjectSet في الطبقة العليا.

• استقرار حدود الإدارة: حتى إذا كانت بيانات Agent Bucket تمتد عبر مجموعات فعلية متعددة، يظل ObjectSet هو الوحدة الأساسية الوحيدة للأذونات والحصص والفوترة والمراقبة. يتم تفعيل السياسات التي تم تهيئتها بواسطة المطورين لـ ObjectSet (مثل التحكم في الوصول والحد الأقصى للسعة) تلقائيًا على جميع Slices ذات الصلة، دون الحاجة إلى القلق بشأن توزيع البيانات الأساسية.

• يمكن توسيع Set واحد خطيًا: عندما ينمو حجم بيانات ObjectSet معين بسرعة، سيتم توزيع بياناته بشكل طبيعي على Slices متعددة. مع توسيع المجموعة الكلية، تنمو سعة ObjectSet بسلاسة وخطية، دون الحاجة إلى إجراء أي عمليات تقسيم أو ترحيل مدمرة على ObjectSet نفسه.

• عزل موارد عبر Sets: من خلال توزيع نطاقات مختلفة من الكائنات على مجموعات فعلية مختلفة، يحقق SetSlice عزلًا للموارد ذات أبعاد أعلى. بالاشتراك مع إدارة حصص ObjectSet، يمكن أن يمنع بشكل فعال نمو بيانات ObjectSet "كبير جدًا" من إزاحة جميع موارد المجموعة الواحدة، وبالتالي التأثير على استقرار ObjectSets الأخرى، مما يجعل مخاطر السعة الإجمالية قابلة للتحكم.- توحيد المنطق والتوافق: بالنسبة للشركات والمطورين، بغض النظر عن عدد الشرائح (Slice) الموجودة في الطبقة الأساسية، فإنهم يتعاملون دائمًا مع Agent Bucket موحد منطقيًا. تظل جميع طرق التشغيل الخاصة بالحاويات و ObjectSet والكائنات كما هي، مما يحقق شفافية كاملة للتوسع المادي للتطبيقات العليا.

Set AccessPoint: عزل نقاط وصول كل مستخدم

يدعم Agent Bucket تمكين نقاط وصول مستقلة (نطاقات مستقلة) لكل ObjectSet، وتوسيع قدرات الأمان والعزل والتسريع المتباينة على نقاط الوصول. يتطلب النظام دعم جدولة نقاط وصول مستقلة على مستوى المليار وقدرات تكوين متباينة.

نطاق وصول مستقل {$apid}.tos-objectset-ap.volces.com: حماية أمانية ذات مستويين

• المستوى الأول Obscurity (الغموض): نطاق فرعي مستقل لكل مستخدم/ObjectSet، تجزئة عالية الإنتروبيا apid، احتمالية تصادم منخفضة للغاية، لا يمكن تخمين أو استنفاد مدخل مستخدم معين من زاوية نطاق الوصول؛

• المستوى الثاني Containment (الاحتواء): يستخدم مطورو Agent sts لتوزيع أذونات الوصول على مستوى ObjectSet، حتى إذا تم تسريب sts، يمكن التحكم في نطاق الوصول الخاص به ليقتصر على فترة صلاحية محدودة لـ ObjectSet معين؛

نظام جدولة استكشافي: حساب استراتيجية جدولة نطاق على مستوى المليار

• استراتيجية وصول متباينة حسب المستخدم/ObjectSet:tag

• يتم تشتيت العديد من المستخدمين/ObjectSet تلقائيًا في مداخل عامة مختلفة، ويتأثر عدد المستخدمين المتأثرين بفشل مدخل واحد

• جدولة مرنة لكامل المنطقة، يتم إكمال نقل حركة المرور تلقائيًا في حالة حدوث أي عطل/تحميل زائد لمدخل واحد

• المستخدمون من فئة توزيع تسريع الشبكة العامة، ضع علامة تسريع نقل الشبكة العامة، وجدولة مدخل التسريع تلقائيًا

• المستخدمون من فئة مخاطر الشبكة العامة، ضع علامة خطر، وجدولة مدخل عزل الشبكة العامة تلقائيًا، وتقليل حصة عرض النطاق الترددي للشبكة العامة

• المستخدمون من فئة الشبكة الداخلية عبر المجالات، ضع علامة عبر المجالات، وجدولة مسار تسريع الخط المخصص للشبكة الداخلية تلقائيًا

• مستخدمو مسرع المنطقة المحلية، ضع علامة مسرع، وقم بتركيب مسرع المنطقة المحلية تلقائيًا

من مساعد البرمجة إلى القرص السحابي AI، الاحتمالات اللانهائية لـ Agent Bucket

يوفر Agent Bucket حلولًا كاملة لـ Agent، وتتجاوز سيناريوهات تطبيق تصميم ObjectSet هذا بكثير، ويمكن توسيعه بسهولة ليشمل جميع التطبيقات التي تحتاج إلى توفير خدمات لعدد كبير من المستخدمين النهائيين:

• مستودع التعليمات البرمجية: في الماضي، عندما كانت الشركات أو الأفراد يستضيفون التعليمات البرمجية في السحابة، غالبًا ما كانوا بحاجة إلى بناء "نظام مستأجر" فوق تخزين الكائنات لتحقيق عزل الحساب والتحكم في الأذونات. الآن، يمكن تخصيص ObjectSet حصري لكل مطور لجمع مستودع التعليمات البرمجية ومخرجات البناء والتبعيات بشكل موحد. تتكيف Agent Skills أيضًا بشكل طبيعي مع ObjectSet، ويوفر ObjectSet عزلًا قويًا لتحميل وتنزيل وتوزيع Skills، وتجنب إزعاج Agent أثناء التشغيل.

• قرص شبكة ألبوم صور المؤسسة: غالبًا ما تخلط خدمات الألبوم أو القرص الشبكي التقليدية صور جميع المستخدمين في نفس الحاوية، وتميز المستخدمين من خلال البادئات، وهو ليس معقدًا في الإدارة فحسب، بل إنه عرضة أيضًا لـ "تأثير الجوار". استنادًا إلى ObjectSet، تقع صور ومقاطع فيديو كل مستخدم في مجموعته الخاصة، ولا تتداخل ذروة الوصول مع بعضها البعض، ويمكنك أيضًا تعيين حدود السعة وسياسات النسخ الاحتياطي وطرق التشفير لكل مستخدم، وتحقيق "لكل شخص ألبوم سحابي آمن وخاضع للرقابة".

• Hadoop مستودع البيانات: في مستودع بيانات المؤسسة، غالبًا ما تشترك خطوط الأعمال المختلفة وقواعد البيانات المختلفة في الموارد على نفس التخزين الأساسي. من خلال تعيين كل قاعدة بيانات كـ ObjectSet، يمكن للمؤسسات تحقيق العزل والتحكم في الحصص لكل قاعدة بيانات فوق تخزين موحد. على وجه الخصوص، يوفر ObjectSet طبقة إضافية من الأذونات على TOS، ويوفر العزل والتحكم في الأذونات لقواعد البيانات والجداول المخزنة على TOS دون تغيير Proton الحالي على TOS. - منصة استضافة النماذج: في سيناريوهات استضافة النماذج الكبيرة، لا يكون حجم كل نموذج كبيرًا فحسب، بل قد يتوافق أيضًا مع إصدارات وأوزان وتكوينات استدلال مختلفة. يمكن أن يؤدي إنشاء ObjectSet لكل نموذج إلى تجميع أوزان النموذج و Tokenizer وملفات التكوين وبيانات التقييم ذات الصلة واستضافتها في نفس المساحة. يمكن لجانب التشغيل تعيين سياسات تشفير مختلفة وسياسات نسخ احتياطي والتحكم في النطاق الترددي لنماذج مختلفة. في الوقت نفسه، من خلال إمكانات القياس الأصلية، يمكن حساب تكلفة الاستخدام الحقيقية لكل نموذج، مما يوفر أساسًا للفواتير على مستوى النموذج وجدولة الموارد.

• خدمة البيانات SaaS: بالنسبة لمنصات توزيع البيانات التي تواجه عددًا كبيرًا من المستخدمين النهائيين، غالبًا ما يكون من الضروري الاتصال بالعديد من مزودي البيانات في نفس الوقت. يجب ضمان حدود بيانات واضحة لكل طرف، وتجنب مخاطر الأداء المتمثلة في "دلو كبير واحد يعيق الجميع". بمساعدة Agent Bucket، يمكن لكل مزود بيانات امتلاك ObjectSet الخاص به، وإدارة البيانات الأصلية ونتائج المعالجة بشكل موحد، ثم من خلال نطاق ترددي ونطاق QPS مستقلين، يمكن توفير ضمانات خدمة مختلفة وتقييد المعدل لمختلف المزودين، وتحقيق "بنية تحتية لتوزيع البيانات عبارة عن منصة واحدة، والعديد من المزودين، معزولة عن بعضها البعض ولكن يمكن التحكم فيها والتعاون فيها".

Reference:

• 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/