¿Por qué se creó get.php y / o `core / file_storage_database`?

Desde alrededor de la versión 1.5 o 1.6, Magento tenía un archivo en la carpeta raíz llamado get.php. Este archivo, utilizando el core/file_storage_datamodelo, permite a los propietarios del sistema Magento servir sus archivos multimedia de productos directamente desde columnas de blob en la base de datos sin tener un archivo de imagen en el sistema de archivos. PHP maneja el envío del archivo

#File: get.php
function sendFile($file)
{
    if (file_exists($file) || is_readable($file)) {
        $transfer = new Varien_File_Transfer_Adapter_Http();
        $transfer->send($file);
        exit;
    }
}

Esto se está desviando hacia el territorio de la historia de Magento, pero ¿ por qué se desarrolló esta característica? Parece, un poco loco. PHP no es la forma más eficiente de servir un archivo, el almacenamiento de blobs de MySQL tiene un historial de ser inestable, e incluso una implementación de blob de base de datos estable es una tarea difícil de trabajar, y por lo que puedo ver Varien_File_Transfer_Adapter_Httpno agrega cualquier encabezado de caché a estos archivos.

¿Alguien sabe por qué Magento desarrolló esta función? ¿Realmente logra cualquier objetivo / problema que se propuso resolver? ¿Alguien lo está usando?

En realidad, encontré el SRS original para esta función y puedo compartirlo aquí con fines históricos:

Actualmente no hay otra opción para almacenar medios, sino en el sistema de archivos del servidor web. Este enfoque es lo suficientemente bueno cuando solo hay una instancia del sistema ejecutándose y la base de datos se encuentra en el mismo servidor que la instancia del sistema.

Sin embargo, la forma más probable de implementación del sistema no es la misma. Los clientes tienen múltiples instancias del sistema implementadas en diferentes servidores, que requieren sincronización. Es por eso que se desarrollarán dos opciones diferentes de almacenamiento de imágenes como opciones: Base de datos y CDN (Content Delivery Network).

CDN como almacenamiento de medios alternativo se implementará en el sistema solo como una opción de soporte, no como una integración completa con un CDN específico. El administrador tendrá que elegir y configurar CDN él mismo, así como realizar pequeños cambios en la configuración del sistema.

No pegaré casos de uso, pero para CDN solo menciona el cambio de URL base para imágenes / máscaras a URL de CDN (supongo que requiere CDN PULL)

No lo he probado exhaustivamente, ni lo he usado en producción, pero lo he usado para mi guía Elastic Beanstalk + Magento . El beneficio es para un clúster de nodos web que no comparte nada: los archivos de imagen se almacenan en el backend de la base de datos cuando se cargan a través de admin, y luego se sirven inicialmente desde allí (e idealmente desde CDN después de eso). Significa que puede evitar NFS para compartir medios.

Supongo que es para entornos de clúster. Múltiples webnodes con 1 nodo db. Si las sesiones / caché también están en la base de datos (u otro nodo), su nodo web será de solo lectura y no tendrá que sincronizar medios cada vez que abra un nuevo nodo web.

En general, estoy de acuerdo en que parece una solución de ingeniería que busca un problema que resolver.

Me encantó ver esto personalmente en Magento, porque (como mencionan otros) proporciona una forma para que las pilas con múltiples nodos web tengan una única fuente autorizada de las imágenes sin tener que lidiar con los montajes NFS.

Si es como yo, y ejecuta implementaciones reemplazando nodos web dentro y fuera de un equilibrador de carga (como el uso de Configuraciones de lanzamiento de AWS / Grupos de escalado automático), esto es bastante sensato.

Por lo general, querrá evitar colocar imágenes en la base de datos por una variedad de razones, pero la forma en que funciona este proceso (básicamente) es que la imagen se extrae del sistema de archivos local desde la base de datos y luego se sirve desde allí para solicitudes posteriores .

Si puede ir un paso más allá (por lo que hay incluso menos solicitudes para extraer las imágenes / referencia del sistema de archivos), recomendaría usar un CDN y configurar su sitio web como el origen, y alterar la URL de los medios como lo describen otros.

Como nota al margen, la mayoría de las configuraciones de MySQL tendrán un valor muy bajo de "max_allowed_packet" que limita el tamaño de transferencia de datos permitido a su base de datos. Si planea almacenar imágenes en la base de datos, es posible que desee comprobar eso para no dispararse en el pie.