Примечание: Это адаптировано из обсуждения, состоявшегося в Make WP Slack (см. ссылку для дополнительного контекста).
Текущая ситуация с миниатюрами
Миниатюры собирались поставщиками и помещались в столбец thumbnail каталога. Сейчас там уже есть данные, и столбец не был удалён. Поскольку этот столбец также существует в API, данные из него (как для аудио, так и для изображений) также копируются в находящийся там столбец thumbnail. Однако только модель Audio использует столбец thumbnail, а модель Image игнорирует его и пытается создать уменьшенную миниатюру с использованием 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 — в audio_set_foreign_identifier. Это позволит сохранить столбец thumbnail в API, но уменьшить объём каталога, поскольку миграцияМиграция Перенос кода, базы данных и медиафайлов сайта с одного сервера на другой. Чаще всего выполняется при смене хостинговой компании. такого размера в API, вероятно, сейчас была бы неприемлемой. Затем мы внесём по два изменения в логику на обеих сторонах:
- Добавить логику обработки
thumbnail_urlвImageStore, которая будет автоматически помещать это значение в словарьmeta_data - Изменить логику модели Image в API: сначала пытаться использовать
image.thumbnail(который был скопирован изmeta_data["thumbnail_url"]во время обновления данных), а затем использоватьimage.urlпри создании уменьшенного изображения
Потенциально мы могли бы сделать то же самое для Audio: похоже, примерно у половины записей нет миниатюр:
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)
Что вы думаете об этом подходе? Я считаю, что любые усилия по уменьшению ширины таблиц нашей базы данных важны, поскольку в дальнейшем это упростит миграции и управление данными.