Лучший способ хранения двоичных файлов или файлов изображений
Вопрос
Каков наилучший способ хранение двоичного файла или изображение файлы?
- База данных Система
- Файл Система
Не могли бы вы, пожалуйста объясните, почему?
Решение
На самом деле лучшего способа не существует, просто куча компромиссов.
Плюсы базы данных:
1.Гораздо проще иметь дело в среде кластеризации.
2.Не полагайтесь на дополнительные ресурсы, такие как файловый сервер.
3.Нет необходимости настраивать операции "синхронизации" в среде с балансировкой нагрузки.
4.Резервные копии автоматически включают эти файлы.
Минусы базы данных:
1.Размер / Рост базы данных.
2.В зависимости от сервера базы данных и вашего языка его может быть трудно ввести и извлечь.
3.Скорость / Производительность.
4.В зависимости от сервера базы данных вам необходимо проверять файлы на вирусы во время загрузки и экспорта.
Плюсы файла:
1.При установке одного веб-сервера / одного сервера базы данных это происходит быстро.
2.Хорошо понятная способность манипулировать файлами.Другими словами, файлы легко переместить в другое место, если у вас заканчивается место на диске.
3.Может сканироваться на вирусы, когда файлы находятся "в состоянии покоя".Это позволяет вам воспользоваться преимуществами обновлений сканера.
Минусы файла:
1.В средах с несколькими веб-серверами требуется доступная общая папка.Который также должен быть кластеризован для отработки отказа.
2.Дополнительные требования безопасности для обработки доступа к файлам.Вы должны быть осторожны, чтобы веб-сервер и / или общий ресурс не разрешали выполнение файла.
3.Резервные копии транзакций должны учитывать файловую систему.
Учитывая вышесказанное, в SQL 2008 есть функция под названием FILESTREAM, которая объединяет оба мира.Вы загружаете файлы в базу данных, и она прозрачно сохраняет их в каталоге на диске.При извлечении вы можете либо извлечь данные из базы данных;или вы можете перейти непосредственно к тому месту, где он находится в файловой системе.
Другие советы
Плюсы хранения двоичных файлов в базе данных:
- Некоторое снижение сложности, поскольку уровень доступа к данным вашей системы нуждается только в интерфейсе к БД, а не к БД + файловая система.
- Вы можете защитить свои файлы, используя ту же самую комплексную систему безопасности на основе разрешений , которая защищает остальную часть базы данных.
- Ваши двоичные файлы защищены от потери вместе с остальными вашими данными посредством резервного копирования базы данных.Нет отдельной системы резервного копирования файловой системы требуется.
Минусы хранения двоичных файлов в базе данных:
- В зависимости от размера / количества файлов может занимать значительное пространство потенциально снижая производительность (зависит от того, хранятся ли ваши двоичные файлы в таблице, к которой часто запрашивается другое содержимое или нет) и создание более длительного резервного копирования раз.
Плюсы хранения двоичных файлов в файловой системе:
- Это то, в чем хороши файловые системы в.Файловые системы хорошо справятся с дефрагментацией и извлечением файлов (скажем, для потоковой передачи видеофайла через веб-сервер), скорее всего, будет быстрее, чем с базой данных.
Минусы хранения двоичных файлов в файловой системе:
- Немного более сложный доступ к данным слой.Нуждается в собственной системе резервного копирования.Необходимо учитывать ссылки проблемы целостности (напримерудалено указатель в базе данных должен будет привести к удалению файла, чтобы не иметь "потерянных" файлов в файловой системе).
В целом я бы использовал файловую систему.В прошлом, используя SQL Server 2005, я бы просто сохранял "указатель" в таблицах БД на двоичный файл.Указателем обычно является GUID.
Вот хорошая новость, если вы используете SQL Server 2008 (и, возможно, другие - я не знаю):имеется встроенная поддержка гибридного решения с новым типом данных FILESTREAM VARBINARY(MAX) FILESTREAM.Логически они ведут себя как столбцы VARBINARY (MAX), но за кулисами SQL Sever 2008 будет хранить данные в файловой системе.
Лучшего способа не существует.
Что?Вам нужно больше информации?
Есть три способа, о которых я знаю...Один, в виде массивов байтов в базе данных.Во-вторых, в виде файла с путем, хранящимся в базе данных.Три, как гибрид (только если позволяет база данных, например, с Файловый поток тип).
Первый довольно крут, потому что вы можете запросить и получить свои данные на одном шаге.Что всегда приятно.Но что происходит, когда у вас МНОГО файлов?Ваша база данных становится все больше.Теперь вам приходится иметь дело с большими проблемами обслуживания баз данных, такими как пробное резервное копирование баз данных объемом более терабайта.А что произойдет, если вам понадобится внешний доступ к файлам?Например, преобразование типов, массовые манипуляции (изменение размера всех изображений, водяные знаки appy и т.д.)?Это гораздо сложнее сделать, чем когда у вас есть файлы.
Второй вариант отлично подходит для несколько большого количества файлов.Вы можете хранить их на устройствах NAS, создавать их резервные копии постепенно, уменьшать размер своей базы данных и т.д. И т.п.Но затем, когда у вас МНОГО файлов, вы начинаете сталкиваться с ограничениями в файловой системе.И если вы распространяете их по сети, вы получаете проблемы с задержкой, правами пользователей и т.д.Кроме того, мне жаль вас, если ваша сеть будет перестроена.Теперь вам приходится запускать массовые обновления базы данных, чтобы изменить расположение ваших файлов, и мне жаль вас, если что-то не так.
Тогда есть гибридный вариант.Это почти идеально - вы можете получить свои файлы с помощью запроса, но ваша база данных невелика.Решает ли это все ваши проблемы?Вероятно, нет.Ваша база данных больше не переносима;вы привязаны к определенной СУБД.И этот материал еще не созрел, так что вы можете наслаждаться процессом прорезывания зубов.И кто сказал, что это решает все различные проблемы?
Факт в том, что "лучшего" способа не существует.Вам просто нужно определить свои требования, сделать наилучший выбор в зависимости от них, а затем смириться с этим, когда поймете, что поступили неправильно.
Мне нравится хранить изображения в База данных.Это позволяет легко переключиться с разработки на производство, просто изменив базы данных (без копирования файлов).И база данных может отслеживать такие свойства, как даты создания / изменения, точно так же, как Файловая система.
Лично я никогда не сохраняю изображения В базе данных в целях повышения производительности.На всех моих сайтах у меня есть папка "/ files", куда я могу поместить вложенные папки в зависимости от того, какие изображения я собираюсь сохранить.Затем я называю их по соглашению.
Например, если я сохраняю фотографию профиля, я сохраню ее в "/files/profile/" как profile_2.jpg (если 2 - идентификатор учетной записи).Я всегда беру за правило изменять размер изображения на сервере до самого большого размера, который мне понадобится, а затем уменьшать его, если они мне понадобятся.Поэтому я бы сохранил "profile_2_thumb.jpg" и "profile_2_full.jpg".
Создавая правила для себя, вы можете просто вызвать img src="/files/profile__thumb.jpg" в коде
Во всяком случае, так я это делаю!