Где хранить изображения: база данных vs файловая система(холивар)

А можно пруф?

http://www.insight-it.ru/masshtabiruemost/arkhitektura-vkontakte/

Интересные факты не по теме
* Фотографии загружаются на два жестких диска одного сервера одновременно, после чего создается резервная копия на другом сервере
* Фотографии не удаляются для минимизации фрагментации

Тоесть по твоему в треде есть верующие в бд которые могут удобно шардиться и бекапиться на таком объеме файлов?

Нет.

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

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

Всегда ФС. Всегда ваш КО.

И да, ФС это тоже БД если чё

Чем обоснуете? Есть какие-то тесты, показывающие явное превосходство ФС над базой? Мне, например, не очевидно. Хранить файлы в базе на порядок удобнее для программиста.

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

Да они особо тормозить все не будет. Ключевое слово - особо. Мы в highload вообще базу не используем, только на холодном старте. Далее файлы + no-sql (key-value store фактически) с линейным масштабированием.

Но что будет ТС делать, когда надо будет это раскидать на 40-50 проксей? 40-50 БД с репликой?

Да они особо тормозить все не будет.
Да ладно. Сравни сколько nginx жрет и СУБД. (А чтобы файлы отдавать я так думаю она будет жрать вообще дофига).

Мне кажется, скорость сети на порядки меньше, чем скорость оперативной памяти, поэтому напрямую брать из дискового кеша и кидать сетвому драйверу, или перед этим ещё распарсить простой запрос, понять где оно лежит, скопировать в памяти пару раз и опять же кинуть сетевому драйверу - разница будет невелика, всё упрётся в сеть. Это если картинка в кеше лежит, если она на диске лежит, то там точно пофиг.

А кеширование у БД вроде нормальное, какая разница, будет nginx кешировать, или оракл.

ну я же сказал особо. На порядок медленнее всего лишь.

/dev/da0s1a 496M 169M / devfs 1.0K 1.0K /dev /dev/da0s1d 989M 4.5M /tmp /dev/da0s1f 1.9G 338M /usr /dev/da0s1e 1.9G 289M /var /dev/da0s1g 25G 17G /usr/local /dev/da1p6.journal 1.0T 1.0T /x1 /dev/da1p7.journal 801G 786G /x2 /dev/da1p3.journal 1.0T 994G /x3 /dev/da2p3.journal 739G 688G /x4 /dev/da1p1.journal 1.0T 1.0T /x5 /dev/da1p4.journal 1.0T 1.0T /x6 /dev/da1p2.journal 1.0T 1.0T /x7 /dev/da2p2.journal 1.0T 990G /x8 /dev/da2p1.journal 1.0T 999G /x9 /dev/da1p5.journal 1.0T 423G /x10

это первое хранилище на SATA и запасные SAS во внешней полке, второе такое же, только там все разделы 1T и сейчас вот тестим 24 x 128G SSD хранилище, там пока всего может парочку T.

К бд больше обращений. Ибо надо сделать как минимум в 2 раза больше сисколов. Тем более еще надо делать переключение контекста.

Кэш для выдачи файлов nginx очень хороший. Он лучше, чем кэш bd в обработке больших блобов

Что правда в БД картинки держишь? Какую БД используешь?

Не БД, но самопальное хранилище. Разумеется не покажу, потому что галимая проприетарщина.

БД будет копировать данные в юзер спейс, а nginx использует sendfile. Это БД выигывают только местные теоретики, реально в продакшене никто под большими нагрузками не использует БД для картинок.

ну мы вообще даже как хранилище данных не используем :)

Вообще шансов у такого подхода нету. Ну мы думали о каком нить storage сетевой-кластерный. Но что-то даже анализ показывает недостаточную скорость

Обращение к фс это сискол (open), сискол(реад), сискол(clos). Обращение к базе: сискол(socket) сискол(write) В базе: { сискол(read) сискол(read) с файловой системы) сискол(wite) ) сискол(read)

Могу послать тебя к эпичному троллингу Сысоева со стороны автора gwan. Сысоев тоже удивлялся: «Как так, у меня сисколлов меньше, а qps все равно в 2 раза ниже!!1».

Итак, во-первых, на хранении фотографий дело все не в количестве сисколлов, а в позиционировании головок диска. Конечно, если у тебя фотохранилище на SSD, то ты зажравшийся буржуй и этот тред можешь вообще не читать.

Во-вторых, БД может позволить себе «экономить» сисколлы, аккумулируя данные для записи, в итоге аплоад одной фотографии не всегда выродится в немедленную последовательность write'ов.

