Задать вопрос
  • Стоит ли хранить изображения base64 в БД?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    В общем случае - нет.
    В конкретных случаях - ну если много маленьких иконок, то можно использовать такой вариант. Или svg текстом можно так хранить.
    base64 кодирует все триолями, поэтому любой файл увеличивается на ~30%, если что то уж хотя бы в бинарных blob можно пробовать. А так - просто в виде файлов или специализированная база типа s3 предпочтительнее
    Ответ написан
    2 комментария
  • Стоит ли хранить изображения base64 в БД?

    Sanasol
    @Sanasol
    нельзя просто так взять и загуглить ошибку
    Стоит ли хранить изображения base64 в БД?

    нет

    composer require symfony/dom-crawler

    use Symfony\Component\DomCrawler\Crawler;
    use Illuminate\Support\Facades\Storage;
    use Illuminate\Http\File;
    
    $desc = $request->input('some_html'); // POST with html
    $dom_desc = new Crawler($desc);
    $images = $dom_desc->filterXPath('//img')->extract(array('src')); // extract images
     
    foreach ($images as $key => $value) {
        if (strpos($value, 'base64') !== false) { // leave alone not base64 images
            $data = explode(',', $value); // split image mime and body
            $tmp_file = tempnam('/tmp', 'items'); // create tmp file path
            file_put_contents($tmp_file, base64_decode($data[1])); // fill temp file with image
            $path = Storage::putFile('public/items', new File($tmp_file)); // put file to final destination
            $desc = str_replace($value, $path, $desc); // replace src of converted file to fs path
            unlink($tmp_file); // delete temp file
        }
    }
    Ответ написан
    1 комментарий
  • Стоит ли хранить изображения base64 в БД?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Классические реляционные СУБД (MySQL) плохо приспособлены к хранению бинарных
    файлов. Все дело в размере строки. Исторически 1 строка (data_row) в БД не превышала 4-8 килобайт.
    Исходя из этого ограничения БД проектируют кеш и алгоритмы когеретности по кешу.
    И все работает отлично до тех пор пока вы не начинаете миксовать крупные файлы и строку БД.
    В этом случае мехнизм кеширования БД ломается и БД вынуждена ходить в disk (tablespace)
    который по total cost of ownership всегда стоит дороже чем обычный диск, и тем более дороже
    чем хранилище AWS/MS-Blob/GDrive. Дороже будет стоить бэкап базы данных которая на 95%
    к примеру состоит из JPG картинок вместо реляционных данных. Такова специфика дискового
    пространства почти любой БД. Не удивляйтесь если облачный биллинг вам выкатит счет
    по которому JPG картинки будут стоить как крипта. Дороже будет сетевой траф для публикации картинки
    ведь вам надо сделать сначала трансфер этих мегабайтов с хоста MySQL в Node/Tomcat/Apache
    и лишь только потом сделать еще один трансфер с веб хостинга к клиенту. Трафик - 2x.

    Поэтому имеет смысл толстые картинки положить в обычный диск под веб сервером Apache
    или пошарить хранилище через web-endpoint. В этом случае биллинг за хостинг картинок
    для вас станет хотя-бы разумным. А в реляционной базе хранить тольк URL на этот диск.
    Ответ написан
    3 комментария