Firebird и бэкапы

[metaclass]

Вспомнил, откуда меня плющила мысль про невосстанавливаемые бэкапы FB, на что разработчики меня уверили, что такого уже не бывает.
Это из двух статей на сайте www.ibase.ru - 1 и 2.

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

Кстати, сегодня вышел релиз Firebird 2.5, нужно, что ли, его ставить и тестить, как раз новый проект можно будет на нем запустить, а при разработке баги, если обнаружатся, отрепортить.

Comments

[denisioru.livejournal.com]

Могу предположить, что ввиду сравнительно высокого уровня вхождения им занимаются люди с опытом, которые умеют находить и обходить косяки.

[metaclass.livejournal.com]

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

[denisioru.livejournal.com]

У него не очень дружественный инструментарий, не самая лучшая документация, есть разнообразные костыли для подключения в разных средах. Если человек осиливает это всё - с достаточно большой вероятностью он сможет и обойти костыли.

[metaclass.livejournal.com]

Документация вообще никакая :)

[denisioru.livejournal.com]

Ну вот и я про то же. К тому же наличие "nightly builds" уже показатель полного пиздеца. А учитывая что переезд с версии на версию (насколько я помню) рекомендуется делать через backup-restore - грустная хрень складывается.

[metaclass.livejournal.com]

Эээ, nightly builds это стандартная же практика - continuous integration.
А переезд с версии на версию и в постгресе рекомендуется через дамп делать, с отличием - у них там это между мажорными версиями.

[denisioru.livejournal.com]

"continous integration" это прямо противоположное явление к "поставил, настроил и забыл". Когда речь идёт о постоянном подкручивании ручек, радости от исчезновения старых багов и рвание волос на жопе при обнаружении новых - я не понимаю, как тут можно "забыть".

Понятно, что можно найти наименее глючный билд, постараться обойти все его баги и написать клиента так, чтобы всё работало устойчиво и "забыть" на некоторое время - но придет очередной админ, посмотрит на билд 1.3.27824.782.2 скажет "древнее говно, надо апдейтнуть" - и поехали сначала.

[metaclass.livejournal.com]

Не, так в продакшен никто это не ставит, очевидно. В продакшене стоят релизы, а еще лучше второй или третий сервисный релиз после основного.

Но для тестов, например при разработке или для приложений, где падения некритичны - это ж самое то, заодно можно разработчиков пинать сразу.

[denisioru.livejournal.com]

+30 к скиллам в разработке, +20 ко времени разработки и +90 к геморою от внедрения. Вобщем прокачать можно, да. Но надо ли это всё?

[metaclass.livejournal.com]

Не знаю, я использовал Postgresql, MSSQL и Firebird, когда выбирал СУБД четыре года назад - тестировал заодно и оракл - в итоге Firebird по удобству победил всех с большим отрывом. Это при том, что я до того вообще не использовал никаких RDBMS, а данные хранил в самодельной объектной базе :)

[denisioru.livejournal.com]

Кстати по объектной БД - db4o вроде неплох, по крайней мере мне так показалось после двухнедельного переменного тискания.

[metaclass.livejournal.com]

Не, после 10 лет теоретического и практического изучения этого вопроса я на нереляционные БД буду смотреть только тогда, когда кто-нибудь напишет работы, аналогичные работам отцов по реляционным БД :)

[metaclass.livejournal.com]

И кстати, у нас за три года сменилось всего лишь три релиза в коробочном продакшене (у меня за четыре года в заказном проекте - 4 релиза, из них один мажорный (1.5->2.1)).

[denisioru.livejournal.com]

Ещё всякие интересные штуки, которые в обычном режиме работают во всех остальных СУБД - NTLM-аутентификация (помню, читал что добавили в FB), дифференциальный и инкрементальный бакап, зеркалирование БД - как с этим дело обстоит? Ежесуточный бакап не панацея, потери за сутки могут вырвать с жопы последние волосы.

[metaclass.livejournal.com]

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

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

[denisioru.livejournal.com]

У вас что, стоимость проекта сравнима со стоимостью БД? Тот же MSSQL 2008 R2 Standard стоит всего $3000, путем несложных манипуляций эта цена упадет в разы при сохранении лицензионности (ActionPack, партнерство). А Std умеет практически всё, что и Ent за редкими исключениями типа партиционирование (коего и IB не умеет).

[metaclass.livejournal.com]

У нас проект продается за 1000$, без ограничений по количеству рабочих мест внутри клиента.

[denisioru.livejournal.com]

И база больше 10 гигов?

[metaclass.livejournal.com]

16-20 гиг