Перепост, про 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

[metaclass.livejournal.com]

Эээ, резервный сервер на случай пиздеца основного.

[sgalitsky.livejournal.com]

- так вот. - для ашкуишкв надо лисапед изобретать для стэндбая? или поставил - и работает?

[fraks-nsk.livejournal.com]

А в этом вашем постгрессе этот стендбай появился как я вижу в версии 9,0 а текущая версия 9, с чем-то.
Т.е. появилось оно совсем недавно, значит чуть раньше Pg был совсем фигней?

[metaclass.livejournal.com]

Postgresql под винду нормальным стал только в 8 версии, это было заметно позже, чем вышел FB 1.5

[fraks-nsk.livejournal.com]

Ну а тогда вообще непонятно об чем тут речь.
Надысь некий сервер который пилят студенты наконец-то вырвался вперед по каким-то показателям. И почему это стало поводом тут же на него валить?
А этот Hot-Standby как я почитал - по смыслу не так далеко от shadow и ушел.

[metaclass.livejournal.com]

Не, настоящий standby это совсем не то. В идеальном случае, пользователи вообще не замечают, что что-то изменилось. Но это стоит столько, что окупает себя только в особо злых случаях.

[fraks-nsk.livejournal.com]

дык я понимаю что и стоит недешево и для того что бы он работал нормально, или хотя бы что бы просто работал - и админы нужны соответственные. Только к чему тут товарисч [info]sgalitsky такие бочки скатывает?
У меня все больше впечатление что он не программер а некий админ прыг-прыг по конторам, сам толком ничего не написал поэтому и вопрос представляет весьма поверхностно.
Базы на которые он ссылается - писал не он и сопровождал по всей видимости тоже не он. Его дело - микро-скриптики на питоне которые ХЗ что делают.

[metaclass.livejournal.com]

Firebird удобен для программистов и неудобен для админов. Поэтому он в основном занимает нишу "софт, который пишется и обслуживается одними и теми же людьми". Админы же как-то неодобрительно к нему относятся.

[fraks-nsk.livejournal.com]

Потому что там крутить особо нечего, да и без знания потрохов - непонятно что.
У меня вообще все там по дефлоту стоит, ничего не кручу :)
Максимум - отключу неудачный индекс по +0 и стараюсь меньше использовать inner join ибо он дает больше воли оптимизатору.
Планы не прописываю.

[metaclass.livejournal.com]

Ну, я тоже не кручу, кроме кэшей и физического расположения баз.
А вот насчет "меньше использовать inner join" - это еще что за вуду новое такое?:) Я его постоянно использую, там где по логике положено.

[w00dy.livejournal.com]

мне кажется что в случае если программист и жнец и на дуде игрец, то как-то пофиг на чём писать, главное чтобы удобно себе любимому было. Просто FB, как мне кажется, пишется программистами для программистов для простых инфраструктурных сценариев, вот удобство отсюда и растёт. И лично я, из своего опыта, не сказал бы что тот же mssql мне поддерживать сложно.

[fraks-nsk.livejournal.com]

shadow - это не в ту сторону? Или подразумевается автоматическое прозрачное резервирование сервера?
А где такое есть?

[metaclass.livejournal.com]

Во всех альтернативах FB есть, где сторонними утилитами, где встроено в сервак.

[fraks-nsk.livejournal.com]

Есть что?
Ставится 3 компа, 2 - с северами и с БД, один из них мастер а второй - зеркало реальном времени, а третий комп - балансировщик/распределитель - определяет по каким-то признакам смерть мастера и перекидывает все на зеркало?
Или что-то другое?

[metaclass.livejournal.com]

Ну хотя бы так
http://wiki.postgresql.org/wiki/Hot_Standby

Вообще идея в том, чтобы снизить даунтайм до минимума, т.к. в каких-нибудь OLTP никто не будет ждать, пока бэкап базы поднимут.

[fraks-nsk.livejournal.com]

Ну ответ про FB ты знаешь - там такого нет, кроме shadow которое собсно никто и не юзает потому как полумера.

[fraks-nsk.livejournal.com]

Но этот Hot Standby сам по себе не панацея потому как возникает масса "но".
Первый вопрос который у меня возникает - как диагностировать выход из строя мастера.

А так и на shadow можно вопрос решить. Мастер умер, выдернул винт, воткнул во второй комп, работаем дальше. Вопрос когда переезжать-то.

[sgalitsky.livejournal.com]

я о fb не слишком много знаю. скажите, пожалуйста, - не пойму, - товарищ прикалывается или взаправду?

[metaclass.livejournal.com]

Насчет standby? Не знаю.
В fb его нету, для HA решений fb не применяется, поэтому вполне может быть, что про standby и не слышали.

[metaclass.livejournal.com]

И да, если спрашивать у разработчиков fb про некоторые вещи, которыми им проедают мозг уже давно - типа нормальных логов сервера, нормальной posix-командной строки, того же standby или корректного использования SMP - они обычно садятся на коня :)

[sgalitsky.livejournal.com]

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

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

[metaclass.livejournal.com]

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

А, и да - firebird имеет embedded вариант - как раз та же ниша, что sqlite. И переход от embedded к нетворк - замена одной либы, из-за чего практикуется такое: показываем клиенту продукт, вообще его не инсталлируя, тупо скопировав в флешки, один пользователь пользуется, потом переселяем на сервер, когда захотят остальные пользователи и запинают свое начальство и ИТ-службу.

[fraks-nsk.livejournal.com]

Во времена выбора IB этого sqlite наверное еще и в помине не было.
А FB весьма неплохо развививается, не требует никаких дописываний лично мной и покрывает все мои задачи.
Зачем мне скакать с сервера на сервер следуя текущей моде если есть нормальное решение, не хуже других и ничего уже переделывать ради просто переделывания - не надо?

[theiced.livejournal.com]

товарищ просто известен своей тупостью.

[sgalitsky.livejournal.com]

не могу так прямо сказать. но что-то, похожее на тупость, у этого товарища проскользнуло.