| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > BLOB-поля, производительность |
| Автор: WolfAlone 1.7.2011, 16:11 | ||||
| Доброго времени суток! Имеем: 1. БД (например, MySQL) 2. Тип таблиц: InnoDB. 3. 5шт. Blob-полей, размером до 2Мб В каждом из этих полей будет храниться фотография (от 1 до 5 [1 фотография = 1 поле]). Вопрос заключается в следующем: насколько резонно хранить фотографии непосредственно в БД? Увеличивается или снижается от этого производительность системы (сервера) в целом? В каких случаях фотографии лучше хранить именно внутри БД, а в каких лучше хранить ссылку на фото на жестком диске? Например, поле
содержащее ссылку на фото на жестком диске, что-то вроде:
Возможно, какой-то конкретный выбор наиболее актуален для какой-то конкретной БД или типа таблиц? P.S. Если это очень принципиально, то предполагается использование ОС: Debian 6 или FreeBSD 8, файловая система Ext3/Ext4 или UFS (соответственно). Сервер БД MySQL 5.1/5.5. |
| Автор: LSD 1.7.2011, 16:37 |
| Мое мнение: если фотографий мало и они лишь приложение к основным данным, то стоит хранить в СУБД. Если же это сервис хранения картинок или еще какой сервис в котором объем картинок перевешивает объем остальных данных, то стоит хранить в виде файлов. |
| Автор: maint 1.7.2011, 16:45 |
| В базе, если приспичило, в отдельной таблице. Моё мнение, хранить в файловой системе. Вообще, загрузка больших картинок на дороговато обходится. По моему, технология такая: высасываем из базы, создаётся времянка на диске и потом показывается. Так, кажется. |
| Автор: WolfAlone 1.7.2011, 17:22 |
Благодарю за ценную информацию! В моём случае фото (от 1 до 5шт.) - это "приложение" к остальным данным. Примером может служить, допустим таблица с объявлениями, например, о продаже машин, которая содержит следующие данные (исключительно для примера): Марка машины, текст объявления, цена, *ещё каких-нибудь 3-5 текстовых полей* + 1-5 фото. Максимальный размер, которого может достигать 1 фотография = 2Мб. То есть, при самом "худшем" раскладе, общий объём занимаемого фотографиями пространства составит 10Мб. Всё фото относятся исключительно к конкретной записи (в нашем примере, к конкретному объявлению).
Объясню чем мотивирован мой вопрос. В плане "удобства" хранения самих фотографий (на диске или в БД) - у меня принципиальных предпочтений нет. Но, в плане резервного копирования, хранить всё в БД, лично мне было бы гораздо удобнее, т.к. это позволит "отделить мух от котлет". То есть, платформа отдельно, все данные в БД - отдельно. Но, если хранение изображений внутри БД значительно скажется на производительности (снижение производительности более чем на 20-30%), то от такого способа мне придётся отказаться. P.S. Объём изображений (в байтах) однозначно будет превышать объём текстовых данных, возможно в несколько десятков или даже сонет раз. То есть, текст у нас занимает до 100Кб в строке, картинки могут занимать до 10Мб. |
| Автор: gcc 1.7.2011, 17:31 |
| лучше PostgreSQL, Oracle хотя, MySQL умеет буферизировать данные при выдачи но если понадобиться сделать бэкапы, то будут проблемы, твой сервис будет не работоспособный пока бэкап не загрузиться, по-моиму  или raid1 - то там как будут хз (но дополнительная стоимость на raid1) есть, например MogileFS протестированная на миллионы пользователей и на большой общий объем подробности с бэкапом не знаю, но крупные сервсиы используют ее, видимо работает |
| Автор: WolfAlone 1.7.2011, 17:37 | ||
gcc, к сожалению выбор ФС ограничен только 2-мя (3-мя), а именно: Ext3 (Ext4) или UFS. Поставить PostgreSQL вместо MySQL - не составляет никакого труда, платформа умеет работать с большим разнообразием БД.
возможно я ошибаюсь, но мне кажется многие БД позволяют делать "горячий" бэкап, то есть, бэкап без остановки сервера, не зависимо от наличия в базе BLOB-полей и их содержимого. |
| Автор: gcc 1.7.2011, 17:45 | ||
| WolfAlone, MogileFS - это не Posix (не встроенная в ОС, а внешние проложение) Добавлено @ 17:45
я имел ввиду, если сервер перезагрузиться, то надо будет восстанавливать таблицы, а они могут не восстановиться и нужно будет бэкап ЗАЛИВАТЬ... (но есть raid1 который зерклирует...) и если сервер очень нагруженные - это всегда плохо если делать бэкап в этот момент... бывает все падает и ФС разваливается |
| Автор: WolfAlone 1.7.2011, 21:14 |
| gcc, благодарю за информацию! Обязательно учту этот момент! |
| Автор: WolfAlone 2.7.2011, 01:35 |
| LSD, хотелось бы услышать Ваши рекомендации по приведённому выше случаю. Какой сервер БД лучше использовать? Стоит ли хранить данные в БД если текст занимает не более 100Кб, а изображения не более 10Мб на 1 строку (запись)? P.S. Всех благодарю за внимание. Так же, буду благодарен за любую информацию и личный опыт касательно выше приведённого случая. |
| Автор: LSD 4.7.2011, 10:39 | ||
BLOB удобен тем, что оне хранится в БД и при правильном использовании (транзакции, ссылочная целостность и т.д.), у тебя всегда будут согласованные данные. У тебя не будет ситуации когда в БД есть запись, а на диске его нет. Или наоборот, в БД запись удалили, а файл остался и занимает место. С другой стороны файлы гораздо производительней, чем BLOB поля. Я так понимаю у тебя будет некий сайт с объявлениями и фотографии нужно будет показывать на веб страничке, так? Мне кажется, что СУБД сама по себе не справится с такой нагрузкой. Вернее конечно она может справится, но это будет непропорционально затратам на тюнинг и железо для СУБД. С помощью файлов эта задача решается гораздо проще, да и отдачей фалов клиенту будет заниматься веб сервер, не дергая СУБД. С другой стороны если у тебя между базой и веб сервером есть прослойка кеширующих in memory database, то тут можно картинки и в BLOB писать, главное чтобы хватило памяти. |
| Автор: WolfAlone 6.7.2011, 03:47 |
| LSD, спасибо большое! Вопрос на данный момент решил так: 1. Мелки картинки (до 100Кб./1шт.), в не очень большом количестве (ориентировочно до 1тыс. записей, максимально, реально - порядка 50 записей) - засовываю в БД, что бы сохранить целостность данных 2. Картинки побольше (все остальные) - раскладываю по файловой системе *частичто, такому решению поспособствовало то, что статику будет отдавать nginx, и дабы он "не простаивал напрасно"... |
| Автор: WolfAlone 6.7.2011, 19:00 |
| Остался пожалуй единственный вопрос по этому поводу. Возможно кто-то проводил эксперименты над БД, со стандартными настройками (без "тюнинга")? Интересует примерная цифра потери производителности при записи данных в BLOB-поля и "доставанию" их оттуда с последующей отдачей через серверный скрипт, с такой же отдачей файла, но не из BLOB-поля, а непосредственно через сам веб-сервер? Интересует примерный % потери производительности, с учётом того, что БД и Веб-сервер находятся на одной и той же машине (то есть, время на сетевой трафик - минимально). Конкретно, интересуют следующие БД:
|
| Автор: LSD 6.7.2011, 19:05 |
| Эксперимент не проводил, но по моим ощущениям речь идет не о процентах, а о разах. |
| Автор: WolfAlone 6.7.2011, 19:07 |
| LSD, Ещё раз спасибо Вам большое! P.S. Никак не могу поставить "+" (пишет, что сутки ещё не прошли). |
