Хранение аватарочек

ФС, конечное же.

ФС. Потом можно будет вынести на отдельный сервер или сервис, например. К тому же в базе они не нужны, достаточно хранить путь/адрес.

К тому же в базе они не нужны, достаточно хранить путь/адрес.

тогда еще пара вопросов:

1) мне тут рубисты на рельсах подсказывают что у них в рубях есть такой модуль, который фоточки конвертит и хранением занимается, в жанге нету такого 1.а) ежели чего-то подобного нет, то хранить в одном каталоге или для каждого пользователя отдельный создавать 2) сам сайтик - мой диплом, поэтому на вопрос «а как же целостность данных?», который непременно задаст комиссия, мне придется ответить. Так вот, как же целостность данных?

http://www.djangopackages.com/grids/g/thumbnails/ Создавать при аплоаде ничего не надо filestorage сам это все должен разруливать.

Грубо говоря, хранением занимается ImageField. Про конвертирование уже написали. Я пока использую у себя sorl-thumbnail. Удобно и быстро, особенно если есть redis или memcache.

На самом деле вопрос не из простых: для ненагруженных проектов - ФС, однозначно. Уж хотя бы потому, что геморра будет меньше. А вот для нагруженных - очень возможно, что оптимизированная БД покажет лучшую производительность. На самом деле это сильно зависит от задачи.

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

Кроме того, не стоит забывать и о модели доступа: в СУБД можно сказать «ис каропки» конкурентный доступ и транзактивность операций. Кроме того, есть еще и бонус нативной репликации данных.

А вообще, я бы на Вашем месте сделал нагрузочный тест на типовую задачу и посмотрел на результат.

На самом деле вопрос не из простых: для ненагруженных проектов - ФС, однозначно. Уж хотя бы потому, что геморра будет меньше. А вот для нагруженных - очень возможно, что оптимизированная БД покажет лучшую производительность. На самом деле это сильно зависит от задачи.

толсто. ФС не оптимизированная БД?

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

открою страшную тайну, есть sendfile

А вообще, я бы на Вашем месте сделал нагрузочный тест на типовую задачу и посмотрел на результат.

на твоем месте лучше полистать топики в этой ветке.

А вот для нагруженных - очень возможно, что оптимизированная БД покажет лучшую производительность

никакой сколь-нибудь серьезной нагруженности пока не предвидится, так что ФС

Прежде чем писать, лучше ознакомиться с предметом. Да, хотя бы, посмотри как отдают статику всякие известные социалочки.

храни аватарки в социальных сетях и граватаре

Ну, чего ты удаляешь сообщения, пока писал всё дропнул.
Так ФС ничего не ломает, ну расскидай аватарки по n сервакам исходя из деления id пользователя на n. Потом можно потихоньку впихивать новые сервкаки, достраивая дерево. Разве нет?

Хранение фотографий

Сначала сделали это просто:

• Загрузка на сервер: приложение принимает изображение, создает миниатюры в нужных разрешениях, сохраняет в NFS
• Загрузка с сервера: изображения отдаются из NFS через HTTP
• NFS построена на коммерческих продуктах
• Это было необходимо, чтобы сначала проверить, что продукт востребован пользователями и они правда будут активно загружать фотографии
• На самом деле оказалось, что:
  • Файловые системы непригодны для работы с большим количеством небольших файлов
  • Метаданные не помещаются в оперативную память, что приводит к дополнительным обращениям к дисковой подсистеме
  • Ограничивающим фактором является ввод-вывод, а не плотность хранения

Потом начали оптимизировать:

* Кэширование более часто используемых миниатюр изображений в памяти на оригинальных серверах для масштабируемости, надежности и производительности * Распределение их по CDN для уменьшения сетевых задержек * Возможно сделать еще лучше: o Хранение изображений в больших бинарных файлах (blob) o Сервис, отвечающий за фотографии имеет информацию о том, в каком файле и с каким отступом от начала расположена каждая фотография (по ее идентификатору) o Этот сервис в Facebook называется Haystack и он оказался в 10 раз эффективнее «простого» подхода и в 3 раза эффективнее «оптимизированного»

