Hinweis: Dies ist einer Unterhaltung im Make-WP-Slack entnommen (siehe den Link für weitere Zusammenhänge).
Unsere derzeitige Situation in Bezug auf Vorschaubilder
Vorschaubilder wurden von Anbietern gesammelt und in die thumbnail-Spalte im Katalog eingefügt. Wir haben dort inzwischen Daten, und die Spalte wurde nicht entfernt. Da diese Spalte auch in der API existiert, werden die Daten daraus (sowohl für Audio als auch für Bilder) ebenfalls in die thumbnail-Spalte dort kopiert. Allerdings verwendet nur das Audio-Modell die thumbnail-Spalte; das Bildmodell ignoriert sie und versucht, mithilfe der primären Bild-URL ein verkleinertes Vorschaubild zu erstellen. Die MediaStore-Klasse im Anbieter wurde so geändert, dass keine neuen Vorschaubild-URLs zur thumbnail-Spalte hinzugefügt werden können; sie können jedoch in den Metadaten unter meta_data["thumbnail_url"] hinzugefügt werden.
Wir sind kürzlich auf Situationen gestoßen, in denen unsere eigenen Versuche, aus den URLs der Bilder in voller Größe Vorschaubilder zu erstellen, zu regelmäßigen Zeitüberschreitungen geführt und verhindert haben, dass die Datensätze in den Suchergebnissen angezeigt werden. SMK ist ein aktuelles Beispiel dafür: (1) (2). In diesen Fällen könnte es vorteilhaft sein, die vorab berechneten Vorschaubilder des Anbieters zu verwenden. Entscheidend ist, dass nicht alle Anbieter Vorschaubilder bereitstellen oder voraussichtlich bereitstellen werden. Daher scheint es sinnvoll, die Breite unserer Tabellen zu reduzieren, indem wir diese häufig leere Spalte entfernen.
Vorschlag
Für image: Zunächst gehen wir alle vorhandenen thumbnail-Werte im Katalog durch und kopieren sie nach meta_data["thumbnail_url"]. Anschließend führen wir einen new-table-without-column-swap durch und entfernen die thumbnail-Spalte aus der Tabelle. Dies hilft, Speicherplatz zu sparen und die Breite der Tabelle zu reduzieren. Anschließend aktualisieren wir die materialisierte image_view-Sicht, damit sie mithilfe des meta_data-Wörterbuchs eine thumbnail-Spalte für die APIAPI Eine API (oder Programmierschnittstelle) ist ein Softwarevermittler, der es Programmen ermöglicht, miteinander zu interagieren und Daten auf begrenzte, klar definierte Weise auszutauschen. befüllt. Ein Beispiel dafür findet sich in der Audio-Sicht bei audio_set_foreign_identifier. Dadurch können wir die thumbnail-Spalte in der API beibehalten, aber im Katalog Speicherplatz einsparen, da eine MigrationMigration Das Verschieben des Codes, der Datenbank und der Mediendateien einer Website von einem Server auf einen anderen. Dies wird meist beim Wechsel des Hosting-Unternehmens durchgeführt. dieser Größe in der API derzeit vermutlich nicht praktikabel wäre. Anschließend nehmen wir an beiden Enden zwei Änderungen an der Logik vor:
- Füge in
ImageStoreeine Logik zur Verarbeitung vonthumbnail_urlhinzu, die diesen Wert automatisch immeta_data-Wörterbuch ablegt - Ändere die Logik des Bildmodells in der API so, dass zunächst versucht wird,
image.thumbnailzu verwenden (das während der Datenaktualisierung ausmeta_data["thumbnail_url"]kopiert wurde), und anschließend beim Erstellen des verkleinerten Bildesimage.urlverwendet wird
Wir könnten dasselbe möglicherweise für Audio tun; es sieht so aus, als hätten etwa die Hälfte der Datensätze keine Vorschaubilder:
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)
Was halten die Leute von diesem Ansatz? Ich denke, jeder Aufwand zur Reduzierung der Breite unserer DB-Tabellen ist wichtig, da er Migrationen und die Datenverwaltung auf lange Sicht erleichtern wird.