Сегодня вышел Firebird 3.0 — шестой основной релиз СУБД Firebird, и он же — самый значительный по масштабу изменений с момента выхода 1-й версии в 2002 году,.
Архитектура Firebird 3.0 была переработана и теперь полностью поддерживает многопоточность с масштабированием до сотен ядер, эффективно поддерживается большое количество RAM. Согласно результатам нагрузочных тестов OLTP, имитирующим интенсивные вставки и изменения, скорость работы в сценариях с сотнями пользователей у Firebird 3.0 по сравнению с 2.5 возросла в ~5 раз.
Помимо масштабирования и производительности, релиз Firebird 3.0 включает в себя возможности шифрование БД, трафика, и более 100 новшеств в области SQL и безопасности — они подробно описаны в release notes и документации по языку SQL (на русском языке).
Самые важные ссылки по Firebird 3:
- Скачать Firebird 3.0 (обязательно читать Release Notes, 186 страниц!), пресс-релиз на русском языке,
- Документация по SQL Firebird 3 на русском языке, пошаговые примеры разработки приложений для СУБД Firebird 3: Для Delphi, Для .NET (EntityFramework, C#)
- Презентация "Новые возможности Firebird 3.0"
- Руководство для начинающих (Quick Start Guide, на английском)
- Список инструментов и драйверов для Firebird
- Еще документация и полезные материалы о Firebird на русском языке
Комментарии (52)
oldpeepper
19.04.2016 17:50+1Да, очень содержательно…
Ну если разработчики не осилили — может кто-нибудь другой вкратце изложит почему теперь стоит выбросить MS и/или Postgree и скорее качать Firebird? Интересует качественное сравнение, а не 186 страниц перечисления и заявления: «Мы гордимся..»
AlexeyKovyazin
19.04.2016 18:02+8Взвешенных сравнений СУБД не существует по нескольким причинам: 1) СУБД это инструменты, которые по хорошему должны подбираться под задачу, но из-за сложности изучения и разницы в SQL диалектах, а также в результате естественной лени :), все пытаются одну и ту же СУБД использовать для «всего». 2) Производители СУБД в подобных сравнениях всегда будут тянуть одеяло на себя (это логично), 3) Попытка ранжировать по популярности или «модности» (с учетом упоминаний в твиттере, как это делают на одном сайте, дает весьма размытые результаты — у большинства пользователей СУБД Frebird твиттера нет, что не мешает им разрабатывать и зарабатывать. 4) Сравнение СУБД — один из самых мощных источников флейма, наверное, третий после Линукс-Виндовс и Андроид-Айфоид, это тяжкое испытание.
На самом деле я понимаю, что Вы хотите прочесть — некое краткое изложение философии разработчика на Firebird, которое бы отразило легкость, качество и удобство написания кода под нее, беспроблемность деплоймента и миграции и прозрачную логику. Мы постараемся подготовить такой материал, он действительно нужен.
Source
19.04.2016 18:12И всё-таки не помешает послать запрос на обновление http://www.sql-workbench.net/dbms_comparison.html в соответвии с новым релизом.
sim_84
19.04.2016 18:25+1а там и для 2.5 не всё корректно. Например вот это
Duplicate NULL values in unique index(*)
есть аж с версии 2.0
Cromathaar
20.04.2016 10:37+1Я полагаю, вопрос в большей степени как раз и состоял в том, для какого типа задач подходит Firebird 3.0 и какие проблемы она позволяет решать?
miwa
19.04.2016 19:08+1Не стОит выбрасывать привычный Вам инструмент, конечно же, хотя интересностей в тройке много. Главные описаны во втором разделе релизнот (две страницы крупным шрифтом) — полный SMP в варианте суперсервер, расширенная индивидуальная конфигурация баз, расширенная статистика и диагностика, SQL-пакеты, оконные и статистические функции, двунаправленные курсоры…
UnclShura
19.04.2016 19:17+3А будет embedded версия? Или есть уже, а я слепой?
miwa
20.04.2016 12:09Из-за унификации кода теперь нет отдельной библиотеки fbembed, в embedded режиме может работать обычный сервер в зависимости от конфигурации.
UnclShura
20.04.2016 12:24Тоесть я могу взять C# клиент, положить firebird.conf c RootDirectory = D:\FbEmbedded рядом с приложением, скопировать сервер (без инсталяции!) в D:\FbEmbedded ну или рядом с приложением, источником указать файл и все будет работать? Или как? Документация пока старая и упоминает fbembed.dll: http://www.firebirdsql.org/manual/ufb-cs-embedded.html#ufb-cs-embedded-windows.
miwa
20.04.2016 12:54В целом — да, будет работать по такой схеме. Само собой за кадром остается масса деталей, которые описаны в релизнотах. Например, если в приложении есть запросы со смешанными явными и неявными джойнами (select table1.f1, table2.f2, table3.f3 from table1, table2 join table3 on… where ...), то они работать не будут. Аутентификацию опять же скорее всего надо будет перенастраивать.
miwa
20.04.2016 12:17Дополню свой ответ цытатой из релизнот (раздел Server Modes, страница 7):
When «database name» does not contain a network protocol but just the database name, the Remote provider
rejects it and the Engine12 provider comes to the fore and tries to open the named database file. If it succeeds,
we get an embedded connection to the database.
Note
A special “embedded library” is no longer required. To make the embedded connection, the standard client
loads the appropriate provider and becomes an embedded server.
kylt_lichnosti
19.04.2016 19:18А как с переходом со старых версий?
Недавно только с 1.5 на 2.5 переехали на работе, но еще не везде.AlexeyKovyazin
19.04.2016 19:19+2Нормально с переходом, если с 1.5 переехали, то 3.0 точно осилите. :) Главное, помнить, что просто бэкап-рестор, хоть и проходит успешно, миграцией не является, как минимум надо перекомпилировать все хранимые процедуры. В общем, читайте РелизНоты.
Sunflower
20.04.2016 08:02Всё вроде бы тип-топ. Единственно IBExpert при регистрации базы с Server version=3.0 потом очень удивляется от двух SYSDBA
kylt_lichnosti
20.04.2016 10:21А почему их два?
Я еще доки не читал к 3.sim_84
20.04.2016 12:01по одному на каждый UserManager. Если указано в конфигурации указано UserManager = Srp, Legacy_UserManager тогда их действительно будет два.
mail-online
19.04.2016 20:00Поставил Linux AMD64 Firebird-3.0.0.32483-0.amd64.tar.gz
Прямо беда какая-то, убил весь вечер, так и не сделал. Телнетом 3050 порт видит слюбого сервера, из isql с другого сервера (тоже с установленным firebird 3.0) коннектиться без проблем к базе, gbak-ом база извлеклось… но, ни из ibexperta, ни из php (причем с разных серверов, и виндовый и линуксовый, на линкуксе даже php5-interbase обновил) никак. Вообще никак не коннектится, всегда ошибка «connection rejected by remote interface».
В общем работать можно только из /opt/firebird/bin/isql при установленном firebird 3.0. Толку от такого обновления никакого…sim_84
19.04.2016 22:34+3потому что там откуда ты коннектился ibexpert'ом или php стоит клиент от 2.5. Firebird 3.0 в умолчательной конфигурации использует аутентификацию с помощью SRP. Для того чтобы старый клиент коннектился надо включить Legacy_Auth. Как это сделать написано в Release Notes см. Compatibility Issues->Legacy Authentication стр. 117
mail-online
20.04.2016 12:33Большое спасибо за информацию! Дело сдвинулось с мёртвой точки. Только эти рекомендации до конца не помогли. Получилось только когда помимо включения Legacy_Auth, скачал дистрибутив третьего под win32, и в ibexpert вместо gds32 подставил fbclient.dll из дистрибутива. С php так и не решилось, не работает. Буду экспериментировать, попробую веб сервер на машину с firebird 3 накатить, посмотрю что выйдет из этого.
mail-online
20.04.2016 12:37Получилось из php. Надо WireCrypt = Disabled поставить вместо Enable. После этого все работает.
Alcogolic
20.04.2016 00:53+3Афигенская СУБД, особенно Embedded версия, встроил в приложение и не паришься, всё работает чётко в отдельном потоке(или нескольких потоках)
c0ntr0ller
20.04.2016 08:02Только засобирался на одном старом проекте с FB2.5 уходить из-за серьезных проблем с безопасностью. Например, зная название генератора можно запросом с вызовом gen_id под любым входом загнать его в уже использованную область и вызвать primary key error. Может в 3.0 поправили кучу багов, сейчас почитаем…
miwa
20.04.2016 08:29+3Зная имя и пароль для доступа к серверу можно много чего сделать. Запустить расчет числа пи до n-ного знака, например. Во многих потоках. Это тоже проблема с безопасностью?
QValder
20.04.2016 12:33-3Вообще в плане импортозамещения Оракла заявка мощная. PostgreSQL не потянул, ребята больше увлекались всякими рюшечками, архиудобными типами данных и прочими, а фундаментальные вещи типа автономных транзакций упущены.
smagen
21.04.2016 13:53+2Не рюшечками мы увлеклись. Кластер с полноценными распределёнными транзакциями, полноценный partitioning (вначале как extension, а потом и в core), инкрементальный бэкап, масштабирование на многоядреных серверах, машинное обучение при планировании запросов – это ещё далеко не все проекты, которые сейчас в работе. Автономные транзакции в плане.
Типами данных мы занимались до основания компании, когда были сами по себе и творили, как свободные художники.QValder
22.04.2016 23:33Без обид, мне очень нравится, что вы натворили как свободные художники, и перечисленые проекты хороши и Постгресом я с удовольствием для себя пользуюсь. Меня только огорчает, что вы не отправили Оракл на помойку, хотя, мне кажется, могли бы.
А для этого не хватает как раз вложенной транзакционности, потому что без нее не любой оракловый проект можно мигрировать. Последнее что я слышал об автономных транзакциях в PostrgreSQL это добавление «подтранзакций», но это как раз, в основном, для логирования и годится (буду рад, если планы поменялись).
Конечно при разработке нового проекта без множественной транзакционности можно обойтись: сервер приложений, например, может распараллелить пользовательскую сессию. Но вы точно выиграете когда старые проекты можно будет мигрировать без изменения архитектуры.
Honeyman
22.04.2016 08:22+2«Фундаментальные вещи типа автономных транзакций» как раз не упущены. Если автономная транзакция — это такая подтранзакция, которая может внутри транзакции записать что-то в базу, несмотря на то, что в основной транзакции случился rollback — это звучит как критическая бага во всей транзакционной модели СУБД, которая не позволяет использовать эту СУБД в хоть сколь-либо серьёзных задачах.
Насколько я понимаю, в PostgreSQL баги под названием «автономные транзакции» нет.
love5an
22.04.2016 20:23+1Я так понимаю, это некоторые криворукие индивидуумы для логов используют. Вопрос правда возникает — а что мешает логировать на уровне приложение? И тут снова возвращаемся к вопросу о кривых руках.
QValder
22.04.2016 23:04То есть, вы утверждаете, что Oracle нельзя использовать «в хоть сколь-либо серьёзных задачах»? Странно только, что некоторые компании предпочитают платить Ораклу 20 K$ на ядро (примерно) чем брать бесплатный PostgreSQL.
А если серьезно, я вот о чем говорю. Допустим есть проект на Оракле, где для распараллеливания обработки пользовательской сессии используются автономные транзакции, тогда, если дело не ограничено простым логированием, вы на PostgreSQL без изменения архитектуры уже не переползете, а вот на новый Firebird, наверняка не без проблем, но, в принципе, можно.Honeyman
23.04.2016 01:19Странно только, что некоторые компании предпочитают платить Ораклу 20 K$ на ядро (примерно) чем брать бесплатный PostgreSQL.
Некоторые — наоборот. Например, интернет-магазин одного сотового оператора федерального уровня прошлой осенью отказался на Oracle на всех своих серверах и всё перевёл на PostgreSQL. Разработчики не нарадовались.QValder
23.04.2016 01:39Разделяю их радость, кое что свое тоже перевел. Думаю, что основной предмет радости все-таки в том, что достаточно легко перевелось. Если бы биллинг сотового оператора федерального уровня (может это не тот, у которого интернет-магазин) взялись переводить на PostgreSQL, его разработчикам было бы не до радости.
love5an
22.04.2016 20:21+1Юзкейс распишите-ка. А то «автономные транзакции» сами по себе попахивают, мягко говоря, кривыми руками и говнокодом. В PostgreSQL и например в MSSQL, с которыми я больше всего работал, их сделать в принципе можно, через dblink(и аналог в mssql), но как-то ни разу не слышал чтобы приходилось. Может в консерватории что-то подправить? Вы в принципе, кстати, вообще, понимаете, зачем нужны транзакции то, если возникает желание их обходить?
QValder
23.04.2016 00:35+1Желание «обходить» транзакции возникает в основном как раз для логирования выполнения, что тоже не плохо (удобнее чем писать во внешний файл, хотя не обязательно надежнее).
Но принципиальнее использование автономных транзакций для запуска параллельных процессов обработки данных. Например, использовал такой подход для сборки больших хранилищ данных. Кстати, по принципу очень похож на современный Map Reduce в Big Data, только внутри распределенной базы Oracle.
Правильно ли распареллеливать обработку задачи на уровне сервера БД или на уровне сервера приложений? Спорный вопрос, часто все зависит от посторонних организационных факторов. Говнокод в смысле ненадежного, трудно поддерживаемого кода встречается в обоих вариантах как и надежный код.
qw1
24.04.2016 15:05Совершенно непонятно, как выглядят такие транзакции в Оракле. Тут пишут, что firebird молодец, и поддерживает такие транзакции. Но у него это просто
in autonomous transaction do begin ... end
Всё полностью синхронно и никакого параллелизма. В Оракле есть fork/join?QValder
24.04.2016 19:14Не понял, при чем тут «полностью синхронно». Код после begin в автономной транзакции выполняется параллельно основному процессу и, если без криворукости, полностью асинхронно. Никаких блокировок не предполагается.
qw1
24.04.2016 21:41«Полностью синхронно» — это о Firebird. А в случае с ораклом, что происходит? В Firebird в блоке
in autonomous transactionобщие переменные с основным скриптом, поэтому можно сделать select в этом блоке в переменные и наendони точно будут заполнены. А если выполнение асинхронное, должна быть команда ожидания/синхронизации, так?QValder
24.04.2016 23:22+1Наоборот, синхронное выполнение обусловлено наличием общих данных. Именно использование общих данных определяет точки синхронизации.
Oracle тоже видимо позволяет в автономной транзакции менять данные основной, во всяком случае пакет скомпилировался. Но ни Oracle ни Firebird не заставляют так делать, это плохая практика на любой платформе, модель акторов создавалась чтобы этого избежать.
А писать синхронный параллельный код для сервера БД — это уж эпическая криворукость. Каждая транзакция должна делать свою часть работы — изменение общих переменных или возможность изменения одних и тех же строк таблицы разными транзакциями должны быть исключены.
Если выполнение асинхронное команд ожидания/синхронизации как правило нет. Если параллельные цепочки транзакций должны выдать согласованный результат обычно используется управляющий процесс, следящий за работой других процессов.
MapReduce устроен именно так — процедуры Map и Reduce полностью асинхронны, мастер-процесс следит, когда Map подготовят файл с данными, его начинают обрабатывать Reduce.
korotky
20.04.2016 12:34Всё радует, только как теперь всю базу пользователей от 2.5 проапгрейдить до SRP без сброса пароля, большой вопрос. Видимо, придётся оставаться на legacy_auth.
miwa
20.04.2016 12:45+1Никак не проапргейдить: очевидный логичный результат того, что в security2.fdb хранятся только хеши, по которым пароли не восстановить. И способы хранения в 2.5 и в 3.0 кардинально отличаются, что делает невозможным прямой перенос хешей.
PaulIsh
25.04.2016 10:15Планируется ли силами основной команды поддержка ppa-репозитория для ubuntu? Или вы можете порекомендовать какой-либо поддерживающийся сообществом? Не смог пока найти репозитория с финальной версией.
Вот тут все еще бета версия.dyemanov
25.04.2016 14:53+1В debian experimental релиз уже есть, на днях Мариус перетащит его к себе в PPA (ссылка выше).
olku
Один абзац и ссылки. Прям торт.