Запись разговоров в базу mysql..

[ys1797]

Ded закрой сей флудодром.
А то тут щас перейдут к readblock eraseblock и writeblock
И конечно к теме, а у меня всеж длинее!

[ded]

Ded закрой сей флудодром.

Не-не! Я читаю и учусь, много полезного почерпнул. Тема расово чистая, потому беспощадная. Имеет тенденцию к вечности, и это достойно.

[tma]

доступ через БД к данным это двойной индекс

Sybase, DB2 и другие аналогичные БД поддерживают RAW-девайсы, т.е. в них уже нет накладных расходов в виде файловой системы.
Правда транзакционные логи они все равно хранят на файловой системе, так что лишняя нагрузка обеспечена.
Мне просто страшно становится от мысли постоянно колошмятить дисками поверх FS для записи огромных BLOB в транзакционные логи,
вытаскивать их в память и гонять по сети в случае репликации...

У меня тут недавно знакомый поднимал кластерный MySQL, который хранит всю БД исключительно в RAM распределяя потаблично между нодами. В результате многочисленных тестов они пришли к выводу, что никакого прироста производительности нет, наоборот идет потеря на некоторых операциях. Да и память, при всей своей дешевизне, стоит дороже дисков, так что не вариант.

Итого не видно ни одного реально оправданной необходимости хранения бинарных данных (по крайней мере больше некой величины, мелкие картинки думаю не в счет, хотя тоже маразм - это же статика!) в БД кроме одного - хранить все в одном месте, другими словами облегчить жизнь программистам и администраторам (проще резервировать), усложнив жизнь простым пользователям.
Вопрос - для кого предназначена система? Для пользователя или программиста? Если для программиста, то ему пора заняться другими делами, но только не программированием...

[tma]

Sabase, DB2 не используют FS от ОС и строят свою БД прямо на диске обращаясь напрямую к драйверу?

Именно так. Они используют RAW-девайсы и сами разбираются как хранить на них информацию.
В бытность системным администратором лично поддерживал штук 7 Sybase'ов настроенных таким образом.
Этот способ обеспечивает намного большую производительность, нежели поверх FS.
Но backup возможен только штатными средствами, правда иначе backup на них и не сделать...

а Sfinx использует эти СУБД для храниения музыки?

Не, он пытается использовать MySQL, как я понимаю, в надежде, что это самая лучшая БД на свете.
В случае с RAW-девайсами это хоть как-то оправдано, но за счет транзакционных логов увы, все равно не катит...

[Sfinx]

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

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

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

Фигню расшифруйте, походу часть исчезла - мне пока непонятно как по HTTP размер файла, который мы тянем узнать в 2 байта.

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

тут я даже не знаю что будеть хуже - ФС на perl + БД или full БД решение ... это надо быть фанатом что нельзя было хотя бы glusterfs поставить ?

[Sfinx]

Не, он пытается использовать MySQL, как я понимаю, в надежде, что это самая лучшая БД на свете.
В случае с RAW-девайсами это хоть как-то оправдано, но за счет транзакционных логов увы, все равно не катит...

Опять пальцем в небо - это не mysql, он не держит multimaster репликацию без костылей. Может быть сейчас и поигрался бы с MariaDB + Galera, но пока не до этого.

[Sfinx]

Мне не известен плеер, который работает блоками - посему и был вопрос в лоб - ответа нет, и думаю не будет.
есть два возможных варианта:
1) передача целиком
2) передача по частям (т.е блоками данных)
Что вы там имели в виду я не знаю. Многократно ступили и признаться в этом духу не хватит.

"Имя, сестра, имя !" Так мы услышим начальника транспортного^H^H^H^H^H^H имя секретного плеера от свитча, который блоками по HTTP работает ? И свитч судорожно полез в тысячный раз в гугль, так как обо#рался
со своими блоками FAT по HTTP просто не подетски До него до сих пор не доходит что HTTP - это TCP поток, и блоков там не было, нет и быть не может ...

[Sfinx]

Sabase, DB2 не используют FS от ОС и строят свою БД прямо на диске обращаясь напрямую к драйверу?
а Sfinx использует эти СУБД для храниения музыки?
это как то слишком надумано

Нельзя думать о каком-нибудь решении - в лоб. Существует такое понятие как окно возможностей. Применяется где угодно, включая архитектуру ПО - есть некие условия исходной задачи, которые вполне позволяют применить решение, которое в обычных условиях неэффективно или громоздко. Здесь на весы ставится много причин, взвешивается, анализируется, проектируется, потом делается прототип, проводятся тесты и уже после этого можно говорить о применимости/целесообразности и т.д. Это продакшн, детка - не хухры-мухры ...

[mik-mak]

..Итого не видно ни одного реально оправданной необходимости хранения бинарных данных (по крайней мере больше некой величины, мелкие картинки думаю не в счет, хотя тоже маразм - это же статика!) в БД кроме одного - хранить все в одном месте, другими словами облегчить жизнь программистам и администраторам (проще резервировать), усложнив жизнь простым пользователям...

Хм.. Итак, дядьки с большими скилами, имеет ли смысл хранить файлы количеством 10-20 в сутки, тоесь, 600 файлов в месяц, размером 3-10 Мб в базе? Тоесь, размер базы в месяц вряд ли превысит 6Гб.. Дальше, оно сваливается в архив и больше не нужно на сервере, так-как начинается новый месяц и новая база.. Да и места больше 10 Гб нету (это поделие на виртуальном сервере крутится)..

[ded]

Подбросьте монету.
Если орёл - то да, имеет. Если решка - нет, не имеет.
Аргументы в пользу того или другого приведены выше в дискуссии.