Хранение графической информации - где?

VistaSolutions, дык проблема чисто при ручной обработке данных файлов?

SolNikolay, я не про ручную обработку, возможно вы меня не так поняли.
Я именно про хранение файлов именно в файловой системе.

Возможно так и реализовано на сервисе
ссылка

SolNikolay, нет. Проблема и во времени доступа.

VistaSolutions, alibek, странно. У нас программеры утверждают, что разницы нет. Особенно на никсах.

SolNikolay, ну, сколько людей столько и мнений

VistaSolutions, ну к примеру возьмем конкурентный ресурс - там файлы просто имеют уникальный id и похоже свалены в одну кучу.

SolNikolay, насчет *никсов не скажу, потому что степень этого влияния от файловой системы зависит. Но в FAT и в NTFS (в NTFS в меньшей степени) время доступа зависит от того, сколько файлов в папке. В юниксовых файловых системах наверняка всего тоже.
Потому что вначале файл надо найти в указателе, чтобы определить, где физически на диске он размещается. И найти файл в списке из 10 элементов будет быстрее, чем в списке из 10000 элементов.

Отвечаю всем.

1. Бэкап проверяется. Иначе какой смысл его делать? Он проверяется при так называемом "техобслуживании сервера".
2. Ежесуточный делается ежесуточно ночью, а еженедельный - в выходные. Чтобы не хранить все яйца в одной корзине. Затем они копируются на разные физические диски и на еще один сервер, который только хранит бэкапы и ничего не делает больше. Избыточность в данном случае оправдана.
3. Чем MySQL провинилась, что ее должны осудить? Юридический статус GPL в России никто не оспаривает. Используемый дистрибутив Linux-а имеет сертификат по безопасности. В чем конкретно проблема?
4. В данном случае не стоит задача бэкапить именно быстро. А если бы она встала - была бы организована другая схема, с репликацией данных или каким-то другим вариантом. А сейчас копирование файлов полностью устраивает, тем более что у MySQL они платформо-независимые. И была бы взята платная поддержка у MySQL AB, если уж на то пошло...
5. MySQL 4.1, если я не ошибаюсь. На 5 переходить не планируется.

SolNikolay, как раз там больше похоже на то, что файлы хранятся в блобах.

alibek, да вы дольше читать FAT будете.

TO4KA, какого у вас размера база-то?

Небольшого. Колеблется около 5 гигабайт.

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

TO4KA, а теперь представьте фотосток, в котором фотки по 2-3 метра весят каждая.

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

Кэш? В нормальных ФС он тоже в наличии.

А вариант создания RAM-диска никто не рассматривает? На несколько гигов? Если так критичная производительность?

Цитата ("TO4KA"):

А вариант создания RAM-диска никто не рассматривает? На несколько гигов? Если так критичная производительность?

Вопрос о базе в терабайты!

> Вопрос такой: каким образом хранить такую информацию? В виде блобов в СУБД? Или в файловой системе с хранением ссылок?
давайте прочитаем по словам "файловая система" и "база данных", изображение является файлом, думаю далее вопросов быть не должно

>Причем с делением на папки
вроде применительно только к определенным файловым системам (ext2 ?)

>1. По скорости будет тормозить только при мервом обращении к графическому элементу, потом будет идти быстрая работа с кешем.
+ ожидается много проблем с написанием такого кеша (операции удаления будут самыми проблемными)

>2. Надежность. Хранение информации в файловой системе потенциально ненадежно. Усложняется логика бакапов. Намного усложняется менеджмент графики в файловой системе (с базой данных намного проще делать DML операции).
возьмем классический mysql, myisam таблицы востанавливаются без проблем, с innodb были проблемы, как сейчас не знаю. для бекапов на ФС легко накрутить систему версионного контроля, да и под нормальными ос есть|будет ФС zfs где скорость бекапа будет потрясающей, а размер минимальным

>3. Если один сервер не будет справляться с нагрузкой, можно будет сделать кластерное решение. При этом намного проще и надежнее наладить взаимную репликацию баз данных, чем поставить сетевую файловую систему.
есть rsync, хотя можно применить ваш 1 пункт для работы с серверами отдающими статику и не будет тормоза на первой выдаче, только на загрузке изображения.

ps может кому поможет ссылка
pss во многом могу ошибаться, тк не сисадмин

TO4KA, смысла в создании RAM-диска нет.
Существуют специальные базы данных, которые работают в оперативной памяти. В таких случаях удобнее использовать именно их.

Цитата ("e1it3"):

давайте прочитаем по словам "файловая система" и "база данных", изображение является файлом, думаю далее вопросов быть не должно

изображение - это всё-таки не файл!
Цитата ("e1it3"):

>Причем с делением на папки
вроде применительно только к определенным файловым системам (ext2 ?)

Почему? Это для всех систем полезно
Цитата ("e1it3"):

>1. По скорости будет тормозить только при мервом обращении к графическому элементу, потом будет идти быстрая работа с кешем.
+ ожидается много проблем с написанием такого кеша (операции удаления будут самыми проблемными)

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

Как всё-таки форум хорошо показывает уровень большинства фрилансеров. дет. сад.
бд надёжнее фс - как уже тут отметили, бд хранит данные в фс, а значит не может быть надёжнее, а наоборот, промежуточное звено только добавляет рисков.
кэширование - потеря производительности(на проверку существования кэша и на вытягивание блоба в случае необходимости) и памяти(часть файлов хранится в бд и ещё в фс).
в некоторых ситуациях, кэширование вообще будет не актуально. что тогда? показываем страницу галереи, на которой 32 картинки - в итоге получаем 32 коннекта mysql на генерацию 1 страницы - это накладно немного. а при хранении в файловой системе, можно не дёргать ни php(или...), ни mysql, а отдавать статику тоненьким сервером.
опять-таки, бэкап и перенос проще на фс. если-же дело касается вирт. хостинга, то перенести базу станет не тривиальной задачей, так и придётся всё сливать в файлы.

и в чём спрашивается преимущество хранение изображений в бд???? кто-нибудь может внятно ответить?

Pilat66, Цитата:

изображение - это всё-таки не файл!

а что это???