تخزين الصور المصغّرة المقدّمة من المزوّد


ملاحظة: هذا مقتبس من محادثة جرت على Slack الخاص بـ Make WP (راجع الرابط لمزيد من السياق).

وضعنا الحالي فيما يتعلق بالصور المصغّرة

تم جمع الصور المصغّرة بواسطة المزوّدين ووضعها في عمود thumbnail في الكتالوج. لدينا بيانات هناك الآن، ولم يُحذف العمود. وبما أن هذا العمود موجود أيضًا في واجهة API، تُنسخ البيانات منه (للصوت والصور معًا) إلى عمود thumbnail هناك أيضًا. ومع ذلك، يستخدم نموذج الصوت عمود thumbnail فقط، بينما يتجاهله نموذج الصور ويحاول إنشاء صورة مصغّرة مُصغّرة باستخدام عنوان URL للصورة الأساسية. وقد عُدّلت فئة MediaStore في المزوّد بحيث لا يمكن إضافة عناوين URL جديدة للصور المصغّرة إلى عمود thumbnail، لكن يمكن إضافتها إلى البيانات الوصفية ضمن meta_data["thumbnail_url"].

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

الاقتراح

بالنسبة إلى image: نبدأ بنسخ جميع قيم thumbnail الحالية في الكتالوج إلى meta_data["thumbnail_url"]. ثم ننفذ عملية تبديل جدول بجدول جديد دون العمود ونزيل عمود thumbnail من الجدول. سيساعد ذلك في توفير المساحة وتقليل عرض الجدول. ثم نحدّث العرض المادي image_view لملء عمود thumbnail لواجهة APIAPI واجهة برمجة التطبيقات (API) هي وسيط برمجي يتيح للبرامج التفاعل مع بعضها ومشاركة البيانات بطرق محدودة ومحددة بوضوح. باستخدام قاموس meta_data. يوجد مثال على ذلك في عرض الصوت ضمن audio_set_foreign_identifier. سيسمح لنا ذلك بالإبقاء على عمود thumbnail في واجهة API مع تقليل المساحة في الكتالوج، إذ يُرجح أن تكون هجرةالهجرة نقل الشيفرة وقاعدة البيانات وملفات الوسائط الخاصة بموقع إلكتروني من خادم إلى آخر. ويحدث ذلك غالبًا عند تغيير شركة الاستضافة. بهذا الحجم في واجهة API غير عملية في الوقت الحالي. ثم سنُجري تغييرين على المنطق في كلا الطرفين:

  1. إضافة منطق معالجة thumbnail_url في ImageStore، بحيث يضع هذه القيمة في قاموس meta_data تلقائيًا
  2. تغيير منطق نموذج الصور في واجهة API ليحاول أولًا استخدام image.thumbnail (الذي نُسخ من meta_data["thumbnail_url"] أثناء تحديث البيانات)، ثم يحاول استخدام image.url عند إنشاء الصورة المصغّرة المُصغّرة

يمكننا فعل الأمر نفسه مع الصوت أيضًا؛ إذ يبدو أن نحو نصف السجلات لا يحتوي على صور مصغّرة:

deploy@localhost:openledger> select count(*) from audio where thumbnail is null;
+--------+
| count  |
|--------|
| 427124 |
+--------+
SELECT 1
Time: 4.354s (4 seconds), executed in: 4.328s (4 seconds)
deploy@localhost:openledger> select count(*) from audio;
+--------+
| count  |
|--------|
| 949384 |
+--------+
SELECT 1
Time: 3.899s (3 seconds), executed in: 3.887s (3 seconds)

ما رأيكم في هذا النهج؟ أعتقد أن أي جهد لتقليل عرض جداول قاعدة البيانات لدينا مهم، لأنه سيجعل عمليات الهجرة وإدارة البيانات أسهل لاحقًا.

#تطبيع-البيانات، #postgres، #الصور-المصغّرة