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

Тут речь о принципиально разных рыночных нишах.
В "оптово-розничной торговле рогами и копытами" просто нафиг не нужны ораклы и железо за десятки тысяч баксов, оно себя там не окупит никак.
А контор, где реально нужны ораклы и дорогое железо - не так уж много. Да и тендера там обычно решены задолго до принятия решения "что покупать".

[kurilka.livejournal.com]

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

[sgalitsky.livejournal.com]

не секрет, что это за "большие игроки"?

[kurilka.livejournal.com]

Про 100т.р. считать лень, но вот как пример - http://opencompute.org/ до других имён (кроме FB) додуматься несложно.

[sgalitsky.livejournal.com]

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

[metaclass.livejournal.com]

http://en.wikipedia.org/wiki/Commodity_computing
Вообще, практика показывает, что в наших ебанутых условиях (которые составляют большую часть того, что я вижу у клиентов) лучше делать все на дешевом железе, а надежность и производительность догонять программно, потому что программиста в случае чего найти несложно, а если навернется какой-нибудь мега-сервера за тысячи денег и внезапно окажется что "производитель такого давно не делает, покупайте новый" или там "подпишитесь на техобслуживание за много тысяч денег" - это продавить у клиентов будет затруднительно.
Т.е. единственный вариант покупки нормального тяжелого железа - это когда от входа понятно, что за железо, софт и обслуживание денег жалеть не будут и всякие планово-экономические отделы мозги ебать на тему "зачем вам столько денег" тоже не будут. И деньги на нормальный обслуживающий персонал будут выделяться без вопросов "а чего это у вас админы получают больше чем генеральный директор".

Моя контора например

[runixonline.livejournal.com]

немелкая даже по мировым масштабам.. ГОК, рудник, переработчики, клиенты..

Но с точки зрения АЙТИ - бизнес несложный. И потратить 100К на новый бульдозер всяко доходнее, чем на суперпуперсервер

[sgalitsky.livejournal.com]

показатель - это его ТТХ. от которых стоимость находится в прямой зависимости.
но для оптовиков и PC очень часто хватает. это правда.
ниши просто слегка разные..)

[fraks-nsk.livejournal.com]

ТТХ должно быть оправдано задачей или малой ценой. Если цена не малая а задачей не оправдано - то это тупая трата денег.

[sgalitsky.livejournal.com]

..ниши разные.
деньги разные.
задачи разные.
серверы разные.

не доходит?

[fraks-nsk.livejournal.com]

ДО вас наконец-то начало доходить :)

[sgalitsky.livejournal.com]

бля..
когда Вам нечего сказать, Вы повторяться начинаете.

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

а потом про - "начало доходить". дубово, чо.

[fraks-nsk.livejournal.com]

Вас переклинило на вашем постгресе.
FB - нифига не устаревший а нормально развивающийся сервер с коммунити по всему миру.

Вот была такая контора, в нашем бизнесе и регионе - Топ-Книга. Увлеклась "решениями для больших мальчиков" - и кризис эту контору смертельно подкосил. У них там и SAP был и консультанты заморские, и один эс и самописки. Дохера чего крутого. И железо конечно. Но это не показатель эффективности.

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

Вам пофиг на эффективность бизнеса - вам крутые железки и софтинки трогать нравится.

[sgalitsky.livejournal.com]

показатель - это тащиться от СУБД, в которой вакуум делают через бэкап с последующим рестором.
в 2011 году, да.

[metaclass.livejournal.com]

Ладно бы вакуум, блин, кого волнуют те размеры баз.
А то backup/restore обычно в качестве панацеи от всего чего можно используют. Может это и бред уже давно, но все равно все используют.

[fraks-nsk.livejournal.com]

Я перебэкапливаю базы только после массированных удалений, когда завожу "новую" базу.
Бывает обычно раз в 2 года.

[metaclass.livejournal.com]

Да, вот с массированными удалениями и производительностью вопрос до сих пор неясен.
У нас для баз где-то 20 гиг размером раз в месяц производится обслуживание - грохаются устаревшие данные, а затем backup-restore. Скорее всего backup-restore тут нафиг уже не нужен, но это нужно проверять.

[fraks-nsk.livejournal.com]

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

А для чего требуется делать вакуум в постгресе?

[w00dy.livejournal.com]

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

[metaclass.livejournal.com]

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

[w00dy.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

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

[w00dy.livejournal.com]

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