http://masterpro.ws/forum/18-obo-vsem-kurilka/616-kak-ustroeny-facebook-i-vko...

Хранение аватарочек (комментарий)

Кроме того, не стоит забывать и о модели доступа: в СУБД можно сказать «ис каропки» конкурентный доступ и транзактивность операций. Кроме того, есть еще и бонус нативной репликации данных.

ага, у тебя два юзера совместно юзают одну аватарку? Меняют её постоянно? Проблему репликации для аватарок легко решает rsync, и проблему доступа ФС решит быстрее и лучше любой БД.

На самом деле - нет. Узкое место в подсистеме ввода-вывода и в мета.

Первая (ввод-вывод) является узким местом, поскольку при большом количестве файлов операции открытия/закрытия начинают сильно замедлять процесс. А у СУБД этих операций нет, и тут налицо выигрыш. Вторая (мета) является узким местом, по причине фиксированного (и очень небольшого) размера в практически во всех ФС. У СУБД с этим проблем нет опять же.

Поэтому при наличии хотя бы трех-четырех миллионов небольших файлов с большим мета их хранение в СУБД в целом будет более выгодным, чем их хранение в ФС. И это вне зависимости от количества серверов определенных под эту задачу.

Кроме того есть еще и закачка. А тут все совсем весело. Тот же nginx (я особенно с ним дружен) сперва заливает файл во временный каталог, а потом перемещает на постоянное место хранения. То есть выполняет (в смысле файловых операций) двойную работу.

Да действительно специально обученый демон отдающий фотку из блоба по смещению и mysql это одно и тоже.

Ну так я и написал что «для ненагруженных проектов - ФС, однозначно». В чем претензии-то?

Берем NoSQL СУБД и получаем почти тоже самое но без «специализированного демона». Не?

Первая (ввод-вывод) является узким местом, поскольку при большом количестве файлов операции открытия/закрытия начинают сильно замедлять процесс. А у СУБД этих операций нет, и тут налицо выигрыш. Вторая (мета) является узким местом, по причине фиксированного (и очень небольшого) размера в практически во всех ФС. У СУБД с этим проблем нет опять же.

у СУБД есть операция поиска по индексу. Конечно, если у тебя есть 100500 Гб памяти(RAM), то это не проблема, но у меня таких серверов нет. Потому БД лежит в памяти частично, а основная часть в ФС.

Про какую-то мету для аватарок я тупо не понял. Ты про что?

Поэтому при наличии хотя бы трех-четырех миллионов небольших файлов с большим мета их хранение в СУБД в целом будет более выгодным, чем их хранение в ФС. И это вне зависимости от количества серверов определенных под эту задачу.

не очевидно.

Кроме того есть еще и закачка.

по барабану. закачка это 0.00000000001% времени, пусть она хоть трижды дольше. Это, блин, аватарки, а не фотки, которые никто не смотрит кроме аффтора.

Ну так я и написал что «для ненагруженных проектов - ФС, однозначно». В чем претензии-то?

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

Ну в оп посте помоему достаточно прозрачно написано mysql или фс. Хотя кто больше сожрет памяти монга с gridfs или метаданные фс вопрос интересный.

Возможно вам пригодится вот эта идея

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

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

Тут еще дело не только в том, как мы храним, но и как отдаем. С фс модно nginx-ом отдавать напрямую.

k0valenk0_igor правильно написал. Если файлов аватарок много (1.000.000+), то я бы хранил их в базе. Так и следить за файловой системой проще и нагрузка на нее будет меньше, да и поиск по индексу в бд быстрее, чем поиск файла в древовидной структуре фс. Масштабировать опять же будет удобней и безопасней (можно использовать средства субд). Короче, если предполагается хоть какая-то работа кроме «хранить, отдавать», то бд будет удобней (и, весьма вероятно, быстрее).

Если стандартными средствами БД то отдавать картинки будет более затратно чем тем же nginx-ом.

Если стандартными средствами БД то отдавать картинки будет более затратно чем тем же nginx-ом.

Это так. Но зато БД может обеспечить автоматическую репликацию, лёгкое масштабирование и удобную чистку кешей. Так что вопрос не однозначный и зависит от конкретных условий задачи.