Por que o get.php e / ou o `core / file_storage_database` foram criados?

Desde a versão 1.5 ou 1.6, o Magento tinha um arquivo na pasta raiz chamado get.php. Esse arquivo, usando o core/file_storage_datamodelo, permite que os proprietários do sistema Magento sirvam seus arquivos de mídia do produto diretamente das colunas de blob no banco de dados sem ter um arquivo de imagem no sistema de arquivos. PHP manipula o envio do arquivo

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

Isso está mudando para o território histórico do Magento, mas por que esse recurso foi desenvolvido? Parece - um pouco louco. PHP não é a maneira mais eficiente de servir um arquivo, o armazenamento de blob do MySQL tem um histórico instável, e até mesmo uma implementação estável de blob de banco de dados é uma dor de trás para trabalhar, e pelo que eu posso ver Varien_File_Transfer_Adapter_Httpnão adiciona quaisquer cabeçalhos de cache para esses arquivos.

Alguém sabe por que o Magento desenvolveu esse recurso? Realiza realmente qualquer objetivo / problema que se propõe a resolver? Alguém está usando?

Na verdade, encontrei o SRS original para esse recurso e posso compartilhá-lo aqui para fins históricos:

Atualmente, não há outra opção para armazenar mídia, mas no sistema de arquivos do servidor web. Essa abordagem é boa o suficiente quando há apenas uma instância do sistema em execução e o banco de dados está localizado no mesmo servidor que a instância do sistema.

No entanto, a maneira mais provável de implantação do sistema não é a mesma. Os clientes têm várias instâncias do sistema implantadas em servidores diferentes, que exigem sincronização. É por isso que duas opções diferentes de armazenamento de imagens devem ser desenvolvidas como opções: banco de dados e CDN (Content Delivery Network).

A CDN como armazenamento de mídia alternativa será implementada no sistema apenas como uma opção de suporte, não como uma integração completa com uma (s) CDN (s) específica (s). O administrador terá que escolher e configurar o CDN, além de realizar pequenas alterações na configuração do sistema.

Não colarei casos de uso, mas para a CDN, ele menciona apenas a alteração de URLs base de imagens / skins para a URL da CDN (presumo que exija PULL CDN)

Não testei extensivamente, nem usei na produção, mas usei-o para o meu guia Elastic Beanstalk + Magento . O benefício é para um cluster de nó da Web sem compartilhamento - os arquivos de imagem são armazenados no back-end do banco de dados quando carregados via admin e, em seguida, são servidos inicialmente a partir daí (e, de preferência, a partir da CDN). Isso significa que você pode evitar o NFS para compartilhar mídia.

Meu palpite aqui é que ele é destinado a ambientes de cluster. Vários nós da web com 1 nó de db. Se as sessões / cache também estiverem no banco de dados (ou outro nó), seu nó da web seria somente leitura e você não precisará sincronizar a mídia sempre que criar um novo nó da web.

No geral, concordo que parece uma solução projetada que procura um problema para resolver.

Fiquei bastante satisfeito ao ver isso no Magento, pessoalmente, porque (como outros estão mencionando), ele fornece uma maneira de pilhas com vários nós da web terem uma única fonte autorizada de imagens sem precisar lidar com montagens NFS.

Se você é como eu, e executa implantações substituindo nós da web dentro e fora de um balanceador de carga (como o uso de Configurações de inicialização da AWS / Grupos de dimensionamento automático), isso é realmente bastante sensato.

Normalmente, você deseja evitar colocar imagens no banco de dados por vários motivos, mas a maneira como esse processo (basicamente) funciona é que a imagem é puxada para o sistema de arquivos local do banco de dados e, em seguida, servida a partir daí para solicitações subsequentes .

Se você puder dar um passo adiante (para que haja ainda menos solicitações para baixar / referenciar as imagens do sistema de arquivos), recomendo usar uma CDN e definir seu site como a origem, além de alterar o URL da mídia, conforme descrito por outros.

Em uma nota lateral, a maioria das configurações do MySQL terá um valor "max_allowed_packet" muito baixo, o que limita o tamanho da transferência de dados permitida ao seu banco de dados. Se você está planejando armazenar imagens no banco de dados, pode verificar isso para não dar um tiro no pé.