Nota: Esto está adaptado de una conversación que tuvo lugar en Make WP Slack (consulta el enlace para obtener más contexto).
Nuestra situación actual con respecto a las miniaturas
Los proveedores recopilaron las miniaturas y las colocaron en la columna thumbnail del catálogo. Ahora tenemos datos allí y la columna no se ha eliminado. Como esta columna también existe en la API, los datos que contiene (tanto para audio como para imágenes) también se copian en la columna thumbnail allí. Sin embargo, solo el modelo Audio utiliza la columna thumbnail; el modelo Image la ignora e intenta crear una miniatura reducida utilizando la URL de la imagen principal. La clase MediaStore del proveedor se ha modificado para que no se puedan añadir nuevas URL de miniaturas a la columna thumbnail, pero sí se pueden añadir en los metadatos, bajo meta_data["thumbnail_url"].
Recientemente nos hemos encontrado con situaciones en las que nuestros propios intentos de crear miniaturas a partir de las URL de las imágenes a tamaño completo han provocado tiempos de espera agotados de forma constante y han impedido que los registros se muestren en los resultados de búsqueda. SMK es un ejemplo reciente de esto: (1) (2). En estos casos, podría ser ventajoso utilizar las miniaturas precalculadas del proveedor. Y lo que es crucial, no todos los proveedores proporcionan miniaturas ni se espera que lo hagan. Por ello, parece que podríamos querer reducir el tamaño de nuestras tablas eliminando esta columna, que suele estar vacía.
Propuesta
Para image: primero recorremos todos los valores existentes de thumbnail en el catálogo y los copiamos en meta_data["thumbnail_url"]. Después realizamos un intercambio de tabla nueva sin columna y eliminamos la columna thumbnail de la tabla. Esto ayudará a ahorrar espacio y a reducir el tamaño de la tabla. Luego actualizamos la vista materializada image_view para rellenar una columna thumbnail para la APIAPI Una API o interfaz de programación de aplicaciones es un intermediario de software que permite a los programas interactuar entre sí y compartir datos de formas limitadas y claramente definidas. utilizando el diccionario meta_data. Un ejemplo de esto se encuentra en la vista de Audioaudio_set_foreign_identifier. Esto nos permitirá conservar la columna thumbnail en la API, pero reducir el espacio en el catálogo, ya que una migraciónMigración Trasladar el código, la base de datos y los archivos multimedia de un sitio web de un servidor a otro. Normalmente se realiza al cambiar de empresa de alojamiento. de ese tamaño en la API probablemente sería inviable por el momento. Después realizaremos dos cambios en la lógica de ambos extremos:
- Añadir la lógica de gestión de
thumbnail_urlenImageStore, que colocará automáticamente ese valor en el diccionariometa_data - Cambiar la lógica del modelo Image en la API para que primero intente utilizar
image.thumbnail(que se ha copiado demeta_data["thumbnail_url"]durante la actualización de datos) y luego intente utilizarimage.urlal crear la imagen reducida
Podríamos hacer lo mismo con Audio; parece que aproximadamente la mitad de los registros no tienen miniaturas:
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)
¿Qué opinan sobre este enfoque? Creo que cualquier esfuerzo por reducir el tamaño de nuestras tablas de la base de datos es importante, ya que facilitará las migraciones y la gestión de datos más adelante.