Чому створено get.php та / або `core / file_storage_database`?

Оскільки у версії 1.5 або 1.6 Magento's мав файл у кореневій папці з назвою get.php. Цей файл, використовуючи core/file_storage_dataмодель, дозволяє власникам системи Magento обслуговувати медіафайли продукту безпосередньо з колонок блоку в базі даних, не маючи файлу зображень у файловій системі. 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;
    }
}

Це зазіхає на територію історії Магенто, але чому ця функція була розроблена? Здається - трохи шалено. PHP - не найефективніший спосіб обслуговування файлу, сховище блоків MySQL має історію нестабільності, і навіть стабільна реалізація блоків бази даних - це біль ззаду, з якою працювати, і те, що я бачу Varien_File_Transfer_Adapter_Http, не додає будь-які заголовки кешування цих файлів.

Хтось знає, чому Magento розробив цю функцію? Чи реально вона реалізує будь-яку мету / проблему, яку вона поставила для вирішення? Хтось ним користується?

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

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

Однак найімовірніший спосіб розгортання системи неоднаковий. Клієнти мають декілька примірників системи, розгорнутих на різних серверах, які потребують синхронізації. Ось чому два варіанти зберігання зображень мають бути розроблені як варіанти: база даних та CDN (мережа доставки вмісту).

CDN як альтернативний носій інформації буде реалізовано в системі лише як опція підтримки, а не як повна інтеграція з певними CDN. Адміністратору доведеться сам вибирати та конфігурувати CDN, а також виконувати незначні зміни в конфігурації системи.

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

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

Я думаю, що він призначений для кластерних середовищ. Кілька веб-вузлів з 1 db вузлом. Якщо сеанси / кеш також знаходяться в db (або іншому вузлі), ваш веб-вузол буде тільки для читання, і вам не доведеться синхронізувати медіа будь-коли під час створення нового веб-вузла.

В цілому я погоджуюся, що це схоже на інженерне рішення, яке шукає проблему.

Я був дуже радий бачити це в Magento, особисто, тому що (як згадують інші) це забезпечує спосіб для стеків з кількома веб-вузлами мати єдине авторитетне джерело зображень, не маючи справи з монтажами NFS.

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

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

Якщо ви можете зробити це на крок далі (так що ще менше запитів, щоб зняти зображення / посилання з файлової системи), я рекомендую використовувати CDN та встановити веб-сайт як джерело, а також змінити медіа-URL, як описано іншими.

З іншого боку, більшість конфігурацій MySQL матимуть дуже низьке значення "max_allowed_packet", яке обмежує розмір передачі даних, дозволений вашій БД. Якщо ви плануєте зберігати зображення в БД, ви можете це перевірити, щоб не стріляти в ногу.