А в-третьих, все дело в IO. Моя «БД» выигрывает в том, что: 1) запись на диск последовательная (грубо говоря, фотки пишутся одна за другой в преаллокейченное дисковое пространство) — мы уже сэкономили на позиционировании; 2) чтение — самая горячая часть всего — оно в любом случае будет рандомным. Все, что я могу обеспечить — линейность этого с помощью preallocated файла.

И чем это хуже файловой системы, в которой шмотами висят ненужные мне метаданные?

Вообще шансов у такого подхода нету. Ну мы думали о каком нить storage сетевой-кластерный. Но что-то даже анализ показывает недостаточную скорость

ну вот сейчас на SSD тестим отдачу. На чтение получается в разы больше, чем на SAS, но там соотношение запись/чтение где-то 1:500 или вообще 1000.

а что у нас кэш файловой системы отменили? и вроде в самом сервере тоже может быть кэш.

ЗЫ: у нас только чтение

давай ссылку :)

Разумеется не покажу, потому что галимая проприетарщина.

Это веб-проект?
Ссылку можно увидеть?

у нас вообще запись можно считать пренебрежимо малой. А чтение обычно на пределе возможности винтов. Но все равно ssd летят, выкидываем, ставим новые. ssd у нас не основное хранилище

Не ну понятно, что если важна скорость, то из ФС нужно отдавать картинки. Хотя бы потому, что для чтения из БД нужно поднимать тред в коде приложения, а nginx ассинхронно будет читать.

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

отлично. и при чём тут твои тибибайты фс к сабжу?

ФС ускоряет индексацию файлов? - нет!

ФС упрощает менеджмент? - нет!

ФС упрощает бэкап? - нет!

ФС - это низкий уровень, не заточенный для конкретных нужд.

Возьмём на пример MoinMoin, потому что там система основана на ФС. Да, он не плохо работает, стабильно. Но, если посмотреть на каталог со страницами, то глаза начинают кровоточить и лучше бы оно было в БД.

а от тебя я сейчас вижу только пиписькомерство и не более.

смысла в куче блобов внутри баз вроде mysql явно нет большого, т.к. банально такого типа бд проектировались изначально не для этого.

естественно что БД должна быть не SQL, а специализированная.

Дай ссылку на эту спец. БД

ФС ускоряет индексацию файлов? - нет!

что такое индексация файлов?

ФС упрощает менеджмент? - нет!

что за менеджмент? В GUI оболочке в корзинку перетащить файлик?

ФС упрощает бэкап? - нет!

для этого есть RAID контроллеры и SANы

ФС - это низкий уровень, не заточенный для конкретных нужд.

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

Возьмём на пример MoinMoin, потому что там система основана на ФС. Да, он не плохо работает, стабильно. Но, если посмотреть на каталог со страницами, то глаза начинают кровоточить и лучше бы оно было в БД.

ты о чем вообще? :) MoinMoin это простенькая реализация Wiki, а мы говорим про файлы в БД, т.е. блобы.

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

плюсую.
Но вообще подождем ссылок на эту БД.

что такое индексация файлов?

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

что за менеджмент? В GUI оболочке в корзинку перетащить файлик?

предположим, некую систему тегирования файлов - древовидная структура ФС тут очевидно не подходит. по этому, БД, решающая проблему «расположения файлов», была бы отличным решением.

для этого есть RAID контроллеры и SANы

я говорю об умышленном удалении файлов с ФС, а не об аппаратных ошибках.

блобы.

я не про блобы, а про БД заточенную под хранение бинарной информации (файлов).

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

зачем? У тебя в БД хранится id или полный путь до файла, зачем их еще индексировать?

предположим, некую систему тегирования файлов - древовидная структура ФС тут очевидно не подходит. по этому, БД, решающая проблему «расположения файлов», была бы отличным решением.

см выше.

я говорю об умышленном удалении файлов с ФС, а не об аппаратных ошибках.

а что мешает умышленно сделать DELETE через SQL-Injection или rm -rf каталога с БД?

я не про блобы, а про БД заточенную под хранение бинарной информации (файлов).

Это называется файловая система :)

Но вообще подождем ссылок на эту БД.

выше говорили: Gridfs в mongodb

её я ещё не щупал, но теоретически выглядит не плохо.

я не про блобы, а про БД заточенную под хранение бинарной информации (файлов).

Ссылку, сестра, ссылку!

выше говорили: Gridfs в mongodb

её я ещё не щупал, но теоретически выглядит не плохо.

