Soft4Commerce Сообщение 29/11/2010 11:23 Копия темы
Где лучше хранить BLOB? Здравствуйте.

У меня такой вопрос: "Где лучше всего, сточки зрения производительности хранить BLOB данные?"
Я планирую хранить в БД большое количество фотографий (20-50 Gb) 
Как лучше спроектировать БД?

1) Хранить BLOB в одной таблице с другими данными
2) Выделить для BLOB отдельную таблицу
3) Выделить отдельную базу данных

По теории без разницы, где хранить (в таблицах храниться только ссылка на BLOB поле), а на практике кто-нибудь сравнивал различие в производительности при разных вариантах?

andrey_a_enkin Сообщение 29/11/2010 11:50 Копия темы
в чем смысл хранить фото в БД?
SELECT photo FROM table WHERE content LIKE('%сиськи%') не замутить, а насиловать сервер БД гигами данных придется.

Soft4Commerce Сообщение 29/11/2010 12:02 Копия темы
еще как можно замутить!
не думайте, что MySQL единственная СУБД в мире (хотя и в MySQL можно так сделать)

преимуществ хранения фото в БД несколько
1) их сложнее украсть парсерам
2) нет проблем с именами файлов (разный регистр на Unix серверах)
3) полный контроль и целостность БД (файл c фото  может быть удален, а ссылка на него в БД остаться, при хранении фото в самой БД такого не произойдет)
4) легкая возможность назначения прав доступа различным пользователям
5) более быстрое получение статистики
6) полностью исключена ситуация когда файлы с одинаковыми именами "затирают" друг друга

>>а насиловать сервер БД гигами данных придется
никакого насилия нет, СУБД для того и разрабатывались, чтобы обрабатывать гигабайты данных

rolef Сообщение 29/11/2010 12:05 Копия темы
с точки зрения производительности в базе лучше хранить ссылки на картинки. Иначе сервер при увеличении обращений к базе быстро ляжет

Soft4Commerce Сообщение 29/11/2010 12:12 Копия темы
обсуждение плавно перетекло от вопроса "как лучше сделать?" к вопросу "а зачем так делать?"

с тем, что фото будут храниться в самой БД я уже определился,  теперь мне нужно решить как лучше это сделать.

Soft4Commerce Сообщение 29/11/2010 12:13 Копия темы
сервер БД нормально переживет даже сотню одновременных запросов

dvaes Сообщение 29/11/2010 13:06 Копия темы
не верю

Soft4Commerce Сообщение 29/11/2010 13:10 Копия темы
ну не верите – не верьте

а я проверял... все Ok

dvaes Сообщение 29/11/2010 13:18 Копия темы
оптимизаторы бьются за каждый килобайт в бд на типах данных, чтобы объем передаваемых данных от сервера бд к обработчику был как можно меньше, ставят различные nginx чтобы с меньшей нагрузкой отдавать статические файлы, а вы 20-50 Гб и в бд... по-моему загнется сервер даже при небольшом ко-ве посетителей

Soft4Commerce Сообщение 29/11/2010 13:34 Копия темы
>> оптимизаторы бьются за каждый килобайт в бд на типах данных, чтобы объем передаваемых данных от
>> сервера бд к обработчику был как можно меньше

а Кто Вас заставляет отдавать пользователю сразу все поля/записи из таблицы?!!!
правильно составляйте SQL запросы!


>> а вы 20-50 Гб и в бд... по-моему загнется сервер даже при небольшом ко-ве посетителей
Microsoft собирается в новой Windows вообще отказаться от файловой системы в пользу БД

Soft4Commerce Сообщение 29/11/2010 13:35 Копия темы
OpenCMS то же хранит все файлы в БД (у нее своя виртуальная файловая система)

и ничего, работает.... а по производительности мало какая CMS с ней может потягаться

csky Сообщение 29/11/2010 14:33 Копия темы
У вас есть еще время передумать :)

преимуществ хранения фото в БД несколько
1) их сложнее украсть парсерам – чем сложнее? – Парсеру до лампочки как хранятся изображение.
2) нет проблем с именами файлов (разный регистр на Unix серверах) – их и так нет, приводите имена файлов к нужному виду
3) полный контроль и целостность БД (файл c фото  может быть удален, а ссылка на него в БД остаться, при хранении фото в самой БД такого не произойдет) – таким образом и скрипт можно удалить – тогда все перестанет работать.
4) легкая возможность назначения прав доступа различным пользователям – а с файловой системой не легкая возможность?
5) более быстрое получение статистики – каким образом?
6) полностью исключена ситуация когда файлы с одинаковыми именами "затирают" друг друга – вопрос номер 2.
+ ко всему база данных файлы не в святой материи хранит, а в тех же файлах. Нужна ли вам лишняя прослойка, не предназначенная для этого.

