Однако это тот самый случай, когда «мал, да удал». Есть масса примеров, где многогигабайтные базы работают сразу с сотнями клиентов. А на выставке «Софтул’2006» (26-28 сентября) компания «Ансофт» представит стенд из «живых» рабочих станций и сервера, имитирующий одновременную работу сотни пользователей со 120-гигабайтной базой Firebird, которая моделирует функционирование крупного торгового холдинга в режиме «уплотненного» времени под управлением ERP.
У нас многие разработчики, особенно те, что сидят за забором режимного предприятия, слишком свободно относятся к лицензированию… Не надо быть семи пядей во лбу, чтобы догадаться, что подобная «малина» кончится со вступлением в ВТО и что по мере накопления опыта правоохранительными органами антипиратская активность будет только нарастать. Но одно дело, когда ты пользуешься ворованным софтом за сто долларов у себя дома, и совсем другое, когда предлагаешь солидному заказчику «спереть» СУБД… Ну или доплатить полсотни тысяч евро.
Кстати, «новые бесплатные» СУБД от Oracle, MS SQL и другие не позволяют добиться того же- смехотворные ограничения (прежде всего на размер базы в 4Гбайт) не смогут удовлетворить мало-мальски серьезную организацию и пригодны только в качестве сыра [См. «Виды бесплатного сыра», «КТ» #640 от 01.06.06.] в мышеловке… Но и «мыши» нынче пошли не глупые.
Однако есть мнение, что…
Надо признать, что этот миф очень распространен. Причина его возникновения, наверное, в том, что Firebird практически не требует администрирования и постоянной настройки, достаточно осуществлять регулярный (чаще всего автоматический) бэкап, и если приложение правильно спроектировано, оно работает годами «без рук». Многие администраторы [Уточним- люди, выполняющие их обязанности, чтобы не обижать грамотных сисадминов сравнениями с такими «специалистами»] злоупотребляют неприхотливостью Firebird и ставят ее на компьютеры без UPS, позволяют себе жать на Reset по поводу и без повода и бить ногой по серверу в случае неполадок. Особо экономные администраторы ставят Firebird на компьютер к какому-нибудь несчастному пользователю- вот, дескать, это и будет наш сервер.
Из-за большого количества установок в экстремальных условиях на бытовых компьютерах и несоблюдения элементарных «правил гигиены» для серверного продукта (бэкапы, бэкапы!!!) можно видеть множество поврежденных баз, красные глаза горе-администраторов и не менее красные (но по другой причине) глаза владельцев бизнеса… Что ж поделать, кроме как вспоминать анекдот про дровосеков, новую японскую пилу и стальные рельсы? ["Дзынь!"- сказала пила. «Не смогла!»- удовлетворенно хмыкнули дровосеки]
Вспомнив про новую пилу, вспомним и то, что…
И вот это уже не миф, а чистейшая правда, которая по неизвестной причине подается как нечто плохое и постыдное. И действительно, СУБД Firebird основана на многоверсионной архитектуре записей, впервые примененной еще в InterBase в далеком 1984-м. Подобная архитектура применялась и в Microsoft Exchange и PostgreSQL, тогда как остальные СУБД исповедовали «блокировочный» подход. Но совсем недавно идея версионности записей вдруг опять получила большую популярность и была (частично) реализована в MSSQL 2005! При этом версионность подается как новейшее изобретение, позволяющее «читателям» не блокировать «писателей»…. Ну а то, что «изобретению» уже 20 лет, только подтверждает правило, что все новое - это хорошо забытое старое.
И еще к вопросу о «свежих» технологиях: недавно MySQL AB «купила» отца-основателя InterBase (и участника проекта Firebird) Джима Старки, заказав ему разработку версионного «движка» Falcon для применения в MySQL. Теперь есть риск, что туда просочатся и…
Конечно, утверждать, что Firebird- идеальна, было бы глупо (нет в мире совершенства, увы). К наибольшим недостаткам этой системы относятся трудности масштабирования на несколько процессоров (поддерживается лишь архитектурой Classic, обладающей повышенными требованиями к объему оперативной памяти) и неоптимальной реализацией сетевого протокола, что очень заметно на медленных линиях связи. Но в версии 2.1, чей выпуск запланирован на конец текущего года, уже исправлены и злополучный протокол, и вылечены многие другие «мозоли», преследующие в том числе и…
У нас живут и творят главные архитекторы и разработчики Firebird: Дмитрий Еманов, Влад Хорсун и Алекс Пешков. Firebird- проект интернациональный, его участники работают в Германии, Австралии, Бразилии, США. Однако наши разработчики сумели занять ведущее место среди более чем пятидесяти контрибуторов проекта. Ну а поддержкой Firebird в мире занимается некоммерческая организация Firebird Foundation, с благословения которой пройдет…
Конференция, намеченная на 14 октября, состоится в Москве. На ней будут присутствовать все ведущие разработчики Firebird, создатели инструментов, библиотек и компонентов для этой СУБД. Производители интересных решений на базе Firebird с удовольствием поделятся своим опытом не только с трибуны, но и в кулуарах. Ну а чтобы зарегистрироваться, загляните на сайт компании-организатора конференцииiBase.
Firebird применяется в основном для небольших и средних встраиваемых приложений, то есть когда сервер ставится в комплекте какого-то приложения (бухгалтерского или складско-учетного) и работает в «невидимом» для пользователей режиме.
Конечно, стенд с ERP Avarda вызывает интерес, было бы очень любопытно на него взглянуть, но решения такого объема (десятки гигабайт) для Firebird скорее редкость.
Также можно отметить, что в крупных компаниях Firebird в основном используется как «вспомогательная» база данных- когда нецелесообразно ставить большую БД (с неизбежным администратором) в небольшой филиал или удаленное подразделение, в этом случае в качестве «заменителя» часто выбирают именно Firebird.
В одной очень крупной российской страховой компании (входящей в тройку лидеров) основную базу данных держат на Oracle, тем не менее Firebird стоит в каждом офисе, а данные из нее заливаются в центральное хранилище для последующей обработки. Собственно, из-за такой второстепенной роли в больших компаниях никто особо и не говорит о Firebird, она просто «не попадается на глаза» ИТ-менеджменту: бюджета для покупки она не требует, шумихи в Интернете про нее тоже нет. Этакая рабочая лошадка, вроде «Газели», ездит и ездит.
Помимо относительно узкой ниши на корпоративном рынке, у Firebird есть несколько особенностей, переходящих в недостатки: во-первых, очень маленький аскетичный дистрибутив, не включающий развитых средств администрирования, которые потом приходится устанавливать отдельно; и во-вторых, ограничения SQL, которые делают разработку хранимых процедур непохожей на MS SQL или Oracle: отсутствие временных таблиц и внешних хранимых процедур.
Разработчики, конечно, работают в этом направлении, но пока Firebird не в состоянии конкурировать с признанными лидерами вроде MS SQL или Oracle на действительно больших проектах.