asterisk.ru

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

Так покажи плеер, который блоками с FAT'а по HTTP читает ! Рассекреть его имя, и мы снова посмеемся все вместе

стандартный веб сервер ( пусть будет апач ) с поддержкой Range request + любой вменяемый плеер ( пусть будет JW ).

нее ?

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

Не. JW использует range request для быстрого seek'а внутри файла (перемотки), но блоками не читает. Так что тут мимо кассы. А конкретно для этой задачи я уже описал достоинства хранения в базе, см. выше - и ФС вариант сливает, как свитч

Sfinx писал(а):JW использует range request для быстрого seek'а внутри файла (перемотки)

Ну воспользуйтесь seek'ом в блоб из БД для перемотки. Вы ж все-таки звуковой файл планируете писать в БД.

Короче все это уже оффтопик, к общему мнению не придем ибо его нет.
Конечно можно картинки и звуковые файлы хранить в БД, кто ж спорит, вопрос в целесообразности и производительности (БД работает поверх ФС, за исключением больших БД, которые работают с RAW-девайсами), а тот же nginx отлично справляется со статикой и т.д.
Это такой современный способ программирования, когда оптимизацию решают за счет увеличения мощности сервера.
Накопал тут пару ссылок на данную тему. Каждый в них найдет что-то интересное для себя и сможет сделать необходимые выводы.
Лично я не имею проектов и не вижу в данном топике проектов, где бы было хранения двоичных файлов оправдано в БД, а не на ФС.
Вот ссылки:
http://www.linux.org.ru/forum/web-development/7466419
http://technet.microsoft.com/ru-ru/libr ... 14%29.aspx

Ох нифига себе флудодром.
Вообще, в Базе данных обычно хранят данные, а в файловой системе - файлы.

Кстати, retch_row обязан выдать весь blob целиком, а не подкачивать его по мере надобности из бд.
Т.е. если мы хотим высрать в браузер/плеер клиента - то весь контент попадет в память/swap.

В случае файла тот же nging этим методом: http://linux.die.net/man/2/sendfile свяжет пару сокетов и будет курить в сторонке.

Sfinx писал(а): Блочная передача по HTTP - это я поржал ... очередная бредятина. Хе-хе, где же ты там блоки в HTTP нашел ? Так же следует знать что любой плейер, перед тем как проиграть файл читает его полностью, так что - будем мы его передавать блоками (гы-гы по HTTP), попугаями или еще как - это все равно, так как его нужно будет передать целиком и полностью.

Я упомянул про смещения и вот это превратилось в блоки что уже неправильно понимают.
Sfinx, http поддерживает получение данных по смещению и сомневаюсь что вам это не известно. И плееры да, запрашивают файл целиком, но если кликнуть в тот кусок файла который не докачался плеер делает новый запрос уже со смещением. Что бы поставить точку в http и смещении, могу это легко продемонстрировать. Простенькая страничка использующая тег audio Вот что мы получаем когда пытаемся проиграть файл И вот что получаем когда хотим перематать на недокаченный кусок А вот критично это или нет уже хз, этот файл у меня скачался за 1,5 мин и он длительностью 1ч, но файл mp3. mp3 записи обычно весят немного и вероятно когда пользователь решит перемотать нужный кусок уже будет скачен. Вобщем о5 всё зависит от ситуации.

tma писал(а): Вот ссылки:
http://www.linux.org.ru/forum/web-development/7466419
http://technet.microsoft.com/ru-ru/libr ... 14%29.aspx

tma Да да, я уже выше давал ссылки на microsoft filestream. Это может стать золотой серединой.

HTML5 плеер как и JW использует range request - это давно не Америка и к теме отношения никакого не имеет, так эта фишка работает только при перемотке. Мне не известен плеер, который работает блоками - посему и был вопрос в лоб - ответа нет, и думаю не будет. А если файл всегда качается целиком (а это нужно как минимум для того чтобы плеер мог знать его длительность и нарисовать time bar) - то все разговоры о блочной передаче и ее сомнительной эффективности идут в (|) (кстати не помешал бы соотв. смайлик !). Насчет BLOB'в и полной загрузки в память - это верно не для всех баз. Есть базы которые по fetch_row получают только id блоба, и уже специальная f() по blob_id возвращает данные, причем с заданной длиной и смещением. Но это опять же - до спины, так как файл плеером все равно качается полностью.
Разумеется есть много задач, где нецелесообразно хранить audio данные в таблице - но эта конкретная - не одна из них. Также следует учесть, что базы сейчас уже не те, что 10 лет назад - есть к примеру одна GPL'ная, по сравнению с которой оракл нервно курит в сторонке.
И напоследок могу подчеркнуть, что большинство из вас никогда не работало с кластерами (бред от свитча не в счет). Задача бэкапа или даже тупого получения списка audio файлов одного ебонента становится невыполнимой , если их хранить на ФС, так как в любой момент любой из backend'ов может склеить ласты.

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

Sfinx, не порите чушь, про чтение файла целиком чтоб размер узнать, сойдете за умного.

вот первая попавшаяся фигня из логов которая просит первые 2 байта, чтоб размер узнать - AppleCoreMedia/1.0.0.10B146 (iPad; U; CPU OS 6_1_2 like Mac OS X; en_us)

P.S. пользуем mogileFS, в базе мета и ссылка на ноды с файлами ( 2-3 кратная избыточность, в зависимости от типа файлов ), голоса около 100 терабайт и как то ласты не склеивает.