Soft4Commerce Сообщение 29/11/2010 14:51 Копия темы
>>1) их сложнее украсть парсерам – чем сложнее? – Парсеру до лампочки как хранятся изображение. 
Если фото храниться в файлах, то за их выдачу отвечает сервер (Apache к примеру) я не могу контролировать поведение сервера,
Если фото хранятся в БД, то я легко могу это предотвратить

>>2) нет проблем с именами файлов (разный регистр на Unix серверах) – их и так нет, приводите имена файлов к нужному виду 
проблемы с именами рано или поздно возникают у всех, другое дело, что эти проблемы замечают не сразу (или вообще не замечают)

>>3) полный контроль и целостность БД (файл c фото  может быть удален, а ссылка на него в БД остаться, при хранении фото в самой БД такого не >>произойдет) – таким образом и скрипт можно удалить – тогда все перестанет работать

а я не дам скриптам права удалять записи "из под ограниченного пользователя", только ROOT будет иметь такую возможность
+ каскадное обновление зависимых таблиц

>>4) легкая возможность назначения прав доступа различным пользователям – а с файловой системой не легкая возможность? 
Создавать для каждого файла свой набор правил в .htaccess?  по Вашему это легкий путь?
или разносить файлы по разным каталогам?

>>5) более быстрое получение статистики – каким образом? 
мне не нужно каждый раз сканировать файловую систему чтобы узнать сколько у меня фоток в разных категориях, какого они размера и когда добавлены и вообще существует ли такой файл или его кто то удалил...

>>+ ко всему база данных файлы не в святой материи хранит, а в тех же файлах. Нужна ли вам лишняя прослойка, не предназначенная для этого.
похоже Вы не знакомы со внутренним устройством БД.

БД все данные и обычные поля и индексы и BLOB поля хранить в "страницах", если поле не помещается в одной странице, резервируется еще одна 
т.е.  все храниться именно "в святой материи" как Вы выразились :)

сам файл БД естественно обычный файл, но сервер СУБД умеет быстро с ним работать.

Stierus Сообщение 29/11/2010 15:26 Копия темы
"но сервер СУБД умеет быстро с ним работать." ... этим окончательно добил. Весь текст держал в напряжении, все думалЖ "ну когда же, когда же", – и вот она, долгожданная кульминация :)))

Soft4Commerce Сообщение 29/11/2010 16:24 Копия темы
очень рад за то, что Вы дождались...

вот пример программы, которая ищет все файлы в своем подкаталоге и ниже
затем удаляет все файлы которые содержат русский текст или HTTP://

soft4commerce.ru/download...


НА ПОИСК ФАЙЛОВ УХОДИТ БОЛЬШЕ ВРЕМЕНИ, ЧЕМ НА ИХ ОБРАБОТКУ!!!!

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


Сервер БД изначально знает по какому смещению от начала файла БД "лежит" требуемая информация

Есть такая пословица: "Старый конеь борозды не портит, но и новую не делает"
так вот большинство программистов используют только проверенные методики,
а все новое – вызывает смех. 
 
Зеркала заденго вида на авто то же сначала вызывали недоумение, все говорили,
это не удобно, мне проще саому глову повернуть :)

Stierus Сообщение 29/11/2010 16:39 Копия темы
попробуйте вложенные паки  – говорят, файловой системе не очень нравится, когда в одну папку срут сотнями тысяч файлов

Soft4Commerce Сообщение 29/11/2010 16:49 Копия темы
ну и зачем мне эти проблемы со вложенными папками?

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

Soft4Commerce Сообщение 29/11/2010 18:24 Копия темы
еще один недостаток при хранении большого числа фоток в файлах

попробуйте открыть по FTP каталог с фотками (100-200 тысяч файлов) на хостинге
пока будет грузиться спсиок файлов, можно попить чаю с соблюдением всех правил чайной церемонии

idle Сообщение 29/11/2010 21:02 Копия темы
Ну Павел и говорит что в одну директорию нельзя класть много файлов, при количестве >10k начинает сильно тормозить.

Soft4Commerce Сообщение 29/11/2010 21:39 Копия темы
это только одна из причин по которой я не хочу хранить фото в файлах,
на мой взгляд БД дает намного больше преимуществ, а быстродействие если и упадет то незначительно (или наоборот увеличьтся)

====
думаю, что ответа на первоначальный вопрос блога я так и не дождусь, поэтому сейчас начну самостоятельно проводить
тесты производительности БД с разной структурой.

Stierus Сообщение 30/11/2010 05:44 Копия темы
не забудьте поделиться результатами (особенно интересно было бы увидеть результаты нагрузочного тестирования :) )

Soft4Commerce Сообщение 30/11/2010 09:29 Копия темы
Ok

напишу результаты тестов и саму методику тестирования

resurection Сообщение 05/12/2010 22:20 Копия темы
[irony]
База данных конечно намного быстрее выдаст Вашему скрипту содержимое картинки. Особенно, если база на другом сервере.
Если будете хранить в БД файлы, то ФТП будет отдавать список файлов гараздо быстрее. Правда, потом ещё придётся объяснять что с этими файлами делать и как из ячейки БЛОБ сделать файл.
А Вам этого нового коня подарили? Почему Вы ему под хвост не заглядываете? С тех пор как появилось ПХП, говнокодеры написали уже целое стадо таких коней.
[/irony]

Объясняю как надо:
1. Имя файла должно быть сгенерированно от md5() – тогда в нём не будет спецсимволов и пробелов. Никакие проблемы с юникс серверами больше не страшны!
2. В папке upload создать 256 папок с именами: "00", "01", ...., "fe", "ff". В скрипте который сохраняет и получает папку написать: $subDir =  subStr($fileName, 0, 2); // Например если файл называется 'd5484624791c68e1.jpg', то искать его надо в папке /upload/d5/d5484624791c68e1.jpg
3. Сохранить файл в ФС с совершенно рандомным названием и путём и в БД записать эти значения (id, file_name_without_extension, extension, file_size, width, height, .... ).
4. С помощью .htaccess полностью закрыть доступ к директории upload и раздавать файлы через скрипт: /download.php?id=74185 . Cкрипт должен находить запись в БД что бы определить где лежит файл. Потом делать readfile($filePath); и умирать

Философия:
БД + ФС + скрипты – это одна система. Никто не должен просто так удалять файлы с ФС. Всё должно происходить через веб-интерфейс. Тогда Вы сможете поддерживать актуальное состояние ФС и БД в соответствующих друг-другу состояниях. Ну а если кто-то полезет шариться во внутренности системы и удалять файлы......

Soft4Commerce Сообщение 10/12/2010 21:54 Копия темы
>>Никто не должен просто так удалять файлы с ФС
не должен, но удаляют, а чтобы обнаружить потерю целостности, придется все файлы перелопатить

resurection Сообщение 10/12/2010 22:16 Копия темы
А что они будут удалять, если все файлы будут с непонятными именами типа "d5484624791c68e1.jpg", да ещё раскиданы по куче папок?
Кстати, я тут подумал, что у файлов даже не надо расширение сохранять. Пускай будет просто "d5484624791c68e1". А вся инфа о файле всё равно есть в БД. И врятли тот кто додумался лазить по ФС, найдёт файл, который хочет удалить.

Soft4Commerce Сообщение 11/12/2010 13:37 Копия темы
Формат графики я определяю по содержимому, а не по расширению.
Несколько раз уже наталкивался на одни и те же грабли... стоит расширение ICO, а на самом деле JPEG.
Броузер то нормально обрабатывает, а скрипт спотыкается о "неверный" формат. :)

Soft4Commerce Сообщение 11/12/2010 13:43 Копия темы
Я согласен с тем, что можно эффективно организовать большое количество файлов (то что файл можно переименовывать по его хешу мне в голову еже приходило, но до создания 256 папок по первым 2 символам я не додумался)

НО! есть вероятность (значительно отличная от нуля), что попадутся два и более файлов, с одинаковым размером и/или одинаковым именем
так что хеш будет одинаковым а файл разным.

Например BMP не использует сжатия и соответственно 2 фото одинакового размера (высота/ширина) будут иметь и одинаковый размер файла

resurection Сообщение 11/12/2010 21:26 Копия темы
имя файла не должно быть его хешем. Зачем Вам хеш файла?
Имя файла должно быть просто рандомным. md5() – это всего лишь example. И при генерации рандома НУЖНО проверять, что бы такого файла ещё не существует. Если существует, генерировать рандом ещё раз.

Кстати, формат файла Вы должны определить только один раз во время загрузки и сохранить это в БД в отдельный столбец. Таким образом вы должны получить:
1. вся информация в базе данных.
2. файлы в ФС. В моём примере получается голый файл вообще не содержащий никакой инфы, даже расширение ему отрубили.