Перепост, про Firebird

[metaclass]

ссылка
В бане (или борделе, кто куда ходит), после грамотной попарки (или еще чего), распаренный партнер подсказывает генральному, что во всем виноват тормозной Firebird, и надо переходить на "промышленные" СУБД.
...
Правильно затюнигованный Firebird держит 1500 активных клиентских подключений, обслуживает 400Гб базу, и экономит предприятию как минимум от $6000 за каждый процессор.

У меня на почве Firebird когнитивный диссонанс в крайней стадии.
Во-первых, он у меня работает в количестве нескольких сотен штук у разных клиентов. Во-вторых, я на его использовании съел собаку. В третьих, у меня кодогенератор пока заточен строго под Firebird и свои модели хранит тоже в Firebird. То бишь мне по долгу службы положено всюду Firebird пропагандировать и пиарить.

Но периодически возникают срачи с разного рода админами, коллегами-программистами и прочими причастными к теме, и все они крайне не любят оный Firebird. Типа истории про неуловимый баг "если в процессе работы почитать(скопировать) базу извне сервера, то база сдохнет. Оригинал сдохнет, не копия". Ну и прочие urban legends. У людей без мозгов вообще первая реакция примерно такая: "Firebird? А, ну идите в топку, пионеры из НИИГиТ.".

Ребе theiced вообще убеждает меня, что базы Firebird регулярно отправляются на марс, со всеми данными :) И таки да, надо признать, такое бывало, меньше 1% случаев, но бывало. Я не знаю, как обстоят с таким дела у всяких Ораклов или PostgreSQL, но меньше 1% излечимых отказов, при жестоко удолбищных условиях эксплуатации - это имхо, вполне хорошо. Возможно, я чего-то не понимаю, и отказов вообще быть не должно.

Если посмотреть на среднего вопрощающего на sql.ru или на отвечающих ему местных "гуру", то причины такой ситуации становятся более понятны - вопрощающий обычно реально пионер из НИИГиТ, отвечающие или модераторы - несдержанные на язык красноглазики, в самом лучшем случае - делающие гешефт на Firebird и около того товарищи.

И еще один аспект - это те самые условия эксплуатации. Oracle/MSSQL - это значит заведомо нормальный сервер, инфраструктура и наличие обслуживающих админов. PostgreSQL/MySQL - наличие в дельта-окрестности следящего за инфраструктурой красноглазика.
Для Firebird же типичная инфраструктура - "первый попавшийся десктоп с виндой, с матерью на nvidia чипсете, съеденными мышами проводами, на котором кишат вирусы, админов нет, а пользователи качают с китайских серверов зоофильское порно с троянами и червями".
Я до сих пор не могу забыть, как админы клиентов базу данных бухгалтерской системы один раз удалили вместе с образом виртуальной машины, а в следующий раз, уже после переселения на физическую машину, у них просто ВЫПАЛ ПРОВОД из винчестера во время работы. Слава богу, база была на другом винчестере.

Comments

[w00dy.livejournal.com]

в постгресе вакуум делается автомагически, обычно в это время ещё статистику всякую собирают и подсчитывают.

[metaclass.livejournal.com]

В Firebird тоже есть. Но его ВНЕЗАПНО советуют отключать и делать по расписанию извне, во время, когда нагрузка меньше.

[w00dy.livejournal.com]

в pg autovacuum тоже модно подтюнить чтобы он не влез своими грязными руками в базу в самый ответственный момент. А раньше vacuum тоже нужно было вручную дёргать, по крону, например, но это было давно и не правда.

[fraks-nsk.livejournal.com]

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

[metaclass.livejournal.com]

В общем, я перекопал и вычистил заведомо все места в нашем софте где транзакции удерживали версии. Сплошные readonly-транзакции, короткие пишущие транзакции и прочие обходные маневры.

И то - при какой-то малопонятной комбинации действий (открытая транзакция+отвалившаяся сеть) - изредка застревает OAT и начинают копиться версии. Помогает только переподключение всех к базе.

[fraks-nsk.livejournal.com]

> в постгресе вакуум делается автомагически, обычно в это время ещё статистику всякую собирают и подсчитывают.

Это ответ на вопрос "Когда".
Но я спрашивал "Для чего".

[w00dy.livejournal.com]

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

[fraks-nsk.livejournal.com]

Статистика по индексам в FB обновляется отдельной командой. Влияет на оптимизатор и выбор индексов. Я не любитель давать волю оптимизатору при написании запросов - и обновление статистики мне не требуется.

По "подчистить место" - таки при этом происходит уменьшение размера файла БД или просто внутри файла мусор подчищается?

[w00dy.livejournal.com]

размер базы тоже уменьшает, если не ошибаюсь. Просто база в pg размазана по куче файлов, так что удалять лишнее можно без особых проблем.

[fraks-nsk.livejournal.com]

А что за куча? Кроме tablespace которые задаются вручную как я понимаю, при потребности.

[metaclass.livejournal.com]

Там практически все большие объекты БД типа таблиц и индексов лежат в отдельных файлах, с цифровыми именами.

[fraks-nsk.livejournal.com]

Типа как в DBF и Paradox? :)

[metaclass.livejournal.com]

Да это общепринятая шиза вроде, что в MySQL, что в оракле, что в Postgresql

[w00dy.livejournal.com]

в pg ж вроде как не совсем такая шиза, там жеж постранично оно как-то связано, а не один файл - одна таблица

[metaclass.livejournal.com]

Не, там вроде именно что один объект БД - один файл.

[w00dy.livejournal.com]

tablespace это само собой, а структура хранилища - это уже нечто другое.

В общем тут можете почитать что там и как: http://www.postgresql.org/docs/9.0/interactive/storage.html