Sfinx писал(а):
a) поиск в 99% осуществляют не в аудио данных, а по src/dst номерам, timestamp'у и т.д. - здесь выигрывает база, так как шариться по ФС с миллионом записей, добывая эту инфу, как минимум глупо
Глупо для этого держать сам аудио-файл в БД, когда можно там хранить его уникальное имя на FS.
Никто никогда не будет шариться по файлам - сделали запрос, получили имя файла - достали файл.
При этом делать с файлами можно что угодно, в том числе и проигрывать его со смещением, как правильно написал
kasper.
И зачем хранить сам файл в БД?
Sfinx писал(а):
b) для прослушивания незачем доставать сразу все BLOB'ы - достаточно создать линки для броузера на страничке и только при клике доставать конкретный для проигрывания в этом же броузере
Потрясающе. Т.е. для запроса
каждого файла понадобится делать запрос в БД, затем вытаскивать оттуда нужный файл?!!
Не проще ли не страдать маразмом и не создавать линки в браузере на
файлы?!!
Соответственно для того, чтобы открыть нужный файл, нужно будет сделать минимум операций.
Но у некоторых - свой особый путь...
Sfinx писал(а):
c) в том 1%, где нам все таки нужен будет ASR - можно написать скрипт/программу, которые будут распознавать audio-поток по записям, и класть распознанное в какое-нить transcripted_audio varchar поле. Я бы это делал в момент добавления новой записи, чем бы снял все последующие проблемы и упростил задачу донельзя
ASR = Answer Seizure Ratio?
Зачем для этого разбирать аудио-файл?
ASR is a measure of network quality defined in ITU SG2 Recommendation E.411: ‘International network management - Operational guidance’.
Its calculated by taking the number of sucessfully answered calls and dividing by the total number of calls attempted (seizures). Since busy signals and other rejections by the called number count as call failures, the calculated ASR value can vary depending on user behaviour.
Ну Ok, можете разбирать и для ASR.
Sfinx писал(а):
d) в случае кластера - хранение записей/voicemail'ов в базе - это must have. Никак не представляю себе ФС-хранение в этом случае, мягко говоря - закукуаетесь копировать это все туда-сюда
"Мыши плакали, кололись, но продолжали есть кактус." (C).
Ваше право страдать маразмом. Вы даже усиленно пытаетесь найти оправдания, правда пока что какие-то жалкие попытки (особенно про линки в браузере
).
Даже в случае voicemail/etc удобнее файлы хранить на файловой системе на отдельном сервере, но никак не в БД.
Хотя бы только из-за того, что скорость поиска конкретного файла на файловой системе будет намного выше (В БД нашли нужную запись, взяли имя файла - обратились к нему), чем в случае хранения его в БД (В БД нашли нужную запись, выгрузили файл на файловую систему сформировав ссылку, обратились к нему).
В любом случае работа с аудио-файлом возможна при его предварительной выгрузки на файловую систему!
Смысл делать дополнительные действия, засовывать файлы в БД, увеличивать ее размер и уменьшать быстродействие?
А если индекс накрылся? Восстановление/резервирование/etc? Жуть какая-то. БД - транзакционные, не знаю как там блоб хранятся, но если они еще и в транзакшин лог будут попадать - это просто жесть.
Ваш SQL сервер просядет просто мгновенно при более-менее большом объеме данных - это ж нужно какие винты иметь шустрые, чтобы постоянно перемалывать такие объемы между памятью и диском?
