بروتوكول تخزين Walrus في النظام البيئي لـ Sui يبدو رائعاً جداً، لكن عند استخدامه فعلياً، تظهر الكثير من المشاكل. كمتخصص تقني تعاملت لفترة طويلة مع التخزين الموزع، يجب أن أقول الحقيقة — الوثائق الرسمية تتحدث فقط عن الحالات المثالية، لكن في الواقع عند النشر تظهر مشاكل من كل مكان.

لنبدأ بخطة الكود المحذوف ثنائي الأبعاد في RedStuff. هذه الطريقة حقاً مبتكرة في الأوراق البحثية: تتعامل مع البيانات كمصفوفة رموز n×m، أولاً تقوم بترميز RaptorQ على الأعمدة لإنشاء الشرائح الأساسية، ثم تقوم بترميز Reed-Solomon على الصفوف لإنشاء الشرائح الثانوية. كل عقدة تخزن مجموعة شرائح أساسية وثانوية، وثلث العقد فقط كافية لاستعادة البيانات الكاملة. معدل الزيادة الاحتياطية يتحكم فيه من 4 إلى 5 أضعاف، هذا الرقم أفضل بالفعل من النسخ المكررة 3 إلى 5 أضعاف لمنصة تبادل رائدة، وأيضاً يوفر مساحة أكثر من النسخ الاحتياطية الشاملة للشبكة لمنصة شاملة واحدة.

لكن الكفاءة لا تأتي بدون ثمن، التكلفة تتضاعف عدة مرات في سيناريوهات الحمل العالي.

أولاً، هناك التكلفة الحسابية للترميز وفك الترميز. رغم أن RaptorQ هو معيار الكود النافورة المعترف به في الصناعة، إلا أن تعقيد العمليات الحسابية للمصفوفة ليس منخفضاً. خاصة عند التعامل مع الملفات بحجم غيغابايت، في الاختبارات الفعلية، تحميل ملف نموذج ذكاء اصطناعي بحجم GB، ستستهلك عملية الترميز أكثر من 90% من موارد معالج العميل، والوقت المستغرق يتجاوز دقيقتين. إذا كان تطبيقك يتطلب تحميلات متكررة، فستصبح هذه التكلفة عنق الزجاجة واضحاً للأداء. وقت الترميز الطويل ليس المشكلة الوحيدة، استهلاك الموارد أثناء فك الترميز وإعادة البناء مخيف أيضاً.