Хранение бинарных данных (не картинок) на сервере
netremo
встала проблема сохранение файлов (офисные) на сервере. Подскажите в
какую сторону почитать и что использовать. Как хранить данные - в
файловой системе или в БД. Сейчас проект использует mysql.
Спасибо.
Artiom Diomin
В Чтв, 25/06/2009 в 00:47 -0700, netremo пишет:
> --
> Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
> FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
>
> Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
> ror...@googlegroups.com
> Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-un...@googlegroups.com
> Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru
> -~----------~----~----~----~------~----~------~--~---
>
--
Artiom Diomin
Jabber/Gtalk: kr...@linux.md
Maxim Kulkin
картинок)" осуществляется точно так же,
как и "бинарных данных (картинок)".
Dieinzige
Я лично больше у хранения в фс вижу)
On 25 июн, 12:00, Artiom Diomin <kro...@gmail.com> wrote:
> ФС, однозначно, а в БД путь до файла
>
> В Чтв, 25/06/2009 в 00:47 -0700, netremo пишет:
>
> > Товарищи ещё один вопросик. Я недавно начал использовать рельсы. Тут
> > встала проблема сохранение файлов (офисные) на сервере. Подскажите в
> > какую сторону почитать и что использовать. Как хранить данные - в
> > файловой системе или в БД. Сейчас проект использует mysql.
>
> > Спасибо.
> > >
> --
> Artiom Diomin
>
> Jabber/Gtalk: k...@linux.md
>
> signature.asc
> < 1KбПросмотретьЗагрузить
Dieinzige
Max Lapshin
> *больше минусов.
>
Так когда приходит по 4 клиента в час, но жутко хитрая схема
авторизации, секурности, высокие требования по безопасности и
сохранности данных, многие используют блобы в БД. Всяко для DBA
дополнительный кускок хлеба.
Но когда возникает хотя бы 10 тыс хитов в день, хранить файлы в БД
становится не то что неудобным, а попросту невозможным.
Файл с диска отдается default веб-сервером многократно быстрее потому
что sendfile.
Dieinzige
я конечно пришел из мира ентерпарйза)
и только только по настоящему втягиваюсь в руби - сообщество.
но всеж такой вопрос..
10тыс хитов в день..пускай в первую половину дня для более
реалистичности..
получается что один клиент в 5 секунд....ну я конечно понимаю, пиковые
не учитываю, и все это на воде писано...но имхо маленькая нагрузка.
что касается sendfile , конечно я согласен., и да, я не спорю что
записать на диск и кинуть ссылку в базу, быстрее...просто по моему
опыту работы с j2контенейнерами, которые под собой тоже тянут апач
(WAS), существенной разницы в скорости видеть не приходилось..
А вот проблем, с целостностью и политиками безопасности да(((
Dieinzige
есстественно все зависит от проекта...)
Max Lapshin
> Максим..
> я конечно пришел из мира ентерпарйза)
> и только только по настоящему втягиваюсь в руби - сообщество.
> но всеж такой вопрос..
> 10тыс хитов в день..пускай в первую половину дня для более
> реалистичности..
> получается что один клиент в 5 секунд....ну я конечно понимаю, пиковые
> не учитываю, и все это на воде писано...но имхо маленькая нагрузка.
Вот в этом и есть разница между длинными транзакциями в больших
приложениях на 1000 клиентов и
веб-сайтами. Эти 10 тысяч приходят пиково, создавая даже на сетевой
интерфейс существенную нагрузку.
В энтерпрайзе не приходится отдавать сотни картинок на страницу,
скорее кучу данных ворошить.
Когда файлы хранятся в БД, их чертовски сложно обрабатывать
ImageMagick-ом (стандартом де-факто в рельсах),
их неудобно кешировать на промежуточном CDN, их нельзя архивировать
средствами бекапа файлов.
А то, что не видел разницу между отдачей через апач и nginx — многое
объясняет =) Разница там действительно огромная.
Dieinzige
(Когда файлы хранятся в БД, их чертовски сложно обрабатывать
ImageMagick-ом (стандартом де-факто в рельсах),
их неудобно кешировать на промежуточном CDN, их нельзя архивировать
тут такой вопрос...
не лучше ли единоразово обработать imageMagick-ом картинку,и сложить
ее, ( а там в базу или на фс уже без раницы),и затем так же вытягивать
уже измененные данные.
если не правильно тебя понял опять ж сори, потому - что работа с
rmagic-ом еще впереди.)
неудобно кешировать на промежуточном CDN -тут спорный вопрос о
трудозатратах на ссылку на промежуточный CDN картинок. или бд куда
будем периодечески все стягивать...хотя это опять же некоторые
сложности..так что повторюсь довольно спорно имхо.
>>их нельзя архивировать средствами..
средствами субд все довольно просто становится.
а оракля вообще сладкие фишки дает)
Alex Dmitriev
Хранение файлов в файловой системе нужно для того, чтобы быстро отдавать статику, нормально делать бэкапы, организовать кэширование на CDN и клиенте, а так же масштабировать хранилище с минимумом вмешательства непосредственно в код проекта. Делать то же самое при хранении файлов в БД будет проблематично.
--
Alex V. Dmitriev
Skype: rene-dekart
MSN/AIM/Jabber/GTalk: rene....@gmail.com
Blog: http://railorz.ru
Dieinzige
Организовать простейший документо оборот , в рамках чего то
абстрактного.
достаточно широкая правовая система..
будите хранить на фс?)
<<
нормально делать бэкапы, организовать кэширование на клиенте,
а так же масштабировать хранилище с минимумом вмешательства
непосредственно
в код проекта.
>>
On 7 июл, 13:12, Alex Dmitriev <rene.dek...@gmail.com> wrote:
> Вы можете сказать, зачем КОНКРЕТНО вам хранить файлы в БД? То, что так
> делать можно, не значит что так делать нужно. Особенно в контексте
> веб-проекта, где юзеры за одну сессию могут просматривать сотни файлов.
>
> Хранение файлов в файловой системе нужно для того, чтобы быстро отдавать
> статику, нормально делать бэкапы, организовать кэширование на CDN и клиенте,
> а так же масштабировать хранилище с минимумом вмешательства непосредственно
> в код проекта. Делать то же самое при хранении файлов в БД будет
> проблематично.
>
> 7 июля 2009 г. 14:13 пользователь Dieinzige <dieinz...@googlemail.com>написал:
>
>
>
> > Да соглашусь со всем окоромя :
> > (Когда файлы хранятся в БД, их чертовски сложно обрабатывать
> > ImageMagick-ом (стандартом де-факто в рельсах),
> > их неудобно кешировать на промежуточном CDN, их нельзя архивировать
> > средствами бекапа файлов. )
> > тут такой вопрос...
> > не лучше ли единоразово обработать imageMagick-ом картинку,и сложить
> > ее, ( а там в базу или на фс уже без раницы),и затем так же вытягивать
> > уже измененные данные.
> > если не правильно тебя понял опять ж сори, потому - что работа с
> > rmagic-ом еще впереди.)
> > неудобно кешировать на промежуточном CDN -тут спорный вопрос о
> > трудозатратах на ссылку на промежуточный CDN картинок. или бд куда
> > будем периодечески все стягивать...хотя это опять же некоторые
> > сложности..так что повторюсь довольно спорно имхо.
> > >>их нельзя архивировать средствами..
> > средствами субд все довольно просто становится.
> > а оракля вообще сладкие фишки дает)
>
> --
> Alex V. Dmitriev
> Skype: rene-dekart
> MSN/AIM/Jabber/GTalk: rene.dek...@gmail.com
> Blog:http://railorz.ru
Alex Dmitriev
ну допустим пример:
Организовать простейший документо оборот , в рамках чего то
абстрактного.
достаточно широкая правовая система..
будите хранить на фс?)
Да, конечно. А почему нет?
<<
нормально делать бэкапы, организовать кэширование на клиенте,
а так же масштабировать хранилище с минимумом вмешательстваАргументы,)
непосредственно
в код проекта.
>>
к чему конкретно?
--
Alex V. Dmitriev
Skype: rene-dekart
Blog: http://railorz.ru
Max Lapshin
>
>
> 7 июля 2009 г. 15:30 пользователь Dieinzige <diei...@googlemail.com>
> написал:
>>
>> ну допустим пример:
>> Организовать простейший документо оборот , в рамках чего то
>> абстрактного.
>> достаточно широкая правовая система..
>> будите хранить на фс?)
>
> Да, конечно. А почему нет?
>
Алексей, потому что в случаях тяжелого документооборота файловая
система — лишняя
и ненужная точка сбоя. Оракловый админ справится с бекапом данных, а вот
двух админов (ораклового и обычного) уже стыковать очень дорого.
Alex Dmitriev
Ммм, окей :) Но речь-то идет о простейшей системе документооборота на MySQL (см. первый пост). Так или иначе, опыта с документооборотом у меня не много, поэтому не буду настаивать.
Max Lapshin
> проекте файлы предполагается хранить в БД. Наличие в базах данных поддержки
> BLOB-полей - не достаточная причина, на мой взгляд, надо что-то посерьезнее.
>
Я бы сказал, что скорее наличие BLOB-ов — следствие того периода в
индустрии, во время
которого БД считалась хорошим сервером приложений с унифицированным
SQL интерфейсом.
Соответственно, где же ещё хранить файлы, как не в таком хранилище.
Мне к счастью ни разу не приходилось иметь дела с системами, где файлы
хранятся в БД.
Dieinzige
инструментарий,)
>>Наличие в базах данных поддержки
>>BLOB-полей - не достаточная причина, на мой взгляд, надо что-то посерьезнее.
Что оракля, что mssql поддерживаю file-link типы, по сути это хранение
файла непостредственно на фс, с доступным линком,а в как таковом парт-
значении,будет хранится ссылка.
по сути получаем все плюсы базы данных, и минусы связанные с некоторой
некошерностью тоже исчезают, а насчет же напрямую отдать ссылку на
файл..тут сказать не могу(это к вопросу о производительности отдачи
картинок).
__ <- написал по памяти то что когда-то читалось нам =) самому в пром-
производстве данный т не приходилось применять.
On 7 июл, 14:13, Alex Dmitriev <rene.dek...@gmail.com> wrote:
> 7 июля 2009 г. 16:04 пользователь Max Lapshin <max.laps...@gmail.com>написал:
>
>
>
> > 2009/7/7 Alex Dmitriev <rene.dek...@gmail.com>:
>
> > > 7 июля 2009 г. 15:30 пользователь Dieinzige <dieinz...@googlemail.com>
> > > написал:
>
> > >> ну допустим пример:
> > >> Организовать простейший документо оборот , в рамках чего то
> > >> абстрактного.
> > >> достаточно широкая правовая система..
> > >> будите хранить на фс?)
>
> > > Да, конечно. А почему нет?
>
> > Алексей, потому что в случаях тяжелого документооборота файловая
> > система -- лишняя
> > и ненужная точка сбоя. Оракловый админ справится с бекапом данных, а вот
> > двух админов (ораклового и обычного) уже стыковать очень дорого.
>
> Ммм, окей :) Но речь-то идет о простейшей системе документооборота на MySQL
> (см. первый пост). Так или иначе, опыта с документооборотом у меня не много,
> поэтому не буду настаивать.
>
> В любом случае, нужно четко осознавать, по какой причине в конкретном
> проекте файлы предполагается хранить в БД. Наличие в базах данных поддержки
> BLOB-полей - не достаточная причина, на мой взгляд, надо что-то посерьезнее.
>
> --
> Alex V. Dmitriev
> Skype: rene-dekart
> MSN/AIM/Jabber/GTalk: rene.dek...@gmail.com
> Blog:http://railorz.ru
Val
на CDN и клиенте" мало зависит от того где хранятся файлы, в обоих
случаях это просто правильное выставление заголовков (Last-Modified/
Cache-Control/Expires/etc) в случае pull-through или забрасывание
файла на CDN, если push.
On Jul 7, 5:12 am, Alex Dmitriev <rene.dek...@gmail.com> wrote:
> Вы можете сказать, зачем КОНКРЕТНО вам хранить файлы в БД? То, что так
> делать можно, не значит что так делать нужно. Особенно в контексте
> веб-проекта, где юзеры за одну сессию могут просматривать сотни файлов.
>
> Хранение файлов в файловой системе нужно для того, чтобы быстро отдавать
> статику, нормально делать бэкапы, организовать кэширование на CDN и клиенте,
> а так же масштабировать хранилище с минимумом вмешательства непосредственно
> в код проекта. Делать то же самое при хранении файлов в БД будет
> проблематично.
>
> 7 июля 2009 г. 14:13 пользователь Dieinzige <dieinz...@googlemail.com>написал:
>
>
>
> > Да соглашусь со всем окоромя :
> > (Когда файлы хранятся в БД, их чертовски сложно обрабатывать
> > ImageMagick-ом (стандартом де-факто в рельсах),
> > их неудобно кешировать на промежуточном CDN, их нельзя архивировать
> > средствами бекапа файлов. )
> > тут такой вопрос...
> > не лучше ли единоразово обработать imageMagick-ом картинку,и сложить
> > ее, ( а там в базу или на фс уже без раницы),и затем так же вытягивать
> > уже измененные данные.
> > если не правильно тебя понял опять ж сори, потому - что работа с
> > rmagic-ом еще впереди.)
> > неудобно кешировать на промежуточном CDN -тут спорный вопрос о
> > трудозатратах на ссылку на промежуточный CDN картинок. или бд куда
> > будем периодечески все стягивать...хотя это опять же некоторые
> > сложности..так что повторюсь довольно спорно имхо.
> > >>их нельзя архивировать средствами..
> > средствами субд все довольно просто становится.
> > а оракля вообще сладкие фишки дает)
>
> --
> Alex V. Dmitriev
> Skype: rene-dekart
> MSN/AIM/Jabber/GTalk: rene.dek...@gmail.com
> Blog:http://railorz.ru
Julik Tarkhanov
On 07 Jul 2009, at 08:50, Dieinzige wrote:
> *больше минусов.
Минус один - кода больше писать. Все
остальное как не посмотри - плюсы.
--
Julik Tarkhanov
m...@julik.nl
Vitaly Kushner
* хранить в бд + кэш в фс при первом использовании (и.е. если есть в
фс - юзай, если нет - запиши и юзай :) плюсы - нужно толко бэкапить
бд. файлы мозно игнорировать, всё равно порекэшируются при первом
исползовании.
* Amazon S3?
Julik Tarkhanov
On 07 Jul 2009, at 17:27, Vitaly Kushner wrote:
> плюсы - нужно толко бэкапить
> бд. файлы
терабайта, и никто не знает как это
произошло и как ее собсна при таком
раскладе бекапить (каждый блок таблиц
на отдельный диск? таром?),
из базы получается терабайтный же дамп
в котором пойди загрепь чего-нибудь в
случае нужды,
потом у базы берет и разрастается
время поиска (страшным образом) потому
что с блобами они работает
неэффективно. Ну и на десерт ActiveRecord
берет и при select * селектит
500 блобов по 10 мегабайт. В память.
Ребят, ну хватит уже. Дамп базы + rsync,
дешево и сердито. Даже версионирование
теперь (при помощи всяких гитов) легче
делать вне базы.
--
Julik Tarkhanov
m...@julik.nl
Dieinzige
поучиться, как максимум голову снести.
терабайтный дамп, сори но так бекапы не делаются=)
не знаю что такое загрель, по этому сложно ответить.
>>
потом у базы берет и разрастается
время поиска (страшным образом) потому
что с блобами они работает
неэффективно.
Ну и на десерт ActiveRecord
берет и при select * селектит
500 блобов по 10 мегабайт. В память.
Julik Tarkhanov
On 07 Jul 2009, at 19:08, Dieinzige wrote:
> за select * from * вообще руки надо отрывать)
активрекордов. Да и за руби тоже
оторвать надо бы. Флейм окончен.
--
Julik Tarkhanov
m...@julik.nl
Dieinzige
...
А ваша агрессия мне не понятна)
Julik Tarkhanov
On 07 Jul 2009, at 19:44, Dieinzige wrote:
> А ваша агрессия мне не понятна)
совершенно не нов и по целому ряду
причин файлам место именно в файловой
системе. К этому пришли многие,
приходят и будут приходить. Отсутствие
в рельсах со времен FileCOlumn приличной
вязалки "файл-база-форма" excuse-ом не
является
--
Julik Tarkhanov
m...@julik.nl
Dieinzige
и то к чему приходят и будут приходить к тому , что для каждой задачи
по своему организуется хранилище.
я по прежнему убежден что хранение файлов в бд дает большее число
плюсов чем минусов.
Возникает вопрос в производительности при отдаче картиники, думаю
вариант предложенный Виталием(последний вариант в этом топике) ,
достаточно решит данную проблему.
Alexey Kovyrin
> терабайтный дамп, сори но так бекапы не делаются=)
А как делаются бекапы 100-гигабайтного (500гб, терабайтного, етс -
размер не важен, главное, что с картинками внутри он капец насколько
больше обычного будет) мускуля?
З.Ы. Да, я считаю что файлам в __мускуле__ не место (по крайней мере
пока PBXT с их стримингом не допилят) и да - бекапы это одна из двух
главных причин (вторая - скорость отдачи, но там еще можно спорить).
--
Alexey Kovyrin
http://kovyrin.info/
Max Lapshin
> Ну я думаю вы ошибаетесь..
> и то к чему приходят и будут приходить к тому , что для каждой задачи
> по своему организуется хранилище.
> я по прежнему убежден что хранение файлов в бд дает большее число
> плюсов чем минусов.
> Возникает вопрос в производительности при отдаче картиники, думаю
> вариант предложенный Виталием(последний вариант в этом топике) ,
> достаточно решит данную проблему.
Да пользуйтесь на здоровье и ощущайте себя первопроходцем при использовании
файлов в БД с рельсами =)
Роман Смирнов
плюсов чем минусов.<
веб-проектов(а все остальные контексты в этой группе оффтопик, ибо к
RoR отношения не имеют).
И вот как раз в контексте веб-проектов, разработчику нужно руки
отрывать, если он хранит файлы в БД.
7 июля 2009 г. 22:05 пользователь Dieinzige (diei...@googlemail.com) написал:
Nikolay Grebnev
настоящие пацаны используют hadoop и другие подобные системы .
Alexey Kovyrin
latency у хадупа/хбейса/етс не годится никуда.
2009/7/7 Nikolay Grebnev <nikolay...@gmail.com>:
--
Alexey Kovyrin
http://kovyrin.info/
Max Lapshin
> Это тока те пацаны, у которых есть бигтейбл, а остальные не могут -
> latency у хадупа/хбейса/етс не годится никуда.
>
Угу. Как говорит мой коллега, иногда не масштабироваться — работать надо.
Nikolay Grebnev
Сейчас есть более срочные дела, а потом займусь - привез для этого на дачу 4 сервака....
Artiom Diomin
проект. В случае если пишется торрент трекер.
Содержимое торрент файла хранить в БД. Это может понадобиться если
например каждому клиенту отдавать торрент файл с чуть изменённым
announce url (с персональным pass_key-ем, актуально на "злых" трекерах)
Хранить можно уже в bencode-ном виде (палюбому там получается просто
Hash) так что пускай AR этот хэш сериализует себе на здоровье.
В Чтв, 25/06/2009 в 00:47 -0700, netremo пишет: