asterisk.ru

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

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

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

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

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

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

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

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

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

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

switch писал(а):Православные одесситы в отаке!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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