Menyimpan gambar mini yang disediakan oleh penyedia


Catatan: Ini diadaptasi dari percakapan yang berlangsung di Make WP Slack (lihat tautan tersebut untuk konteks selengkapnya).

Situasi kita saat ini terkait gambar mini

Gambar mini dikumpulkan oleh penyedia dan dimasukkan ke kolom thumbnail dalam katalog. Saat ini kita sudah memiliki data di sana, dan kolom tersebut belum dihapus. Karena kolom ini juga ada di API, data darinya (baik untuk audio maupun gambar) juga disalin ke kolom thumbnail di sana. Namun, hanya model Audio yang menggunakan kolom thumbnail; model Image mengabaikannya dan mencoba membuat gambar mini berskala lebih kecil menggunakan URL gambar utama. Kelas MediaStore di penyedia telah diubah sehingga tidak ada URL gambar mini baru yang dapat ditambahkan ke kolom thumbnail, tetapi URL tersebut dapat ditambahkan dalam metadata di bawah meta_data["thumbnail_url"].

Baru-baru ini kami mengalami beberapa skenario ketika upaya kami sendiri untuk membuat gambar mini dari URL gambar berukuran penuh menyebabkan waktu tunggu habis secara konsisten dan mencegah rekaman ditampilkan dalam hasil pencarian. SMK adalah contoh terbaru dari hal ini: (1) (2). Dalam kasus seperti ini, mungkin akan lebih baik jika kita menggunakan gambar mini yang telah dihitung sebelumnya oleh penyedia. Yang terpenting, tidak semua penyedia menyediakan atau diharapkan menyediakan gambar mini. Oleh karena itu, tampaknya kita mungkin ingin mengurangi lebar tabel dengan menghapus kolom yang sering kosong ini.

Proposal

Untuk image: pertama-tama kita menyalin semua nilai thumbnail yang ada di katalog ke dalam meta_data["thumbnail_url"]. Kemudian kita melakukan pertukaran tabel baru tanpa kolom ini dan menghapus kolom thumbnail dari tabel. Hal ini akan membantu menghemat ruang dan mengurangi lebar tabel. Kemudian kita memperbarui materialized view image_view untuk mengisi kolom thumbnail untuk APIAPI API atau Application Programming Interface adalah perantara perangkat lunak yang memungkinkan program berinteraksi satu sama lain dan berbagi data dengan cara yang terbatas serta didefinisikan secara jelas. menggunakan kamus meta_data. Contohnya terdapat dalam view Audio pada audio_set_foreign_identifier. Hal ini memungkinkan kita mempertahankan kolom thumbnail di API, tetapi mengurangi penggunaan ruang di katalog, karena migrasiMigrasi Memindahkan kode, basis data, dan berkas media sebuah situs web dari satu server ke server lain. Biasanya dilakukan saat berganti perusahaan hosting. sebesar itu di API kemungkinan belum layak dilakukan saat ini. Selanjutnya, kita akan membuat dua perubahan pada logika di kedua sisi:

  1. Tambahkan logika penanganan thumbnail_url di ImageStore yang akan secara otomatis menempatkan nilai tersebut ke dalam kamus meta_data
  2. Ubah logika model Image di API agar terlebih dahulu mencoba menggunakan image.thumbnail (yang telah disalin dari meta_data["thumbnail_url"] selama penyegaran data), kemudian mencoba image.url saat membuat gambar berskala lebih kecil

Kita berpotensi melakukan hal yang sama untuk Audio; tampaknya sekitar setengah rekaman tidak memiliki gambar mini:

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)

Bagaimana pendapat semua orang tentang pendekatan ini? Menurut saya, setiap upaya untuk mengurangi lebar tabel DB kita merupakan hal yang penting, karena hal itu akan mempermudah migrasi dan pengelolaan data di kemudian hari.

#data-normalization, #postgres, #thumbnails