Comments 39
Может, они используют Firebird потому что легаси.
Вот если бы была статистика миграции с PostgreSQL на Firebird или внедрение Firebird в 2014-2015 году, это было бы интересно.
Вот если бы была статистика миграции с PostgreSQL на Firebird или внедрение Firebird в 2014-2015 году, это было бы интересно.
Во-первых, хочу отметить, что информационная система становится legacy только когда полностью прекращается ее разработка и доработка. Т.е. если система в эксплуатации 10 лет, и все еще расширяется, то она от факта своей долгой жизни не становится legacy Было выбрано решение хорошее, архитектура правильная и т.д. Далеко не у каждого разработчика в портфолио есть система, прожившая несколько лет.
Из новых внедрений — люди с Hadoop Firebird запустили, но отказываются рассказывать из-за NDA. Банк с БД в 7Тб, растущей на 1Тб в месяц — про него наверное сможем скоро рассказать. Новое облачное решение на Firebird — cloud.smeta.ru
Внедрения в традиционном сегменте можно посмотреть у РедСофта (РедБаза там правда, но все родственник Firebird), Аварды, Датакрата и т.д., и т.п.
Что касается миграции с одной СУБД на другую — вопрос поставлен неверно. Бизнес не мигрирует с одной СУБД на другую, бизнес меняет информационную систему (ERP, CRM и т.д) целиком, или модернизируют какую-то его часть. Вопрос о миграции именно СУБД мог бы стоять в случае наличия универсальной системы, работающей на нескольких СУБД, но на практике такие системы оптимизируются под любимую СУБД разработчика, а на остальные мигрируются тяп-ляп, в расчете на совместимость на уровне стандарта.
Маркетологи-евангелисты передергивают суть бизнес-трансформации в ИТ системе, выпячивая роль продукта — дескать, внедряйте X и будете в шоколаде, а вот продукт Y был плохой. А тот факт, что радикально меняется клиентская логика (и клиентский же софт), и за миграцией реально стоят ряды кодеров, аналитиков и опыт конкретных внедренцев — массово игнорируется. К тому же сам факт изменения превозносится как безусловно положительный, а устойчивую систему клеймят как legacy.
Я прекрасно понимаю, почему такие передергивания педалируют наемные маркетологи-евангелисты, но нормальные работники ИТ сферы (т.е. не склонные к флейму без пива) должны разбираться в применимости инструментов и представлять общую картину, и автоматически фильтровать маркетинговый булшит.
Из новых внедрений — люди с Hadoop Firebird запустили, но отказываются рассказывать из-за NDA. Банк с БД в 7Тб, растущей на 1Тб в месяц — про него наверное сможем скоро рассказать. Новое облачное решение на Firebird — cloud.smeta.ru
Внедрения в традиционном сегменте можно посмотреть у РедСофта (РедБаза там правда, но все родственник Firebird), Аварды, Датакрата и т.д., и т.п.
Что касается миграции с одной СУБД на другую — вопрос поставлен неверно. Бизнес не мигрирует с одной СУБД на другую, бизнес меняет информационную систему (ERP, CRM и т.д) целиком, или модернизируют какую-то его часть. Вопрос о миграции именно СУБД мог бы стоять в случае наличия универсальной системы, работающей на нескольких СУБД, но на практике такие системы оптимизируются под любимую СУБД разработчика, а на остальные мигрируются тяп-ляп, в расчете на совместимость на уровне стандарта.
Маркетологи-евангелисты передергивают суть бизнес-трансформации в ИТ системе, выпячивая роль продукта — дескать, внедряйте X и будете в шоколаде, а вот продукт Y был плохой. А тот факт, что радикально меняется клиентская логика (и клиентский же софт), и за миграцией реально стоят ряды кодеров, аналитиков и опыт конкретных внедренцев — массово игнорируется. К тому же сам факт изменения превозносится как безусловно положительный, а устойчивую систему клеймят как legacy.
Я прекрасно понимаю, почему такие передергивания педалируют наемные маркетологи-евангелисты, но нормальные работники ИТ сферы (т.е. не склонные к флейму без пива) должны разбираться в применимости инструментов и представлять общую картину, и автоматически фильтровать маркетинговый булшит.
UFO just landed and posted this here
А может потому, что куча стороннего софта который часто имеет корни из Delphi или использует FB в Embedded варианте?
У меня на работе (завод) тоже куча софта использует FB. CheckPFR, ТАСКОМ (не уверен), СПРУТ-ТП (однако более новое ПО Спрут-ОКП уже с MSSQL).
Т.е. вопрос такой: Почему они ее используют и в каком виде/обьёме?
У меня на работе (завод) тоже куча софта использует FB. CheckPFR, ТАСКОМ (не уверен), СПРУТ-ТП (однако более новое ПО Спрут-ОКП уже с MSSQL).
Т.е. вопрос такой: Почему они ее используют и в каком виде/обьёме?
>Почему они ее используют и в каком виде/обьёме?
Почему — потому что Firebird это отличная, очень удобная и мощная СУБД универсального назначения.
В каком виде и объеме — мы постараемся опубликовать рассказы о наиболее интересных разработках на Firebird.
Почему — потому что Firebird это отличная, очень удобная и мощная СУБД универсального назначения.
В каком виде и объеме — мы постараемся опубликовать рассказы о наиболее интересных разработках на Firebird.
Почему не postgresql? MySQL? Мне как разработчику на C# было бы интересно «почему FB»? Как там с ORM под нее (использовать EF от MS или nHibernate или еще что то). Что со средствами управления/администрирования для FB? BiExpert и все? Или есть еще бесплатные тулзы?
PS: А знаете какая самая распространенная и часто используемая СУБД?
PS: А знаете какая самая распространенная и часто используемая СУБД?
Я не хотел бы сваливаться во флейм по сравнению СУБД. На остальные вопросы легко может ответить Гугль :)
Уже есть разгадка ниже :-)
Такском (референт) — на ФБ однозначно. CheckPFR — тоже.
Думаю, Вы более чем правы.
Вот цитата из актуальной на текущий момент вакансии. Компания упомянута в статье.
Вот цитата из актуальной на текущий момент вакансии. Компания упомянута в статье.
Требования:
Высшее профильное образование;
Опыт проектирования и разработки реляционных СУБД, предпочтительно Firebird;
Разработка приложений на Delphi;
Опыт администрирования баз данных, починки поломанных баз данных;
Использование и опыт разработки udf функций;
Да, и в целом, количество вакансий и вилка зарплат по данной СУБД в сравнении с MySQL или PostgreSQL говорит не в пользу первой.
Ну трезубец зарплат вообще крутится где то в MSSQL-ORACLE и в разрезе их инструментов аналитики. Но при разработке приложения/сервиса/утилиты иногда нужда легковесная и удобная СУБД (а еще и бесплатная, и меж платформенная(для полного...)), и тут смотришь иногда даже на экзотические варианты.
Пример: Embedded база да еще и с доступом из разных процессов. На вскидку (FB, MySQL Embedded (но она кажись платная), MS SQL Compact, VistaDB (платная))… SQLite — как вариант но у него проблема с доступом из разных процессов.
Пример: Embedded база да еще и с доступом из разных процессов. На вскидку (FB, MySQL Embedded (но она кажись платная), MS SQL Compact, VistaDB (платная))… SQLite — как вариант но у него проблема с доступом из разных процессов.
Если планируемый объем базы исчисляется терабайтами, есть ли смысл использовать Firebird? Или лучше посмотреть в сторону MariaDB с движком TokuDB? А может, PosgreSQL?
И чем Вам не нравятся терабайты FB?
Я не знаю, потому и спрашиваю.
Про TokuDB, например, есть куча технической информации от разработчиков с подробным разъяснением, как она работает, почему такая быстрая на ряде операций, на какие объемы рассчитана.
А вот про Firebird на сайте разработчиков написано: «Database up to 20 Terabytes supported» (кстати, противоречит FAQ), что не так уж и много. Само наличие столь малого лимита может говорить о том, что СУБД в принципе не рассчитана на большие объемы.
Про TokuDB, например, есть куча технической информации от разработчиков с подробным разъяснением, как она работает, почему такая быстрая на ряде операций, на какие объемы рассчитана.
А вот про Firebird на сайте разработчиков написано: «Database up to 20 Terabytes supported» (кстати, противоречит FAQ), что не так уж и много. Само наличие столь малого лимита может говорить о том, что СУБД в принципе не рассчитана на большие объемы.
Опять же, не хочу сваливаться в сравнение СУБД, но TokuDB явный новодел, и заявлять что там все шоколадно — я бы подождал годика 2 как минимум. Заявлена поддержка многоверсионности — и прямо вот сразу все проблемы победили и всех опередили? а ведь MVCC не один десяток лет доводили до ума и в Firebird/InterBase (с 1983 года), в Постгрессе, в MSSQL далеко не сразу она появилось и не сразу в полном объеме. Не говоря уже о ролбэксегментах в самой неломаемой СУБД, но это точно флейм взовьется :)
Ну и задаться бы вопросом — когда там успели накопиться многотерабайтные БД? Какие-то длинные логи туда льют? Или научные расчеты? Какой бизнес производит столько реальных данных? В общем, на одних фрактальных индексах далеко не уедешь, делайте реальные внедрения и тогда приходите рассказывать, а пока, пусть даже с прекрасными презентациями, ни одна крупная организация из списка выше кроме как на сайт-визитку такие новоделы не поставит.
В общем, я прекрасно понимаю желание попиарить что-то еще за счет Firebird, но лучше пишите свои материалы — ведь хабравчане любят новые технологии и хорошие статьи.
Ну и задаться бы вопросом — когда там успели накопиться многотерабайтные БД? Какие-то длинные логи туда льют? Или научные расчеты? Какой бизнес производит столько реальных данных? В общем, на одних фрактальных индексах далеко не уедешь, делайте реальные внедрения и тогда приходите рассказывать, а пока, пусть даже с прекрасными презентациями, ни одна крупная организация из списка выше кроме как на сайт-визитку такие новоделы не поставит.
В общем, я прекрасно понимаю желание попиарить что-то еще за счет Firebird, но лучше пишите свои материалы — ведь хабравчане любят новые технологии и хорошие статьи.
Дык я не пиарить что-то хочу, а спрашиваю, как дела в Firebird с большими базами. Хорошо, мой вариант вы раскритиковали (допустим, я даже с вами согласен), но что с большими данными у Firebird-то?
Нормально все, есть большие БД, люди работают, базы растут. Материалов от разработчиков у нас маловато, но это беда многих проектов, мы работаем над этим — вот с докой (русской и английской) по языку SQL практически разобрались,
Приходите к нам на бесплатный семинар по большим БД, или дождитесь вебинара, который на ту же тему чуть позже будет.
Если у Вас есть конкретная область приложения, где можно создать БД в 30-40Тб, можем обсудить тесты на оборудовании наших партнеров, например. Мы недавно пытались найти область, где взять много реальных больших данных.
Логи всех пользователей Мозиллы нам не дадут, к сожалению, но если есть подобные предложения, было бы круто. Лично мне кроме сбора температурных данных с опубликованных IoT устройств ничего в голову не пришло.
Приходите к нам на бесплатный семинар по большим БД, или дождитесь вебинара, который на ту же тему чуть позже будет.
Если у Вас есть конкретная область приложения, где можно создать БД в 30-40Тб, можем обсудить тесты на оборудовании наших партнеров, например. Мы недавно пытались найти область, где взять много реальных больших данных.
Логи всех пользователей Мозиллы нам не дадут, к сожалению, но если есть подобные предложения, было бы круто. Лично мне кроме сбора температурных данных с опубликованных IoT устройств ничего в голову не пришло.
Уже не первую неделю вижу посты на хабре о том как Firebird шагает по планете и диву даюсь — неужели этот тот самый Firebird, который мы пару лет назад с таким облегчением выпилили из своего проекта, заменив на другую БД?
Выпиливали не из-за какой-то абстрактной нелюбви или из-за того, что решили что-то более модное «пощупать». Нет, выпиливали вполне оправданно, потому что к нам от клиентов сначала десятками, а потом и сотнями валились претензии о том, что программа «перестала работать с БД». Основных проблем, как сейчас помню было три:
1. Служба Firebird периодически останавливалась сама по себе.
2. Нарушение целостности данных БД. Например, FOREIGN KEY на несуществующее значение в родительской таблице — это было почти в пределах нормы.
3. DB corruption
И если против первых двух помогали какие-то костыли, то против третьего трудно было найти аргумент, утилиты для восстановления БД помогали менее чем в половине случаев.
Выпиливали не из-за какой-то абстрактной нелюбви или из-за того, что решили что-то более модное «пощупать». Нет, выпиливали вполне оправданно, потому что к нам от клиентов сначала десятками, а потом и сотнями валились претензии о том, что программа «перестала работать с БД». Основных проблем, как сейчас помню было три:
1. Служба Firebird периодически останавливалась сама по себе.
2. Нарушение целостности данных БД. Например, FOREIGN KEY на несуществующее значение в родительской таблице — это было почти в пределах нормы.
3. DB corruption
И если против первых двух помогали какие-то костыли, то против третьего трудно было найти аргумент, утилиты для восстановления БД помогали менее чем в половине случаев.
Доводилось использовать в середине 2000-х в своих проектах Firebird 1.0 и 1.5. Ничего такого не замечалось; правда, и условия были практически тепличными: с полсотни соединений одновременно, запросы максимум раз в минуту (сервер был простенький самопальный — на процессоре Duron 800 с линуксом на борту), размер базы до 50 метров.
Насколько я понимаю, речь идет о KLite от СКБ Контур.
Если мне не изменяет память, Вы использовали а) версию 1.5 (2004 года выпуска, в 2012-м то году), б) кривую UDF (не имеющую отношения к Firebird Project), которая писала не в свою область памяти, и поэтому приводила к падениям сервера и прочим проблемам, в) там были какие-то проблемы с правильным управлением транзакциями, вызванные непониманием механизма версионности записей г) и проблемы с конфигурацией Firebird.
Обратиться за профессиональной технической поддержкой Вы не захотели, на курсы разработки приложений для Firebird тоже не ходили, мою книгу и книгу Хелен Борри не читали или читали невнимательно. Без обид, но результат очевиден.
Ваши конкуренты из ТАКСОМ и других вполне себе устанавливают Firebird сотнями тысяч, т.к. Firebird идеально ведет себя в качестве встраиваемой БД, при условии правильной разработки.
Если мне не изменяет память, Вы использовали а) версию 1.5 (2004 года выпуска, в 2012-м то году), б) кривую UDF (не имеющую отношения к Firebird Project), которая писала не в свою область памяти, и поэтому приводила к падениям сервера и прочим проблемам, в) там были какие-то проблемы с правильным управлением транзакциями, вызванные непониманием механизма версионности записей г) и проблемы с конфигурацией Firebird.
Обратиться за профессиональной технической поддержкой Вы не захотели, на курсы разработки приложений для Firebird тоже не ходили, мою книгу и книгу Хелен Борри не читали или читали невнимательно. Без обид, но результат очевиден.
Ваши конкуренты из ТАКСОМ и других вполне себе устанавливают Firebird сотнями тысяч, т.к. Firebird идеально ведет себя в качестве встраиваемой БД, при условии правильной разработки.
Про проект вы угадали, в то время я имел непосредственное к нему участие, но вот пункты б-в-г, по-моему, мимо кассы, это скорее ваши домыслы. Насчет «а» — версию на тот момент уже просто не помню, хотя кажется это была всё-таки 2.x. Тем не менее, такой факт, что после смены БД, фактически ничего не меняя в коде самой программы, не было больше ни одного инцидента, связанного с БД.
Без обид, но результат очевиден.без обид, тут уже моё личное мнение, но если СУБД позволяет без каких-либо финтов ушами ломать ссылочную целостность, то это аргумент не в её пользу.
Ну если бажная UDF, то можно вообще сказать, что FB вообще не база, а недоразумение, которое данные превращает в мусор.
Могу сказать в лет, в чем была проблема, скорее всего в отложенной записи и частом использовании резет, в таком миксе база намертво падала, как и все другое.
Возможно и диск начал сыпаться.
О такой проблеме, как потеря ссылочной целостности впервые слышу, в форумах (fido/sqlru) не помню, что бы подымалась эта проблема.
Могу сказать в лет, в чем была проблема, скорее всего в отложенной записи и частом использовании резет, в таком миксе база намертво падала, как и все другое.
Возможно и диск начал сыпаться.
О такой проблеме, как потеря ссылочной целостности впервые слышу, в форумах (fido/sqlru) не помню, что бы подымалась эта проблема.
Раз уж угадал с проектом — Вы Артем, я так полагаю? :)
2% компаний ещё не успели перейти с FireBird
FireBird — серьезная СУБД промышленного класса и сравнивать ее в PostgreSQL, и тем более с MySQL имхо некорректно. Не могу похвастаться террабайтами данных, но в рамках 10- 25 Gb у нас на проекте работает как часы уже более десяти лет.
Очень жаль, что у хабраюзеров такие ассоциации (устаревшая система, легаси проекты и т.п.), ничего хорошего нет в такой демотивации разработчиков и ничего хорошего в том, что у постгреса (отдаленно, но все же ближайший конкурент) благодаря таким комментам может когда-то не оказаться такой достойной альтернативы.
Очень жаль, что у хабраюзеров такие ассоциации (устаревшая система, легаси проекты и т.п.), ничего хорошего нет в такой демотивации разработчиков и ничего хорошего в том, что у постгреса (отдаленно, но все же ближайший конкурент) благодаря таким комментам может когда-то не оказаться такой достойной альтернативы.
Вот если я сейчас принимаю решение о СУБД для CRM предприятия штатом до 1000 человек, почему мне стоит выбрать FB, а не PostgreSQL?
По какой характеристике PostgreSQL будет хуже FB?
По какой характеристике PostgreSQL будет хуже FB?
лично для меня выбор очень зависит от того, как софт будет использоваться.
Если есть перспектива передачи его другим командам на сопровождение или предполагается, например, продавать решение другим клиентам, тогда постгрес (так как он намного более популярный и распространенный). Если для вас критично репликация или там плюшки типа json, тогда, понятно, тоже постгрес.
Но если продукт нужен для внутреннего использования, нет и не предвидится проблем с установкой, настройкой или, например, железом или хостингом, тогда, на мой личный вкус, FB лучше. Лично мне больше нравиться его архитектура (superclassic) и возможности в этом плане (например для редко запускаемых вещей можно вообще не держать демон, достаточно классик). Меньше типов заставляет разработчика держаться в рамках. Он намного более строгий в плане работы: например о несуществующем столбце вы узнаете на этапе компиляции тригера а не при выполнении как в постгресе. Для сложных запросов, если нет необходимости в дополнительном индексе, можно указать план для запроса.
Главное, наверное, все же строгость: если у вас работает среднестатистическая команда разрабов, иногда бывает очень трудно удержать их в рамках одной доменной модели и не городить свои огороды с множеством самых примитивных ошибок. С FB, по моим ощущениям, проще.
Если есть перспектива передачи его другим командам на сопровождение или предполагается, например, продавать решение другим клиентам, тогда постгрес (так как он намного более популярный и распространенный). Если для вас критично репликация или там плюшки типа json, тогда, понятно, тоже постгрес.
Но если продукт нужен для внутреннего использования, нет и не предвидится проблем с установкой, настройкой или, например, железом или хостингом, тогда, на мой личный вкус, FB лучше. Лично мне больше нравиться его архитектура (superclassic) и возможности в этом плане (например для редко запускаемых вещей можно вообще не держать демон, достаточно классик). Меньше типов заставляет разработчика держаться в рамках. Он намного более строгий в плане работы: например о несуществующем столбце вы узнаете на этапе компиляции тригера а не при выполнении как в постгресе. Для сложных запросов, если нет необходимости в дополнительном индексе, можно указать план для запроса.
Главное, наверное, все же строгость: если у вас работает среднестатистическая команда разрабов, иногда бывает очень трудно удержать их в рамках одной доменной модели и не городить свои огороды с множеством самых примитивных ошибок. С FB, по моим ощущениям, проще.
Объясните, какой профит даёт «меньше типов» и что значит «держаться в рамках»?
Это про какой-то каст данных в хранимых процедурах?
Это про какой-то каст данных в хранимых процедурах?
Я имею ввиду просто меньшее разнообразие типов в FB. Бывают ситуации, когда это заставляет более осмысленно относиться к выбору типа для поля, что ли. Очень неприятно, например, иногда бывает разгребать схему, где предназначенное для одних и тех же целей поле в разных таблицах имеет разный тип, а если еще и наделают доменов, тогда еще хуже.
И ещё вопрос про FB, я им не пользуюсь с 2008 года. Там всё так же нет автоинкремента для primary key и надо генераторы/триггеры писать?
как в MySQL нет, конечно. И да, надо создать генератор и триггер.
Но здесь как раз от PostgreSQL отличие в том, что вы делаете ето ЯВНО. Постгрес для вашего serial типа создаст все тот же генератор (sequence) и, опять же, надо не забыть ручками проставить правильные права/владельца именно на sequence. Другими словами, разрешая кому-то добавление данных в таблицу в постгрес, обязательно проверьте права на генератор, иначе — ошибка при добавлении. Т.е. вы права-то дали, а на самом деле и нет. Вот как раз таких мелких «нестрогих» вещей в FB нет и в этом, как по мне, его прелесть :).
Но здесь как раз от PostgreSQL отличие в том, что вы делаете ето ЯВНО. Постгрес для вашего serial типа создаст все тот же генератор (sequence) и, опять же, надо не забыть ручками проставить правильные права/владельца именно на sequence. Другими словами, разрешая кому-то добавление данных в таблицу в постгрес, обязательно проверьте права на генератор, иначе — ошибка при добавлении. Т.е. вы права-то дали, а на самом деле и нет. Вот как раз таких мелких «нестрогих» вещей в FB нет и в этом, как по мне, его прелесть :).
Не надо. Уже давно есть IDENTITY COLUMN.
Если Вы ИТ-директор, то могу Вам посоветовать — не выбирайте ни то, ни другое. CRM это стандартный функционал, давно формализованный и реализованный (в т.ч. много вариантов есть на Firebird).
Выберите готовый или даже «облачный» вариант с хорошим АПИ для экспорта и импорта данных, и прикрутите к нему свои расширения. Это в разы быстрее будет, чем писать свой CRM.
Выберите готовый или даже «облачный» вариант с хорошим АПИ для экспорта и импорта данных, и прикрутите к нему свои расширения. Это в разы быстрее будет, чем писать свой CRM.
Магнит в этом списке и со знаком плюс и со знаком минус. В больших БД Firebird в нем не прижился и от него отказались.
Sign up to leave a comment.
FirebirdSQL используют 11 компаний из списка ТОП-500 России