А, так ты теоретик, ну я так и думал.

выше говорили: Gridfs в mongodb

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

её я ещё не щупал, но теоретически выглядит не плохо.

тебе уже сказали, что при достижении объема БД больше памяти и большой нагрузке твой вариант с mongodb загнется. Транзакций в ней нет, то что там называется транзакциями - костыль. Горизонтальное масштабирование из-за памяти у тебя будет постоянным.

зачем? У тебя в БД хранится id или полный путь до файла, зачем их еще индексировать?

У тебя в БД хранится

оно туда само собой сохраняется что ли? нет, оно туда сохраняется оптимизированным софтом. А я говорю про кучу файлов, для которых пути в БД ещё не хранятся.

а что мешает умышленно сделать DELETE через SQL-Injection или rm -rf каталога с БД?

во-первых, так как БД бэкапить проще, он скорее будет забэкаплен чем ФС.

а во-вторых, удаление БД будет заметно сразу и проконтролировать это проще и вред будет устранён быстрее.

Это называется файловая система

это не имеет завершённого вида.

а что у нас кэш файловой системы отменили?

На чтении кеш тебе практически не помогает: условно говоря, у тебя 100Gb данных, из которых в течение минуты случайным образом выдергиваются 100Mb. Единственное, в чем тебе поможет кеш — это при чтении «популярных» фоток. Собственно, мой вариант хранения фотографий точно так же ничем не облегчает чтение, разве что кеширование можно делать самостоятельно (избегая сисколлов и даже загрязнения кешей при использовании O_DIRECT; бонусом можно использовать AIO, но мне хватает N читающих с диска потоков)

При рандомной записи дисковый кеш в принципе не помогает. Более того, в современных ФС данные и метаданные (которые, кстати, нам нафиг не нужны) лежат в разных областях диска, так что создание 4-мегабайтного файла «больнее» для диска, чем просто запись в 8k последовательных секторов. В данном случае кеш просто позволяет твоему приложению не зависать в ожидании завершения операции записи. Мое же хранилище будет просто совершать запись в последовательные сектора на диске. Чем интенсивнее запись, тем больший выигрыш я получаю. А освободившиеся ресурсы диска идут, правильно, на чтение, которое происходит тупо быстрее, потому что опять-таки, тупо головки меньше времени бегают туда-сюда при записи.

А мои вопросы будешь игнорировать?

оно туда само собой сохраняется что ли? нет, оно туда сохраняется оптимизированным софтом. А я говорю про кучу файлов, для которых пути в БД ещё не хранятся.

это шутка? :)

во-первых, так как БД бэкапить проще, он скорее будет забэкаплен чем ФС.

а во-вторых, удаление БД будет заметно сразу и проконтролировать это проще и вред будет устранён быстрее.

Чем проще? LOL :) Если ты удалишь 10 мелких файлов или один большой, то ничего не случится с остальными. Если ты начнешь удалять и удалишь часть файла с бинарными данными БД, то ты потеряешь все.

это не имеет завершённого вида.

Дейт, ты по-русски умеешь говорить? :)

А мои вопросы будешь игнорировать?

1. Да, это веб-проект

2. Нет, ссылку на него увидеть нельзя

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

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

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

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

и да, если это будет не монго, то это будет что-то другое, но хорошо выполняющее свою задачу.

ссылку на Сысоева дай, хочется почитать где у него там qps ниже в 2 раза.

Нет, ссылку на него увидеть нельзя

никто и не сомневался.

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

У тебя nginx при отдаче статики выдавал gateway timeout?
Что за версия nginx такая?

и да, если это будет не монго, то это будет что-то другое, но хорошо выполняющее свою задачу

Ну вот когда будет, тогда и будем разговаривать.
А теоритезировать и фантазировать можно сколько угодно.

ссылку на Сысоева дай, хочется почитать где у него там qps ниже в 2 раза.

Легко! Картинка: http://nbonvin.files.wordpress.com/2011/03/avg2.png

Непосредственный комментарий: http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-serv...

У тебя nginx при отдаче статики выдавал gateway timeout?

Ну ты жжёшь! Ты вообще в курсе, что nginx не может выдать gateway timeout, если он отдает статику напрямую?

Ну ты жжёшь! Ты вообще в курсе, что nginx не может выдать gateway timeout, если он отдает статику напрямую?

Дык, это ты написал, что когда отказались от файликов, и перешли на твою закрытую супер-бд, gateway timeout пропал.

Ты наверное из тех кому табличку сарказм надо показывать.