إزالة التكرار

تستخدم المستودعات المدعومة من Xet تقنية التجزئة المعرّفة بالمحتوى (CDC) لإزالة التكرار على مستوى البايتات (حوالي 64 كيلوبايت من البيانات، ويُشار إليها أيضاً باسم «الجزء»). يُعرَّف كل جزء بواسطة تجزئة متدحرجة تحدد حدود الأجزاء بناءً على محتوى الملف الفعلي، مما يجعلها مقاومة للإدراج أو الحذف في أي مكان داخل الملف. عند رفع ملف إلى مستودع مدعوم من Xet باستخدام عميل واعٍ بـ Xet، يتم تقسيم محتواه إلى هذه الأجزاء ذات الأحجام المتغيرة. بعد التجزئة، يُحتفظ فقط بالأجزاء الجديدة غير الموجودة مسبقاً في تخزين Xet، بينما يُتخلص من كل ما عدا ذلك.

إن إزالة التكرار على مستوى المقاطع هي ما يجعل النسخ على جانب الخادم فورية أيضاً: فـ hf buckets cp بين المستودعات والدلاء ينقل تجزئات المحتوى فقط، دون إعادة رفع البيانات. راجع نسخ الملفات بين المستودعات والدلاء.

كيف يعمل التقطيع المعرّف بالمحتوى

لفهم التقطيع المعرّف بالمحتوى، تخيّل ملفًا على أنه نص طويل. يفحص النظام البيانات باستخدام تجزئة متدحرجة — وهي دالة رياضية صغيرة تنزلق فوق البايتات. كلما وصلت التجزئة إلى نمط خاص، يُوضع حدّ للتقطيع عند ذلك الموقع. وبما أن الحدود تُحدَّد بواسطة المحتوى نفسه (وليس بمواقع ثابتة)، فإن المناطق المتطابقة من البيانات تنتج دائمًا نفس المقاطع، حتى لو تغيّر المحتوى المحيط.

لماذا لا نستخدم مقاطع ذات حجم ثابت؟

فكّر فيما يحدث عند إدراج كمية صغيرة من البيانات في منتصف ملف. مع التقطيع بحجم ثابت، تتغير كل حدود القطع بعد نقطة الإدراج، مما يُبطل جميع القطع اللاحقة — على الرغم من أن معظم البيانات لم يتغير:

Original file, fixed 6-byte chunks:

  |The qu|ick br|own fo|x jump|s over| the l|azy do|g     |
  chunk1  chunk2 chunk3 chunk4 chunk5 chunk6 chunk7 chunk8

Insert "very " before "lazy":

  |The qu|ick br|own fo|x jump|s over| the v|ery la|zy dog|
  chunk1  chunk2 chunk3 chunk4 chunk5 chunk6 chunk7 chunk8
                                       ~~~~~~ ~~~~~~ ~~~~~~
                                        3 chunks changed!

على الرغم من أن 5 بايتات فقط أُدرجت، إلا أن 3 من أصل 8 مقاطع تغيّرت لأن جميع الحدود بعد التعديل انزاحت بمقدار 5 مواضع. في الملفات الحقيقية بحجم مقطع 64KB، يمكن لتعديل صغير أن يُبطل مئات الميجابايت من المقاطع.

تُبقي تقسيمات التعريف بالمحتوى الحدود مستقرة

مع CDC، تُوضع الحدود حيث يتطابق المحتوى مع نمط معين — وليس عند فترات ثابتة. وهذا يعني أن الإدراج يؤثر فقط على الجزء الذي يحدث فيه التعديل. تبقى الأجزاء قبله وبعده متطابقة:

Original file, content-defined chunks (boundaries marked by "|"):

  |The quick |brown fox |jumps over |the lazy dog|
    chunk 1     chunk 2    chunk 3     chunk 4

Insert "very " before "lazy":

  |The quick |brown fox |jumps over |the very lazy dog|
    chunk 1     chunk 2    chunk 3     chunk 4'
    (same)      (same)     (same)      (changed)

فقط قطعة واحدة من أصل أربع قطع تغيّرت — وهي القطعة التي تحتوي على التعديل. أما القطع الثلاث الأخرى فهي مطابقة حرفياً على مستوى البايتات، وقد تمّ إزالة تكرارها. ولهذا السبب يكون CDC فعّالاً للغاية مع البيانات المُصنَّفة: فعند تحديث نقطة تفتيش لنموذج أو إضافة صفوف إلى مجموعة بيانات، لا يلزم رفع وتخزين الأجزاء المعدّلة فقط.

من المقاطع إلى التخزين

يعمل خط أنابيب إزالة التكرار الكامل على النحو التالي:

عند تقسيم ملف إلى أجزاء، يتم فحص تجزئة كل جزء مقابل ما هو مخزَّن بالفعل. يحدث ذلك على مستويات متعددة: أولاً مقابل الأجزاء التي شوهدت بالفعل في جلسة الرفع الحالية، ثم مقابل ذاكرة تخزين مؤقت محلية لبيانات الوصف المرفوعة سابقاً، وأخيراً يتم فحص مجموعة فرعية من الأجزاء مقابل جميع تخزين Xet عبر استعلام عالمي لإزالة التكرار. يتم تخطي الأجزاء المكررة بالكامل. تُجمَّع الأجزاء الجديدة في كتل بحجم 64 ميغابايت وتُرفع. تُخزَّن كل كتلة مرة واحدة في مخزن مُعتمد على المحتوى (CAS)، ومفهرسة حسب تجزئتها.

التوفير في التخزين في الممارسة العملية

التوصية الحالية لدى Hub هي تقييد حجم الملفات بـ 200 غيغابايت. عند حجم كتلة يبلغ 64 كيلوبايت، يحتوي ملف بحجم 20 غيغابايت على 312,500 كتلة، كثير منها يبقى دون تغيير من إصدار إلى آخر. صُمم Git LFS ليلاحظ فقط أن الملف قد تغيّر ويخزّن كامل ذلك المراجعة. من خلال إزالة التكرار على مستوى الكتل، يتيح نظام Xet الخلفي تخزين المحتوى المُعدَّل في الملف فقط (والذي قد يكون بضعة كيلوبايت أو ميغابايت فقط) وإزالة التكرار بأمان للكتل المشتركة عبر المستودعات. بالنسبة للملفات الثنائية الكبيرة الموجودة في مستودعات النماذج والبيانات، يوفر هذا تحسينات كبيرة في أوقات نقل الملفات.

For more details, refer to the From Files to Chunks and From Chunks to Blocks blog posts, or the Git is for Data paper by Low et al. that served as the launch point for XetHub prior to being acquired by Hugging Face.