Где хранить изображения

    Намедни задумался над вопросом хранения изображений. Альтернативы две: в файловой системе и в базе данных. Это я, кстати, про изображения для веб-проектов.

    Почитал литературу. Как оказалось, но не было особо удивительным, у хранения файлов как файлов есть ряд преимуществ:
    • Скорость. Пожалуй, одно из самых важных преимуществ. Дело в том, что при хранении в БД нам надо произвести следующие действия для вывода изображения: считать стрим из базы, создать временный файл, записать в него стрим. Из файловой же системы его достаточно только считать.
    • Универсальность. Обычные изображения можно использовать для множества приложений: переслать через фтп, добавить в письмо, показать в браузере. Бинарные данные из базы необходимо сначала конвертировать.
    • Простота реализации. Закачать файл на сервер и сохранить ссылку на него в таблицу легче, чем реализовывать логику сохранения бинарных данных в ту же таблицу. А простота — это скорость разработки и внесения изменений. Время — деньги.
    • И если база вдруг накроется (представим, что бэкапов не было), то хотя бы изображения не потеряются.

    У хранения файлов в базе данных есть один несомненный плюс — шифрование. Но часто ли необходимы такие меры предосторожности для изображений? И довольно сложно синхронизировать файловую систему с базой: удалил запись, надо удалить и файл. В базе это же решается в один ход каскадным удалением соответствующей записи с BLOB'ом.

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

    Вердикт такой. Нельзя сказать, что какой-то из подходов более правильный, т.к. правильность определяется задачей. Более простым является стандартный способ хранения изображений как файлов. Но для некоторых задач более подходят базы данных.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 25

      –2
      для этого придумали FileStream
        +6
        Сколько живу, столько зову извращенцами кадров, хранящих в базе изображения и прочие не текстовые данные.
          +1
          Или я не понял ход Ваших мыслей или…

          > Скорость. Пожалуй, одно из самых важных преимуществ. Дело в том, что при хранении в БД нам надо произвести следующие действия для вывода изображения: считать стрим из базы, создать временный файл, записать в него стрим. Из файловой же системы его достаточно только считать.

          Зачем нам записывать данные в файл, если их надо отдать клиенту (речь ведь про веб-сервер)? Надо их считать и выдать в поток (сокет), через которых их получит клиент.

          > Универсальность. Обычные изображения можно использовать для множества приложений: переслать через фтп, добавить в письмо, показать в браузере. Бинарные данные из базы необходимо сначала конвертировать.

          Мы все еще говорим про веб-сервер? Он всем этим не занимается. Он только может отдавать изображения клиентам, в исходном виде или после какой-либо обработки «на лету»

          > Простота реализации. Закачать файл на сервер и сохранить ссылку на него в таблицу легче, чем реализовывать логику сохранения бинарных данных в ту же таблицу. А простота — это скорость разработки и внесения изменений. Время — деньги.

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

          > И если база вдруг накроется (представим, что бэкапов не было), то хотя бы изображения не потеряются.

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

          Реально у хранения изображений в файловой системе (т.е. статически!) есть одно важное преимущество — web-сервер (программа, например nginx или apache) хорошо (быстро и эффективно) умеют работать со статическими ресурсами, выдавать их клиентам, указывать, необходимо ли обновить этот ресурс или достаточно прочитать из кэша клиента и т.п. В случае с БД этот функционал придется писать самому (или пользоваться готовыми решениями), если он нужен.
          Поэтому:
          — если Вы однажды помещаете изображение на сервер и дальше будете его только выдавать клиентам в неизменном виде, то лучше хранить его в файле.
          — если же изображение будет обрабатываться перед выдачей, меняться в зависимости от запросов клиента и вообще вести бурную жизнь, то лучше его хранить в БД.
            0
            Я примерно то же самое и хотел сказать, что у вас в последнем параграфе.
            Только насчет «бурной жизни» не совсем понятно. Вы хотите операции напрямую над бинарными данными проводить? Если нет, то разницы где хранить изображение нет.
              0
              > В случае с файлом нужно совершить два действия (записать файл и поместить ссылку на него в таблицу), в > случае с хранением в БД — только одно.

              На самом деле в случае с БД тоже два. Содержимое файла как правило обычно получают из временного файла. В остальном полностью с Вами солидарен.
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Можно, но в базе это проще сделать.
                • НЛО прилетело и опубликовало эту надпись здесь
                –1
                большой плюс хранения файлов в базе, когда их тысячи и размер не более 1 метра,
                в остальных случаях файловая система
                  0
                  какой же это плюс?
                    +1
                    а что это минус?
                    возрастает скорость работы с данными особенно когда их много
                    разбивать на каталоги это хорошо, но когда кол-во файлов, как я написал исчисляется тысячами лучше хранить в базе

                  +1
                  Что-то ни_о_чем статья у Вас получилась. Вывод какой-то странный…

                  Например, что мешает шифровать файлы, и выдавать через скрипт дешифрованный стрим?

                  Основные проблемы хранения изображений в файлах это:
                  — при большом кол-ве файлов, файловая система начинает тормозить (СУБД, как правило хранят все с физически одном файле);
                  — целостность базы при удалении (надо заботиться об удалении файла, а не только записи в БД).

                  Но первое решается созданим структуры каталогов, и раскидыванием в них файлов,
                  и второе, не такой уж «гемморой», для большинства задач лечится периодической «сборкой мусора» из крона.

                    0
                    Ничего не мешает, только это сложнее все. Статья как раз о том, что в зависимости от целей одно или другое решение удобнее.

                      +1
                      Объясните, пожалуйста, чем сложнее?
                        0
                        Мне кажется, это более трудоемкое решение, чем простая запись в базу. Я могу и заблуждаться.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Как вариант хранение база + кеш в файловую систему
                      Для маленького проекта — плохое решение
                      Зато для большого — когда куча серверов и нужно масштабирование — очень даже ничего )
                        0
                        у хранения в базе главный плюс — это контроль за целостностью данных
                          0
                          Обсуждалось миллион раз. В том числе и на Хабре.
                          habrahabr.ru/blogs/mysql/45966/
                            0
                            Да, действительно. Там даже более детально разобрано. Мой топик в топку. Читаем все там :)
                            0
                            Зато из базы труднее проксировать в nginx
                              0
                                0
                                Этот документ совершенно не учитывает нюансы веб-разработки. СУБД не понимают (и не должны) протокола HTTP — а значит программисту приходится учитывать их в коде.
                                0
                                а зачем их шифровать?
                                • НЛО прилетело и опубликовало эту надпись здесь

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое