Русский форум Asterisk сообщества
https://forum.asterisk.ru/
Не-не! Я читаю и учусь, много полезного почерпнул. Тема расово чистая, потому беспощадная. Имеет тенденцию к вечности, и это достойно.ys1797 писал(а):Ded закрой сей флудодром.
Sybase, DB2 и другие аналогичные БД поддерживают RAW-девайсы, т.е. в них уже нет накладных расходов в виде файловой системы.ddkprog писал(а):доступ через БД к данным это двойной индекс
Именно так. Они используют RAW-девайсы и сами разбираются как хранить на них информацию.ddkprog писал(а):Sabase, DB2 не используют FS от ОС и строят свою БД прямо на диске обращаясь напрямую к драйверу?
Не, он пытается использовать MySQL, как я понимаю, в надежде, что это самая лучшая БД на свете.ddkprog писал(а):а Sfinx использует эти СУБД для храниения музыки?
Фигню расшифруйте, походу часть исчезла - мне пока непонятно как по HTTP размер файла, который мы тянем узнать в 2 байта.gosha писал(а):Sfinx, не порите чушь, про чтение файла целиком чтоб размер узнать, сойдете за умного.А если файл всегда качается целиком (а это нужно как минимум для того чтобы плеер мог знать его длительность и нарисовать time bar)
вот первая попавшаяся фигня из логов которая просит первые 2 байта, чтоб размер узнать - AppleCoreMedia/1.0.0.10B146 (iPad; U; CPU OS 6_1_2 like Mac OS X; en_us)
тут я даже не знаю что будеть хуже - ФС на perl + БД или full БД решение ... это надо быть фанатомP.S. пользуем, в базе мета и ссылка на ноды с файлами ( 2-3 кратная избыточность, в зависимости от типа файлов ), голоса около 100 терабайт и как то ласты не склеивает.
что нельзя было хотя бы glusterfs поставить ?Опять пальцем в небо - это не mysql, он не держит multimaster репликацию без костылей. Может быть сейчас и поигрался бы с MariaDB + Galera, но пока не до этого.Не, он пытается использовать MySQL, как я понимаю, в надежде, что это самая лучшая БД на свете.
В случае с RAW-девайсами это хоть как-то оправдано, но за счет транзакционных логов увы, все равно не катит...
"Имя, сестра, имя !" Так мы услышим начальника транспортного^H^H^H^H^H^H имя секретного плеера от свитча, который блоками по HTTP работает ? И свитч судорожно полез в тысячный раз в гугль, так как обо#ралсяswitch писал(а):Мне не известен плеер, который работает блоками - посему и был вопрос в лоб - ответа нет, и думаю не будет.
есть два возможных варианта:
1) передача целиком
2) передача по частям (т.е блоками данных)
Что вы там имели в виду я не знаю. Многократно ступили и признаться в этом духу не хватит.
До него до сих пор не доходит что HTTP - это TCP поток, и блоков там не было, нет и быть не может ...Нельзя думать о каком-нибудь решении - в лоб. Существует такое понятие как окно возможностей. Применяется где угодно, включая архитектуру ПО - есть некие условия исходной задачи, которые вполне позволяют применить решение, которое в обычных условиях неэффективно или громоздко. Здесь на весы ставится много причин, взвешивается, анализируется, проектируется, потом делается прототип, проводятся тесты и уже после этого можно говорить о применимости/целесообразности и т.д. Это продакшн, детка - не хухры-мухры ...ddkprog писал(а):Sabase, DB2 не используют FS от ОС и строят свою БД прямо на диске обращаясь напрямую к драйверу?
а Sfinx использует эти СУБД для храниения музыки?
это как то слишком надумано
Хм.. Итак, дядьки с большими скилами, имеет ли смысл хранить файлы количеством 10-20 в сутки, тоесь, 600 файлов в месяц, размером 3-10 Мб в базе? Тоесь, размер базы в месяц вряд ли превысит 6Гб.. Дальше, оно сваливается в архив и больше не нужно на сервере, так-как начинается новый месяц и новая база.. Да и места больше 10 Гб нету (это поделие на виртуальном сервере крутится)..tma писал(а):..Итого не видно ни одного реально оправданной необходимости хранения бинарных данных (по крайней мере больше некой величины, мелкие картинки думаю не в счет, хотя тоже маразм - это же статика!) в БД кроме одного - хранить все в одном месте, другими словами облегчить жизнь программистам и администраторам (проще резервировать), усложнив жизнь простым пользователям...