Запись разговоров в базу mysql..
Re: Запись разговоров в базу mysql..
я предлагаю закончить этот бесмыссленный спор. Автор получил ответ на свой вопрос, каждый высказал свою точку зрения, все остались при своём.
Re: Запись разговоров в базу mysql..
Так покажи плеер, который блоками с FAT'а по HTTP читает ! Рассекреть его имя, и мы снова посмеемся все вместе 
Re: Запись разговоров в базу mysql..
стандартный веб сервер ( пусть будет апач ) с поддержкой Range request + любой вменяемый плеер ( пусть будет JW ).
нее ?
а вообще у хранения файлов в базе есть плюсы, но конкретно тут минус.
нее ?
а вообще у хранения файлов в базе есть плюсы, но конкретно тут минус.
Re: Запись разговоров в базу mysql..
Не. JW использует range request для быстрого seek'а внутри файла (перемотки), но блоками не читает. Так что тут мимо кассы. А конкретно для этой задачи я уже описал достоинства хранения в базе, см. выше - и ФС вариант сливает, как свитч
Re: Запись разговоров в базу mysql..
Ну воспользуйтесь seek'ом в блоб из БД для перемотки. Вы ж все-таки звуковой файл планируете писать в БД.Sfinx писал(а):JW использует range request для быстрого seek'а внутри файла (перемотки)
SkyTel OU - облачная АТС, DID, SIP-транк с посекундной тарификаицей, мобильная связь
http://skytel24.com | Эстония: +372.333.55.10 | Россия: +7(495)4019900
http://skytel24.com | Эстония: +372.333.55.10 | Россия: +7(495)4019900
Re: Запись разговоров в базу mysql..
Короче все это уже оффтопик, к общему мнению не придем ибо его нет.
Конечно можно картинки и звуковые файлы хранить в БД, кто ж спорит, вопрос в целесообразности и производительности (БД работает поверх ФС, за исключением больших БД, которые работают с RAW-девайсами), а тот же nginx отлично справляется со статикой и т.д.
Это такой современный способ программирования, когда оптимизацию решают за счет увеличения мощности сервера.
Накопал тут пару ссылок на данную тему. Каждый в них найдет что-то интересное для себя и сможет сделать необходимые выводы.
Лично я не имею проектов и не вижу в данном топике проектов, где бы было хранения двоичных файлов оправдано в БД, а не на ФС.
Вот ссылки:
http://www.linux.org.ru/forum/web-development/7466419
http://technet.microsoft.com/ru-ru/libr ... 14%29.aspx
Конечно можно картинки и звуковые файлы хранить в БД, кто ж спорит, вопрос в целесообразности и производительности (БД работает поверх ФС, за исключением больших БД, которые работают с RAW-девайсами), а тот же nginx отлично справляется со статикой и т.д.
Это такой современный способ программирования, когда оптимизацию решают за счет увеличения мощности сервера.
Накопал тут пару ссылок на данную тему. Каждый в них найдет что-то интересное для себя и сможет сделать необходимые выводы.
Лично я не имею проектов и не вижу в данном топике проектов, где бы было хранения двоичных файлов оправдано в БД, а не на ФС.
Вот ссылки:
http://www.linux.org.ru/forum/web-development/7466419
http://technet.microsoft.com/ru-ru/libr ... 14%29.aspx
SkyTel OU - облачная АТС, DID, SIP-транк с посекундной тарификаицей, мобильная связь
http://skytel24.com | Эстония: +372.333.55.10 | Россия: +7(495)4019900
http://skytel24.com | Эстония: +372.333.55.10 | Россия: +7(495)4019900
Re: Запись разговоров в базу mysql..
Ох нифига себе флудодром. 
Вообще, в Базе данных обычно хранят данные, а в файловой системе - файлы.
Кстати, retch_row обязан выдать весь blob целиком, а не подкачивать его по мере надобности из бд.
Т.е. если мы хотим высрать в браузер/плеер клиента - то весь контент попадет в память/swap.
В случае файла тот же nging этим методом: http://linux.die.net/man/2/sendfile свяжет пару сокетов и будет курить в сторонке.
Вообще, в Базе данных обычно хранят данные, а в файловой системе - файлы.
Кстати, retch_row обязан выдать весь blob целиком, а не подкачивать его по мере надобности из бд.
Т.е. если мы хотим высрать в браузер/плеер клиента - то весь контент попадет в память/swap.
В случае файла тот же nging этим методом: http://linux.die.net/man/2/sendfile свяжет пару сокетов и будет курить в сторонке.
Re: Запись разговоров в базу mysql..
Я упомянул про смещения и вот это превратилось в блоки что уже неправильно понимают.Sfinx писал(а): Блочная передача по HTTP - это я поржал ... очередная бредятина. Хе-хе, где же ты там блоки в HTTP нашел ? Так же следует знать что любой плейер, перед тем как проиграть файл читает его полностью, так что - будем мы его передавать блоками (гы-гы по HTTP), попугаями или еще как - это все равно, так как его нужно будет передать целиком и полностью.
Sfinx, http поддерживает получение данных по смещению и сомневаюсь что вам это не известно. И плееры да, запрашивают файл целиком, но если кликнуть в тот кусок файла который не докачался плеер делает новый запрос уже со смещением. Что бы поставить точку в http и смещении, могу это легко продемонстрировать. Простенькая страничка использующая тег audio
Код: Выделить всё
<html>
<body>
<audio controls="true" id="player" src="http://production.mediajoint.prx.org.s3.amazonaws.com/public/audio_files/16671/01_Radio_Special_broadcast.mp3">..
Your browser does not support the <code>audio</code> element...
</audio>
</body>
</html>
Код: Выделить всё
GET /public/audio_files/16671/01_Radio_Special_broadcast.mp3 HTTP/1.1
Host: production.mediajoint.prx.org.s3.amazonaws.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
.........................
Range: bytes=0-
Код: Выделить всё
GET /public/audio_files/16671/01_Radio_Special_broadcast.mp3 HTTP/1.1
Host: production.mediajoint.prx.org.s3.amazonaws.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
......................
Range: bytes=21049565-56723038
If-Range: "2781e0d7e51b138ce8461bdb748c86ff"
tma Да да, я уже выше давал ссылки на microsoft filestream. Это может стать золотой серединой.tma писал(а): Вот ссылки:
http://www.linux.org.ru/forum/web-development/7466419
http://technet.microsoft.com/ru-ru/libr ... 14%29.aspx
The asterisk is my hero
Re: Запись разговоров в базу mysql..
HTML5 плеер как и JW использует range request - это давно не Америка и к теме отношения никакого не имеет, так эта фишка работает только при перемотке. Мне не известен плеер, который работает блоками - посему и был вопрос в лоб - ответа нет, и думаю не будет. А если файл всегда качается целиком (а это нужно как минимум для того чтобы плеер мог знать его длительность и нарисовать time bar) - то все разговоры о блочной передаче и ее сомнительной эффективности идут в (|) (кстати не помешал бы соотв. смайлик !). Насчет BLOB'в и полной загрузки в память - это верно не для всех баз. Есть базы которые по fetch_row получают только id блоба, и уже специальная f() по blob_id возвращает данные, причем с заданной длиной и смещением. Но это опять же - до спины, так как файл плеером все равно качается полностью.
Разумеется есть много задач, где нецелесообразно хранить audio данные в таблице - но эта конкретная - не одна из них. Также следует учесть, что базы сейчас уже не те, что 10 лет назад - есть к примеру одна GPL'ная, по сравнению с которой оракл нервно курит в сторонке.
И напоследок могу подчеркнуть, что большинство из вас никогда не работало с кластерами (бред от свитча не в счет). Задача бэкапа или даже тупого получения списка audio файлов одного ебонента становится невыполнимой , если их хранить на ФС, так как в любой момент любой из backend'ов может склеить ласты.
Разумеется есть много задач, где нецелесообразно хранить audio данные в таблице - но эта конкретная - не одна из них. Также следует учесть, что базы сейчас уже не те, что 10 лет назад - есть к примеру одна GPL'ная, по сравнению с которой оракл нервно курит в сторонке.
И напоследок могу подчеркнуть, что большинство из вас никогда не работало с кластерами (бред от свитча не в счет). Задача бэкапа или даже тупого получения списка audio файлов одного ебонента становится невыполнимой , если их хранить на ФС, так как в любой момент любой из backend'ов может склеить ласты.
Re: Запись разговоров в базу mysql..
Sfinx, не порите чушь, про чтение файла целиком чтоб размер узнать, сойдете за умного.А если файл всегда качается целиком (а это нужно как минимум для того чтобы плеер мог знать его длительность и нарисовать time bar)
вот первая попавшаяся фигня из логов которая просит первые 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 терабайт и как то ласты не склеивает.
