هل ينبغي وضع بيانات Immich الوصفية على SSD والبيانات الضخمة على HDD؟

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

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

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

افصل حالة الإدخال والإخراج الصغيرة النشطة عن الوسائط الموجهة للسعة

احصر بيانات PostgreSQL، والصور المصغرة، والمعاينات، والفيديوهات المُرمّزة، وذاكرة التخزين المؤقت للنماذج، والملفات الأصلية المرفوعة، والمكتبات الخارجية، ونسخ النسخ الاحتياطي. سجّل الحجم الحالي، ومعدل النمو، وتكرار القراءة والكتابة، وتكلفة إعادة البناء، وما إذا كان يجب أن يظل كل دور محفوظًا بعد الاستعادة. يمنع ذلك تسمية مجلد عامة مثل «البيانات الوصفية» من إخفاء عدة أعباء عمل مختلفة جدًا.

يوضح إطار التخزين ZimaSpace الخاص بـ وضع البيانات الوصفية للوسائط وذاكرة التخزين المؤقت النشطة التمييز المفيد: تستفيد قواعد البيانات والفهارس من التخزين منخفض زمن الاستجابة، بينما يمكن أن تبقى الوسائط المصدرية المجمعة على تخزين السعة عندما لا يتطلب نمط الوصول إليها معدل عمليات الإدخال والإخراج نفسه. إذا أظهر HDD الحالي زمن استجابة منخفضًا أثناء عمليات البحث وتصفح المخطط الزمني والمهام في الخلفية، فقد لا يوفر نقل كل ملف مشتق إلى SSD مكسبًا ملحوظًا للمستخدم. أبقِ التخطيط الحالي إلى أن تُظهر مقارنة مضبوطة أن مسار التخزين النشط ينتظر فعلًا.

ضع PostgreSQL والملفات المشتقة التي تُقرأ كثيرًا على SSD عندما تكون هي عنق الزجاجة

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

في تخطيطات Immich الحالية، أبقِ قاعدة البيانات على تخزين محلي منخفض زمن الاستجابة، وانقل مسارات البيانات المُنشأة المدعومة بعناية بدلًا من ابتكار نقاط تركيب متداخلة عشوائية.

آلية التخزين مفهومة جيدًا خارج Immich: تستفيد تهيئة تخزين PostgreSQL من وصول عشوائي أقل تكلفة بكثير مقارنة بالأقراص الدوارة. وهذا لا يضمن تحقيق تحسن ملحوظ في Immich، لكنه يوضح سبب كون عمليات قاعدة البيانات والفهارس مرشحين قويين لـ SSD عندما يكون زمن استجابة الجهاز هو موضع الانتظار المقاس.

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

أبقِ الملفات الأصلية على HDD عندما تكون السعة والحماية أهم من الإدخال والإخراج العشوائي

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

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

لا تضع الملفات الأصلية التي لا يمكن تعويضها على HDD لمجرد أنه أرخص، ثم تتعامل مع RAID على أنه نسخة احتياطية. احتفظ بنسخة ثانية ونسخة خارج المضيف أو غير متصلة بالإنترنت وفق هدف الحماية المنزلي. يغير تقسيم مستويات التخزين الأداء والتكلفة؛ لكنه لا يقلل عاقبة فقدان النسخة الوحيدة من مكتبة العائلة.

-15% OFF

انقل دورًا تخزينيًا واحدًا في كل مرة، واختبر نقاط التركيب بعد إعادة التشغيل

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

أعد تشغيل المضيف بدلًا من إعادة إنشاء الحاويات فقط. يوفّر التخطيط المقسّم الناجح نقطتي تركيب SSD وHDD عند بدء تشغيل Immich وقبل أن يكتب إليها، ويحافظ على المستخدمين والعلاقات، ويقرأ عينات من الملفات الأصلية، ويُبقي مراقبة المساحة الحرة مفعّلة على كلا المستويين. يُعد وجود مجلد بديل فارغ عند نقطة تركيب متوقعة سببًا لإيقاف العملية. أبقِ التقسيم عندما يتحسن عنق الزجاجة المقاس وتظل خريطة الاسترداد مفهومة. تراجع إذا تسبب التخطيط في مسارات قديمة أو أصول مفقودة أو انحراف في الأذونات أو عملية نسخ احتياطي تحمي مستوى واحدًا فقط. أفضل تصميم للتخزين هو الأسرع الذي لا يزال بإمكانك استعادته بشكل صحيح.

الدعم والنصائح

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.