Хранить изображения в SQL или нет?

Question

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

Все мои изображения - это действительно маленькие черно-белые письма (не в оттенках серого, а в черно-белых тонах), размером 70x70. Если мы возьмем изображения (которые в основном являются двумерным массивом 1 и 0), они могут быть сохранены в виде двоичных данных, каждый из которых будет иметь размер приблизительно 600 байт.

Итак, мой вопрос заключается в том, будет ли запрос 600 байтов, хранящихся в БД, быстрее, чем запрос ссылки с последующим доступом к файловой системе; при условии, что выполняется много «графических» запросов.

Кто-нибудь имеет опыт работы в этой области?

Если это имеет значение, я использую MySQL и MonetDB (отдельно, но у меня один и тот же вопрос).

Большое спасибо, Brett

Answer 1

Если бы это было только 600 байтов, я бы не стал сильно беспокоиться и сохранял бы их в базе данных как BLOB-объект

В High Scalablilty есть интересная статья о том, как Flickr спроектирован. Это может оказаться полезным для вас.

Answer 2

Поскольку вы пометили вопрос sql-сервером, тогда я рекомендую вам прочитать Для блобов или не для блобов , исследовательский документ от сожаления Джима Грея. В статье содержится множество подробностей по теме хранения BLOB-файлов в файловой системе (NTFS) и базе данных (SQL Server), и вы будете поражены тем, сколько углов рассматривается. Это ДОЛЖНО читать. Но вывод таков:

Исследование показывает, что если объекты больше одного мегабайта на в среднем, NTFS имеет явное преимущество через SQL Server. Если объекты до 256 килобайт, база данных имеет явное преимущество. Внутри этого Диапазон, это зависит от того, как написать интенсивная нагрузка, и срок хранения типичной копии в система.

Ваш случай явно относится к делу "To BLOB".

Answer 3

Насколько я понимаю, нет проблем хранить еще большие файлы в БД, если вы не используете SELECT * без всякой причины (честно говоря, вообще нет причины использовать SELECT *).

BLOB-объекты и ТЕКСТЫ хранятся отдельно от других данных и не влияют на производительность, если не запрашиваются явно.

Answer 4

Хранение изображения в базе данных (и обслуживание его по каждому запросу) не позволяет вам кэшировать эти изображения на прокси-сервере (или, скорее, многократно усложняет задачу и блокирует практически все готовые решения) , Суть в том, что для измерения воздействия вам нужно взглянуть на него по-другому - вместо того, «сколько времени занимает один запрос для извлечения изображения, нужно« спросить себя », сколько времени выполняет серия (укажите здесь разумное число) запросов чтобы получить тот же набор изображений, занимает ". Может также спросить себя: «Должен ли я оплатить поездку туда-обратно до БД и обратно?».

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

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

Answer 5

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

Как говорит @codeholic, если вы не используете SELECT *, все идет хорошо.

Answer 6

Если вы говорите о веб-приложении, хранить изображения в базе данных просто глупо. Поскольку у вас нет преимуществ, которые может получить настольное приложение, а только трудности.