الخلاصة

  • تحدد IBM الحد الأدنى للحجم المحتسب في Cold Vault عند 256 كيلوبايت لكل كائن، والحد الأدنى لمدة التخزين عند 90 يوماً. كائن افتراضي حجمه 4 كيلوبايت يولّد أساساً لاحتساب السعة يعادل 64 ضعف حجمه.
  • تحتاج الفاتورة الكاملة إلى السعر والمدة والطلبات وعمليات القراءة أيضاً. جمع الكائنات الصغيرة قد يقلل مرات تطبيق الحد الأدنى، لكنه يغيّر طريقة تعديل السجلات وحذفها واستعادتها منفردة.

الخصم ينتظر عند آخر المعادلة

قد تنجح إدارة المشتريات في خفض سعر الغيغابايت، بينما ينجح فريق التطبيق في تقسيم البيانات إلى سجلات صغيرة مستقلة. لكل فريق إنجازه. ثم تصل الفاتورة لتضرب إنجاز أحدهما في قرار الآخر.

توضح فئة Cold Vault في IBM Cloud Object Storage هذه العلاقة بدقة. تنشر IBM حداً أدنى للحجم المحتسب يبلغ 256 كيلوبايت لكل كائن، مع مدة تخزين دنيا تبلغ 90 يوماً. أما Vault فحدوده 128 كيلوبايت و30 يوماً. ولا تفرض Standard وSmart Tier حداً أدنى للحجم أو المدة، ولا رسوماً لاسترجاع البيانات. تبقى الطلبات والتحويلات إلى الإنترنت العام بنوداً منفصلة.فئات التخزين

لنفترض كائناً حجمه 4 كيلوبايت. بقسمة 256 على 4 نحصل على 64. هذه نسبة أساس احتساب السعة إلى حجم المحتوى في Cold Vault؛ وفي Vault تصبح النسبة 32. كأن قطعة صغيرة تستأجر غرفة كاملة، ثم تترك معظمها فارغاً.

أما إجمالي التكلفة فيحتاج إلى تطبيق التعرفة والوقت والعمليات على هذا الأساس. إذا كانت جميع الكائنات بحجم 4 كيلوبايت واستوفت الحد الأدنى للمدة، فلا يصبح بند السعة وحده أرخص في Cold Vault منه في Standard إلا إذا انخفض سعر سعته إلى أقل من واحد على أربعة وستين من سعر Standard. العرض الفعلي هو الذي يجيب عن ذلك. اسم الفئة لا يجري عملية القسمة نيابة عن المشتري.

الحجم الإجمالي يخفي عدد الوحدات المشتراة

تبدأ ميزانية التخزين عادة بعدّ البيانات: كم لدينا الآن، وكم سيضاف في السنة المقبلة؟ وجود حد أدنى لكل كائن يفرض سؤالاً ثانياً: إلى كم قطعة قُسّم هذا المحتوى؟

يمكن حفظ السجلات نفسها منفردة أو جمعها في كائنات أكبر. في الحالة الأولى يصطدم كل كائن صغير بحده الأدنى. وفي الثانية يصطدم كل ملف مجمّع بحده. تظل المعلومات واحدة، لكن عدد الوحدات المحتسبة يتغير.

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

تقول وثائق IBM إن استخدام الفئة نفسها يُجمع عبر الحاويات داخل المثيل. هذا التجميع المحاسبي لا يحوّل الحدود الفردية إلى مساحة مشتركة تستطيع الكائنات الكبيرة ملأها لصالح الصغيرة. وتفصل الوثائق بين التخزين والطلبات ونقل البيانات إلى الشبكة العامة.طريقة الفوترة

هنا يمكن أن يتحول نجاح الضغط إلى مفاجأة مالية. تصغر بيانات كائن كان أصلاً دون 256 كيلوبايت، ويبقى الحد الأدنى المحتسب في Cold Vault كما هو. يعلن المهندسون تحسناً حقيقياً، ثم يبحث الماليون عن أثره في بند السعة فلا يجدونه. التقرير الفني والتقرير المالي قد يكونان صحيحين معاً؛ كل منهما يتابع كمية مختلفة.

التجميع يحتاج إلى من يفكّه

يبدو الحل سريعاً: نجمع القطع الصغيرة، فنقلل مرات دفع الحد الأدنى. لكن الكائن المستقل كان يحمل أيضاً اسماً وحدوداً واضحة للقراءة والتعديل والحذف. بعد التجميع، يجب بناء تلك القدرة في مكان آخر.

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

تظهر المفاضلة بوضوح عندما يتغير سجل صغير كثيراً. قد يؤدي تعديل محدود إلى إعادة كتابة مجموعة أكبر. ويتطلب الحذف الفردي آلية تجعله نافذاً داخل المحتوى المخزن. أما الاستعادة فتحتاج إلى توافق الفهرس مع البيانات. بذلك قد تنتقل بعض الوفورات من بند السعة إلى طلبات إضافية أو قراءات أو عمل تشغيلي.

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

وتغيير الفئة نفسه يحتاج إلى عمل. توضح IBM أن الفئة تُختار عند إنشاء الحاوية، وأن فئة الحاوية القائمة لا يمكن تغييرها. يجب نقل الكائنات أو نسخها إلى حاوية أخرى بالفئة المطلوبة.إعداد الفئات قواعد الحاويات

لذلك تتضمن عبارة «ننتقل إلى الأرخص لاحقاً» وجهة جديدة ونسخاً وتحديث مراجع التطبيقات والتحقق من النتائج. خيار الانتقال ذو قيمة، وتقديره يصبح أدق عندما تظهر تكلفة استخدامه في الحساب الأول.

الإحصاء يسبق المساومة

ينقص حساب الوفر لعميل بعينه توزيع أحجام كائناته ومدد الاحتفاظ بها ونمط قراءتها والعرض السعري المنطبق عليه.

أما ترتيب الشراء فيمكن تحديده الآن: فهم مجموعة الكائنات أولاً، ثم مقارنة الأسعار. السجلات الصغيرة التي تبقى طويلاً تختلف اقتصادياً عن الصغيرة التي تُحذف سريعاً. والبيانات النادرة القراءة قد تظل بحاجة إلى وصول مستقل لكل سجل عند طلبه. وصف «بيانات باردة» يتسع لسلوكيات كثيرة أكثر مما ينبغي لنموذج مالي واحد.

تنشر IBM الحدود، وللمشتري فرصة احتسابها قبل التوقيع. المشكلة التنظيمية تبدأ حين يحدد فريق التطوير عدد الوحدات التي ستولدها المنظومة، بينما تتفاوض المشتريات على سعر الوحدة وحده. قد يحصل الطرفان على إشادة داخلية، فيما تحصل الفاتورة على حاصل الضرب.

الوثائق الأصلية

تستند قواعد التخزين إلى وثائق IBM الرسمية المرتبطة أعلاه. ويُستخدم سجل عضوية RIPE NCC فقط للتحقق من هوية International Business Machines Corporation في الدليل. حجم 4 كيلوبايت افتراض حسابي معلن.