Почему были созданы get.php и / или `core / file_storage_database`?

Начиная примерно с версии 1.5 или 1.6, Magento имел файл в корневой папке с именем get.php. Этот файл, используя core/file_storage_dataмодель, позволяет владельцам систем Magento обслуживать медиа-файлы своих продуктов непосредственно из столбцов BLOB-объектов в базе данных, не имея файла изображения в файловой системе. PHP обрабатывает отправку файла

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

Это отклоняется от исторической территории Magento, но почему эта функция была разработана? Кажется - слегка ненормальный. PHP - не самый эффективный способ обслуживания файла, хранилище больших двоичных объектов MySQL имеет нестабильную историю, и даже стабильная реализация больших двоичных объектов является трудной задачей, и, как я вижу Varien_File_Transfer_Adapter_Http, не добавляет любые заголовки кэширования для этих файлов.

Кто-нибудь знает, почему Magento разработал эту функцию? Достигает ли она на самом деле какой-либо цели / задачи, которую ставит перед собой? Кто-нибудь использует это?

Я действительно нашел оригинальную SRS для этой функции и могу поделиться ею здесь для исторических целей:

В настоящее время нет другого варианта для хранения мультимедиа, кроме как в файловой системе веб-сервера. Этот подход достаточно хорош, когда работает только один экземпляр системы, а база данных находится на том же сервере, что и экземпляр системы.

Однако наиболее вероятный способ развертывания системы не одинаков. Клиенты имеют несколько экземпляров системы, развернутых на разных серверах, которые требуют синхронизации. Вот почему два разных варианта хранения изображений должны быть разработаны как опции: База данных и CDN (Сеть доставки контента).

CDN в качестве альтернативного хранилища мультимедиа будет реализован в системе только как вариант поддержки, а не как полная интеграция с конкретными CDN. Администратору придется самостоятельно выбирать и настраивать CDN, а также вносить незначительные изменения в конфигурацию системы.

Я не буду вставлять сценарии использования, но для CDN упоминается только изменение базовых URL-адресов для изображений / обложек на URL CDN (я предполагаю, что требуется PULL CDN)

Я не тестировал его широко и не использовал в производстве, но использовал его для руководства Elastic Beanstalk + Magento . Преимущество заключается в том, что кластер веб-узлов не имеет общего доступа - файлы изображений сохраняются в бэкэнде БД при загрузке через администратора, а затем первоначально передаются оттуда (и, в идеале, из CDN после этого). Это означает, что вы можете избежать NFS для совместного использования медиа.

Я предполагаю, что он предназначен для кластерных сред. Несколько веб-узлов с узлом 1 дБ. Если сеансы / кэш также находятся в базе данных (или другом узле), ваш веб-узел будет доступен только для чтения, и вам не придется синхронизировать мультимедиа каждый раз, когда вы открываете новый веб-узел.

В целом я согласен, что это похоже на спроектированное решение, которое ищет проблему для решения.

Я был очень рад видеть это в Magento лично, потому что (как уже упоминали другие) это дает возможность для стеков с несколькими веб-узлами иметь единый авторитетный источник изображений без необходимости иметь дело с монтированием NFS.

Если вы похожи на меня и запускаете развертывание путем замены веб-узлов в балансировщике нагрузки и из него (например, с помощью конфигураций запуска AWS / групп автоматического масштабирования), это на самом деле вполне нормально.

Как правило, вы хотите избежать размещения изображений в БД по разным причинам, но способ, которым этот процесс (в основном) работает, заключается в том, что изображение вытягивается в локальную файловую систему из БД, а затем подается оттуда для последующих запросов ,

Если вы можете сделать еще один шаг вперед (так что запросов на извлечение изображений / ссылок из файловой системы еще меньше), я бы порекомендовал использовать CDN и указать исходный веб-сайт, а также изменить URL-адрес мультимедиа, как описано другими.

С другой стороны, большинство конфигов MySQL будут иметь очень низкое значение "max_allowed_packet", которое ограничивает размер передачи данных, разрешенный вашей БД. Если вы планируете хранить изображения в БД, вы можете проверить это, чтобы не выстрелить себе в ногу.