![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Перепост, про Firebird
ссылка
В бане (или борделе, кто куда ходит), после грамотной попарки (или еще чего), распаренный партнер подсказывает генральному, что во всем виноват тормозной Firebird, и надо переходить на "промышленные" СУБД.
...
Правильно затюнигованный Firebird держит 1500 активных клиентских подключений, обслуживает 400Гб базу, и экономит предприятию как минимум от $6000 за каждый процессор.
У меня на почве Firebird когнитивный диссонанс в крайней стадии.
Во-первых, он у меня работает в количестве нескольких сотен штук у разных клиентов. Во-вторых, я на его использовании съел собаку. В третьих, у меня кодогенератор пока заточен строго под Firebird и свои модели хранит тоже в Firebird. То бишь мне по долгу службы положено всюду Firebird пропагандировать и пиарить.
Но периодически возникают срачи с разного рода админами, коллегами-программистами и прочими причастными к теме, и все они крайне не любят оный Firebird. Типа истории про неуловимый баг "если в процессе работы почитать(скопировать) базу извне сервера, то база сдохнет. Оригинал сдохнет, не копия". Ну и прочие urban legends. У людей без мозгов вообще первая реакция примерно такая: "Firebird? А, ну идите в топку, пионеры из НИИГиТ.".
Ребе![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
theiced вообще убеждает меня, что базы Firebird регулярно отправляются на марс, со всеми данными :) И таки да, надо признать, такое бывало, меньше 1% случаев, но бывало. Я не знаю, как обстоят с таким дела у всяких Ораклов или PostgreSQL, но меньше 1% излечимых отказов, при жестоко удолбищных условиях эксплуатации - это имхо, вполне хорошо. Возможно, я чего-то не понимаю, и отказов вообще быть не должно.
Если посмотреть на среднего вопрощающего на sql.ru или на отвечающих ему местных "гуру", то причины такой ситуации становятся более понятны - вопрощающий обычно реально пионер из НИИГиТ, отвечающие или модераторы - несдержанные на язык красноглазики, в самом лучшем случае - делающие гешефт на Firebird и около того товарищи.
И еще один аспект - это те самые условия эксплуатации. Oracle/MSSQL - это значит заведомо нормальный сервер, инфраструктура и наличие обслуживающих админов. PostgreSQL/MySQL - наличие в дельта-окрестности следящего за инфраструктурой красноглазика.
Для Firebird же типичная инфраструктура - "первый попавшийся десктоп с виндой, с матерью на nvidia чипсете, съеденными мышами проводами, на котором кишат вирусы, админов нет, а пользователи качают с китайских серверов зоофильское порно с троянами и червями".
Я до сих пор не могу забыть, как админы клиентов базу данных бухгалтерской системы один раз удалили вместе с образом виртуальной машины, а в следующий раз, уже после переселения на физическую машину, у них просто ВЫПАЛ ПРОВОД из винчестера во время работы. Слава богу, база была на другом винчестере.
В бане (или борделе, кто куда ходит), после грамотной попарки (или еще чего), распаренный партнер подсказывает генральному, что во всем виноват тормозной 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 чипсете, съеденными мышами проводами, на котором кишат вирусы, админов нет, а пользователи качают с китайских серверов зоофильское порно с троянами и червями".
Я до сих пор не могу забыть, как админы клиентов базу данных бухгалтерской системы один раз удалили вместе с образом виртуальной машины, а в следующий раз, уже после переселения на физическую машину, у них просто ВЫПАЛ ПРОВОД из винчестера во время работы. Слава богу, база была на другом винчестере.
no subject
В "оптово-розничной торговле рогами и копытами" просто нафиг не нужны ораклы и железо за десятки тысяч баксов, оно себя там не окупит никак.
А контор, где реально нужны ораклы и дорогое железо - не так уж много. Да и тендера там обычно решены задолго до принятия решения "что покупать".
no subject
no subject
no subject
no subject
использовать для серверов бытовую технику или материнские платы, разработанные не пойми кем, - иногда рентабельно, иногда нет. некоторым подходит, конечно.
no subject
Вообще, практика показывает, что в наших ебанутых условиях (которые составляют большую часть того, что я вижу у клиентов) лучше делать все на дешевом железе, а надежность и производительность догонять программно, потому что программиста в случае чего найти несложно, а если навернется какой-нибудь мега-сервера за тысячи денег и внезапно окажется что "производитель такого давно не делает, покупайте новый" или там "подпишитесь на техобслуживание за много тысяч денег" - это продавить у клиентов будет затруднительно.
Т.е. единственный вариант покупки нормального тяжелого железа - это когда от входа понятно, что за железо, софт и обслуживание денег жалеть не будут и всякие планово-экономические отделы мозги ебать на тему "зачем вам столько денег" тоже не будут. И деньги на нормальный обслуживающий персонал будут выделяться без вопросов "а чего это у вас админы получают больше чем генеральный директор".
no subject
На этом нашем интелевском сервере под 1с в гарантийный срок сдох сказевый винт. Поставщик искал его месяц - не нашел. А SATA на той маме не было. Взамен сдохшего винта дал 2 SATA + контроллер.
На обычном компе пошел в любой магазин и купил любой винт в любое время. А поскольку стоит дешево по сравнению с серверным железом то весь сервер можно менять раз в год - будет и дешевле и проще и как ни странно - надежнее.
no subject
За год тысяч на 60 минимум набегает. За один юнит. И вот что в этот юнит ставить - чепуху за 50-70 тыр, учитывая то, что скоро её перестать хватать и придется ставить вторую такую же (и платить за два юнита уже от 120 тыр), или какой-нибудь X2200, который чуть более сотки стоит.
математика-то простая.
и не сказать, чтоб датацентры пустовали. цены растут, мест нормальных все меньше.
т.е. наверное, все же мир не ограничивается firebird'ом и оптово-розничной торговлей.
и уж ни викимедия, ни фейсбук на "обычных компах" не крутятся.
no subject
У меня своя выделенная серверная, с кондиционированием.
Вместо стоек - грузовые стеллажи, на них с десяток "серверов" и один одинэсный. Шумит зараза больше чем все остальные вместе взятые.
Бесперебойники там конечно есть, но дизеля не брали ибо без питания всего офиса сервера сами по себе не нужны. Отключений больше чем на полдня раз в год не бывает. При извещении заранее мы при этом успеваем перестроить работу что бы не нарушить график отгрузок.
Пример с крутым оборудованием у меня перед глазами. Имеем совместный бизнес с москвичами. Они привезли с собой все оборудование - 2 стоечных сервера и стойку. Смотрится прикольно - пустая стойка и в ней 2 сервера :)
Но посколькуу них свое сквозное решение на одинэсе - то у них это железо оправданно. Правда зачем было делать на одинэсе если у них переписано ВСЕ?
no subject
стоечные варианты для датацентров конечно имеют свои осбенности, но что касаемо обычных компов то
из вариантов
1. - взять крутой дорогой сервер на все бабки и работать на нем всю жизнь
2. - взять обычный комп уровня немного выше среднего, через год заменить на аналогичный
Вариант 2 дает то что у меня постоянно новое железо, снятое с сервера смещается на десктопы, и поскольку компы с каждым годом все быстрее то через 10 лет я имею не старую развалину к которой ничего не найти и с производительностью далекой от сегодняшних мерок а нормальное свежее современное железо, причем возможно что обычный десктопный комп к тому времени будет иметь производительность не хуже чем эта крутая в прошлом серверная развалина.
Причем что бы это серверное железо нормально работало нужно иметь его некоторый запас в штуках ибо если оно выходит из строя - то быстро ему замену не купить. Причем запас на все эти 10 лет. А с попсовым железом - в любое время в любом магазине.
В итоге получается что если не применять ресурсоемких решений которые на несерверном железе просто не поедут - то на обычных десктопных компах получается дешевле и надежнее.
no subject
>ибо если оно выходит из строя - то быстро ему замену не купить
- есть такая вещь, как техподдержка. от дистрибьютора или стороннего сервиса. и если летит резервный блок питания на хранилище, стоимостью около 500k$, - оттуда прилетает человек и делает так, чтобы работало. при этом, естественно, есть резервные системы и хоть и кое-как, но неделю прожить можно (это было самое большее по длительности диагностики-ремонта-замены комплектующих).
no subject
Быстрее - понятие относительное, причем относительно задачи.
Вот к допустим у меня на попсовом сервере бизнес-операция выполняется за 0,02сек (цифры абстрактные)
Человек эти операции генерить быстрее чем одна штука в 3 секунды - не в состоянии.
Вопрос - зачем мне быстрее?
По надежности - аналогично, и конечно связано с предыдущим пунктом.
Летит блок питания - берется новый, за 1000руб, из запаса или даже из магазина, на крайний случай - снимается с десктопа. 100% резервирование сервера стоит 15тыр. Если умерло ВСЕ - достается бэкап, наливается на новый сервер и поехали дальше. Поскольку базы не гигантские - перелить бэкап недолго.
Всему свои инструменты и решения, и они должны соизмеряться с задачами. Нет смысла стрелять из пушки по воробьям.
no subject
o_O
Как надёжность или скорость связаны с ценой? Цена тут вообще, имхо, никакой рояли не играет.
no subject
если Вы думаете, что сановское (делловское, НР) железо работает медленнее и ненадежнее бытовой техники. или что 15k RPM SAS медленнее какого-нибудь кавьяра или сигейта.
- это Ваше мнение. продолжайте так думать и дальше.
no subject
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
- да и не надо оно Вам. не заморачивайтесь.
no subject
no subject
Если оно оправданно - то по чему нет?
Если не требуется - то зачем брать то что не нужно?
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=523729&msg=10514488
"
Например, в Профитмеде (50 гиг, ~400 пользователей), сервак
Dell PowerEdge R900 с 4-мя шестиядерными процами Intel Xeon X7460 2,6 GHz 16Mb L3 Cache, 1066Mhz FSb, 120W TDP
64Gb Memory, 667Mhz (8x4Gb Quad Ranked FB DIMMs)
и полка MD3220 (sas) с 12 scsi-sas 2.5 дюймовыми дисками (raid 10). Одна полка стоит около 15к евро, вроде.
Это одно. Другое - на некоей ERP в некоем городе база в 25 гиг обслуживается на Proliant BL 685, 16 гиг памяти, 4x2 ядер Opteron 8222, 4 300-гиговых диска 10k на fibre channel. где-то 80 пользователей."
no subject
база - 50 Гб, 400 пользователей - должна крутиться на четырехголовом 64 гигабайтном аппарате? это ебический фейл, пример использования денег в качестве туалетной бумаги, о котором Вы сами многократно писали, - у этого сервера база может в оперативке сидеть комфортно. либо с таким дальним прицелом, что когда мощности будут использоваться на 100% - аппарат будет безнадежно устаревшим.
no subject
"
Профитмед (Россия) – крупный фармацевтический дистрибьютор.
Несмотря на относительно небольшой размер БД (~60Гб, растет на 2Гб/мес), эта база данных Firebird примечательна очень большим числом одновременных соединений, которые позволяют работать сотням аптек по всей России.
Профитмед использует 64-битную архитектуру Firebird чтобы эффективно исполь-зовать возможности современного серверного оборудования.
"
http://habrahabr.ru/blogs/personal/88708/#habracut
no subject
no subject
Как минимум - им виднее.
no subject
тот же RAC - это решение для постепенно растущего (по мере надобности) кластера, когда финансы или политика не позволяют купить мощную машину сразу. и да, экономически это во многих случаях очень выгодно, т.к. машина не стоит, загруженная на четверть в течение года. и да, моральное старение и все такое.
Моя контора например
Но с точки зрения АЙТИ - бизнес несложный. И потратить 100К на новый бульдозер всяко доходнее, чем на суперпуперсервер