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

[noize]

У нас не так давно из-за проблем с диском накрылась БД, так ее восстановление из бэкапа заняло почти всю ночь

Для таких вещей обычно используют репликацию. Так что этот пример мимо, т.к. с тем же успехом мог накрыться дисковый массив с файлами.

[tma]

Предлагаю реплицировать БД с блобами - это еще круче будет.
Если накроются какие-то файлы - это фигня, от этого ничего страшного не случится, мягко говоря.
А накроется БД - кердык полный будет.

[noize]

Предлагаю реплицировать БД с блобами - это еще круче будет.

т.е. хотите сказать, что у вас БД используется без репликации? Серьёзный подход, однако.

[tma]

Я где-то написал, что у нас используются блобы?

[noize]

Нет, но это не отменяет того, что комментарий про крушение диска с БД ни в коей мере не относится к хранению бинарных данных в СУБД.
Поставить между серверами для БД гигабитный свич сегодня может себе позволить каждый. Если не хочется повышенной нагрузки при синхронной репликации, то в кашим услугам асинхронная. Это вполне проверенный и зарекомендовавший себя метод отказоустойчивого хранения данных в СУБД. Я уверен, что большинство(если не все) популярных СУБД имеют встроенные стредства для инхронизации данных.
Лично для меня плюсы хранения всех данных в БД вполне очевидны и sfinx их достаточно подробно перечислил. Главный минус в этой схеме в том, что с этим необходимо заморачиваться в начале, писать дополнительные скрипты для записи блобов в БД. Но если в компании используется подобная схема хранения данных, то нельзя её рассматривать как некорректное решение.

[tma]

Ссылку на результаты проведенных тестов не приложите?
Пока что выдается желаемое за действительное...

[noize]

каких тестов?

[tma]

Точно, зачем тесты... Главное ощущение, что это хорошее решение, а все остальное приложится.

[Sfinx]

Православные одесситы в отаке!

О, жтаг-моск switch'а таки вышел из hibernate, но глючить все еще продолжает

Sfinx, все что вы написали это ваше субъективное мнение, однако факты - упрямая вещь.

И в чем тут проблема ? Операций таки-да, минимум - одно единственное чтение.

проблема в том что 10 мегабайтный файл из БД придется тянуть целиком, что чревато проблемами особенно при узких каналах (например между ДЦ).

А файл с ФС тянуть типа не надо - он у switch'а, как и у tma - по воздуху появляется у пользователя ?

Если применять вещи по назначению и использовать файлы, то можно читать из ФС блоками, например только нужные места, по мере поступления. Блочная передача реализована везде, от FAT до HTTP.

Видите ли tma - файл надо сначала найти, открыть, прочитать, запихнуть в буфер, передать по сети и т.д.

открытие файла это создание дескриптора потока - чисто виртуальная сущность. Чтение можно осуществлять блоками (это и делается всегда, иначе бы даже БД не работала бы с файлами больше чем ОЗУ), запись в буфера осуществляется автоматически, в 80% случаев на аппаратном уровне. Передача по сети ведется блоками, а не целиком как в случае БД.

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

и за сколько времени вы легко и не принужденно сделаете терабайтный дамп?

Не поверишь - 0 ms. У меня multimaster репликация. А за сколько ты сделаешь бэкап своей терабайтной FAT ФС ? Только незабудь - блоками, блоками ... и по HTTP

Ну да, лишнние 50-100ms это веский довод.
Файл в 10 мегабайт передается по сети 100 мбит/с в среднем за 2 секунды. Откуда 50..100 мс взяли я не знаю, не иначе поп-батюшка подсказал.

Опять тут чукча не читатель: речь шла, об отношении TIME(fetch_row) - TIME(read_file) = ~50-100 ms. Где там 2 секунды ... наверное залетевший бизон Хигса вызвал очередной катастрофический сбой в наборе строго химических рефлексов свитча, который он по незнанию именует моском. Вот тут как раз и стоит сходить к батюшке, глядишь и глюки/демоны отступят

не просто медленнее, а встопицот раз медленнее. на 1000 записей разницы можешь и не заметить, а когда их в тысячу раз больше? Короче ясно что вы не решали сколь-нибудь серьезных задач с БД, уж слишком серьезные пробелы в образовании...

Не, серьезных не решал, у меня все какие-то несерьезные попадаются. Как и оппоненты, у которых индексы постоянно накрываются. Со стороны выглядит где-то так - свитч на работе, собирает срочную совещанию и важным таким голосом говорит: "у нас тут индекс опять накрылся, потому что база, бл#дь серьезная как и ее @#$%% задача, #@$#$ !"

[Sfinx]

Слив засчитан, что значит полную и безоговорочную победу сил света над псевдо-научной бесовщиной ... чего только передача блоков FAT по HTTP стоит ... как вспомню, так вздрогну ...