Вышел Firebird 3.0

[@olku]

Один абзац и ссылки. Прям торт.

[@oldpeepper]

Да, очень содержательно…
Ну если разработчики не осилили — может кто-нибудь другой вкратце изложит почему теперь стоит выбросить MS и/или Postgree и скорее качать Firebird? Интересует качественное сравнение, а не 186 страниц перечисления и заявления: «Мы гордимся..»

[@AlexeyKovyazin]

Взвешенных сравнений СУБД не существует по нескольким причинам: 1) СУБД это инструменты, которые по хорошему должны подбираться под задачу, но из-за сложности изучения и разницы в SQL диалектах, а также в результате естественной лени :), все пытаются одну и ту же СУБД использовать для «всего». 2) Производители СУБД в подобных сравнениях всегда будут тянуть одеяло на себя (это логично), 3) Попытка ранжировать по популярности или «модности» (с учетом упоминаний в твиттере, как это делают на одном сайте, дает весьма размытые результаты — у большинства пользователей СУБД Frebird твиттера нет, что не мешает им разрабатывать и зарабатывать. 4) Сравнение СУБД — один из самых мощных источников флейма, наверное, третий после Линукс-Виндовс и Андроид-Айфоид, это тяжкое испытание.
На самом деле я понимаю, что Вы хотите прочесть — некое краткое изложение философии разработчика на Firebird, которое бы отразило легкость, качество и удобство написания кода под нее, беспроблемность деплоймента и миграции и прозрачную логику. Мы постараемся подготовить такой материал, он действительно нужен.

[@Source]

И всё-таки не помешает послать запрос на обновление http://www.sql-workbench.net/dbms_comparison.html в соответвии с новым релизом.

[@AlexeyKovyazin]

Сравнений больше чем самих СУБД развелось :) Будем работать.

[@sim_84]

а там и для 2.5 не всё корректно. Например вот это
Duplicate NULL values in unique index(*)
есть аж с версии 2.0

[@Cromathaar]

Я полагаю, вопрос в большей степени как раз и состоял в том, для какого типа задач подходит Firebird 3.0 и какие проблемы она позволяет решать?

[@miwa]

Не стОит выбрасывать привычный Вам инструмент, конечно же, хотя интересностей в тройке много. Главные описаны во втором разделе релизнот (две страницы крупным шрифтом) — полный SMP в варианте суперсервер, расширенная индивидуальная конфигурация баз, расширенная статистика и диагностика, SQL-пакеты, оконные и статистические функции, двунаправленные курсоры…

[@UnclShura]

А будет embedded версия? Или есть уже, а я слепой?

[@Regis]

Похоже, что уже есть.

[@miwa]

Из-за унификации кода теперь нет отдельной библиотеки fbembed, в embedded режиме может работать обычный сервер в зависимости от конфигурации.

[@UnclShura]

Тоесть я могу взять 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]

В целом — да, будет работать по такой схеме. Само собой за кадром остается масса деталей, которые описаны в релизнотах. Например, если в приложении есть запросы со смешанными явными и неявными джойнами (select table1.f1, table2.f2, table3.f3 from table1, table2 join table3 on… where ...), то они работать не будут. Аутентификацию опять же скорее всего надо будет перенастраивать.

[@dyemanov]

нет аутентификации в embedded ;-)

[@miwa]

Упс, да, здесь я лажанул :(

[@miwa]

Дополню свой ответ цытатой из релизнот (раздел 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]

А как с переходом со старых версий?
Недавно только с 1.5 на 2.5 переехали на работе, но еще не везде.

[@AlexeyKovyazin]

Нормально с переходом, если с 1.5 переехали, то 3.0 точно осилите. :) Главное, помнить, что просто бэкап-рестор, хоть и проходит успешно, миграцией не является, как минимум надо перекомпилировать все хранимые процедуры. В общем, читайте РелизНоты.

[@Sunflower]

Всё вроде бы тип-топ. Единственно IBExpert при регистрации базы с Server version=3.0 потом очень удивляется от двух SYSDBA

[@kylt_lichnosti]

А почему их два?
Я еще доки не читал к 3.

[@sim_84]

по одному на каждый UserManager. Если указано в конфигурации указано UserManager = Srp, Legacy_UserManager тогда их действительно будет два.

[@mail-online]

Поставил 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]

потому что там откуда ты коннектился ibexpert'ом или php стоит клиент от 2.5. Firebird 3.0 в умолчательной конфигурации использует аутентификацию с помощью SRP. Для того чтобы старый клиент коннектился надо включить Legacy_Auth. Как это сделать написано в Release Notes см. Compatibility Issues->Legacy Authentication стр. 117

[@mail-online]

Большое спасибо за информацию! Дело сдвинулось с мёртвой точки. Только эти рекомендации до конца не помогли. Получилось только когда помимо включения Legacy_Auth, скачал дистрибутив третьего под win32, и в ibexpert вместо gds32 подставил fbclient.dll из дистрибутива. С php так и не решилось, не работает. Буду экспериментировать, попробую веб сервер на машину с firebird 3 накатить, посмотрю что выйдет из этого.

[@mail-online]

Получилось из php. Надо WireCrypt = Disabled поставить вместо Enable. После этого все работает.

[@UncleAndy]

Эх… Первая «любовь». :)

[@Alcogolic]

Афигенская СУБД, особенно Embedded версия, встроил в приложение и не паришься, всё работает чётко в отдельном потоке(или нескольких потоках)

[@c0ntr0ller]

Только засобирался на одном старом проекте с FB2.5 уходить из-за серьезных проблем с безопасностью. Например, зная название генератора можно запросом с вызовом gen_id под любым входом загнать его в уже использованную область и вызвать primary key error. Может в 3.0 поправили кучу багов, сейчас почитаем…

[@miwa]

Зная имя и пароль для доступа к серверу можно много чего сделать. Запустить расчет числа пи до n-ного знака, например. Во многих потоках. Это тоже проблема с безопасностью?

[@sim_84]

права на генераторы появились, если проблема в этом

[@QValder]

Вообще в плане импортозамещения Оракла заявка мощная. PostgreSQL не потянул, ребята больше увлекались всякими рюшечками, архиудобными типами данных и прочими, а фундаментальные вещи типа автономных транзакций упущены.

[@smagen]

Не рюшечками мы увлеклись. Кластер с полноценными распределёнными транзакциями, полноценный partitioning (вначале как extension, а потом и в core), инкрементальный бэкап, масштабирование на многоядреных серверах, машинное обучение при планировании запросов – это ещё далеко не все проекты, которые сейчас в работе. Автономные транзакции в плане.
Типами данных мы занимались до основания компании, когда были сами по себе и творили, как свободные художники.

[@QValder]

Без обид, мне очень нравится, что вы натворили как свободные художники, и перечисленые проекты хороши и Постгресом я с удовольствием для себя пользуюсь. Меня только огорчает, что вы не отправили Оракл на помойку, хотя, мне кажется, могли бы.
А для этого не хватает как раз вложенной транзакционности, потому что без нее не любой оракловый проект можно мигрировать. Последнее что я слышал об автономных транзакциях в PostrgreSQL это добавление «подтранзакций», но это как раз, в основном, для логирования и годится (буду рад, если планы поменялись).
Конечно при разработке нового проекта без множественной транзакционности можно обойтись: сервер приложений, например, может распараллелить пользовательскую сессию. Но вы точно выиграете когда старые проекты можно будет мигрировать без изменения архитектуры.

[@Honeyman]

«Фундаментальные вещи типа автономных транзакций» как раз не упущены. Если автономная транзакция — это такая подтранзакция, которая может внутри транзакции записать что-то в базу, несмотря на то, что в основной транзакции случился rollback — это звучит как критическая бага во всей транзакционной модели СУБД, которая не позволяет использовать эту СУБД в хоть сколь-либо серьёзных задачах.
Насколько я понимаю, в PostgreSQL баги под названием «автономные транзакции» нет.

[@love5an]

Я так понимаю, это некоторые криворукие индивидуумы для логов используют. Вопрос правда возникает — а что мешает логировать на уровне приложение? И тут снова возвращаемся к вопросу о кривых руках.

[@QValder]

То есть, вы утверждаете, что Oracle нельзя использовать «в хоть сколь-либо серьёзных задачах»? Странно только, что некоторые компании предпочитают платить Ораклу 20 K$ на ядро (примерно) чем брать бесплатный PostgreSQL.
А если серьезно, я вот о чем говорю. Допустим есть проект на Оракле, где для распараллеливания обработки пользовательской сессии используются автономные транзакции, тогда, если дело не ограничено простым логированием, вы на PostgreSQL без изменения архитектуры уже не переползете, а вот на новый Firebird, наверняка не без проблем, но, в принципе, можно.

[@Honeyman]

Странно только, что некоторые компании предпочитают платить Ораклу 20 K$ на ядро (примерно) чем брать бесплатный PostgreSQL.

Некоторые — наоборот. Например, интернет-магазин одного сотового оператора федерального уровня прошлой осенью отказался на Oracle на всех своих серверах и всё перевёл на PostgreSQL. Разработчики не нарадовались.

[@QValder]

Разделяю их радость, кое что свое тоже перевел. Думаю, что основной предмет радости все-таки в том, что достаточно легко перевелось. Если бы биллинг сотового оператора федерального уровня (может это не тот, у которого интернет-магазин) взялись переводить на PostgreSQL, его разработчикам было бы не до радости.

[@love5an]

Юзкейс распишите-ка. А то «автономные транзакции» сами по себе попахивают, мягко говоря, кривыми руками и говнокодом. В PostgreSQL и например в MSSQL, с которыми я больше всего работал, их сделать в принципе можно, через dblink(и аналог в mssql), но как-то ни разу не слышал чтобы приходилось. Может в консерватории что-то подправить? Вы в принципе, кстати, вообще, понимаете, зачем нужны транзакции то, если возникает желание их обходить?

[@QValder]

Желание «обходить» транзакции возникает в основном как раз для логирования выполнения, что тоже не плохо (удобнее чем писать во внешний файл, хотя не обязательно надежнее).
Но принципиальнее использование автономных транзакций для запуска параллельных процессов обработки данных. Например, использовал такой подход для сборки больших хранилищ данных. Кстати, по принципу очень похож на современный Map Reduce в Big Data, только внутри распределенной базы Oracle.
Правильно ли распареллеливать обработку задачи на уровне сервера БД или на уровне сервера приложений? Спорный вопрос, часто все зависит от посторонних организационных факторов. Говнокод в смысле ненадежного, трудно поддерживаемого кода встречается в обоих вариантах как и надежный код.

[@qw1]

Совершенно непонятно, как выглядят такие транзакции в Оракле. Тут пишут, что firebird молодец, и поддерживает такие транзакции. Но у него это просто

in autonomous transaction do begin ... end

Всё полностью синхронно и никакого параллелизма. В Оракле есть fork/join?

[@QValder]

Не понял, при чем тут «полностью синхронно». Код после begin в автономной транзакции выполняется параллельно основному процессу и, если без криворукости, полностью асинхронно. Никаких блокировок не предполагается.

[@qw1]

«Полностью синхронно» — это о Firebird. А в случае с ораклом, что происходит? В Firebird в блоке in autonomous transaction общие переменные с основным скриптом, поэтому можно сделать select в этом блоке в переменные и на end они точно будут заполнены. А если выполнение асинхронное, должна быть команда ожидания/синхронизации, так?

[@QValder]

Наоборот, синхронное выполнение обусловлено наличием общих данных. Именно использование общих данных определяет точки синхронизации.
Oracle тоже видимо позволяет в автономной транзакции менять данные основной, во всяком случае пакет скомпилировался. Но ни Oracle ни Firebird не заставляют так делать, это плохая практика на любой платформе, модель акторов создавалась чтобы этого избежать.
А писать синхронный параллельный код для сервера БД — это уж эпическая криворукость. Каждая транзакция должна делать свою часть работы — изменение общих переменных или возможность изменения одних и тех же строк таблицы разными транзакциями должны быть исключены.
Если выполнение асинхронное команд ожидания/синхронизации как правило нет. Если параллельные цепочки транзакций должны выдать согласованный результат обычно используется управляющий процесс, следящий за работой других процессов.
MapReduce устроен именно так — процедуры Map и Reduce полностью асинхронны, мастер-процесс следит, когда Map подготовят файл с данными, его начинают обрабатывать Reduce.

[@qw1]

Проверил на Firebird 2.5.3 — блоки автономных транзакций не выполняются параллельно, зависимости по данным заведомо нет.

[@QValder]

Если это так то я поторопился с комплиментами Firebird'у.

[@korotky]

Всё радует, только как теперь всю базу пользователей от 2.5 проапгрейдить до SRP без сброса пароля, большой вопрос. Видимо, придётся оставаться на legacy_auth.

[@miwa]

Никак не проапргейдить: очевидный логичный результат того, что в security2.fdb хранятся только хеши, по которым пароли не восстановить. И способы хранения в 2.5 и в 3.0 кардинально отличаются, что делает невозможным прямой перенос хешей.

[@miwa]

Да.

[@PaulIsh]

Планируется ли силами основной команды поддержка ppa-репозитория для ubuntu? Или вы можете порекомендовать какой-либо поддерживающийся сообществом? Не смог пока найти репозитория с финальной версией.

Вот тут все еще бета версия.

[@dyemanov]

В debian experimental релиз уже есть, на днях Мариус перетащит его к себе в PPA (ссылка выше).

[@gloomy2]

Это на днях уже несколько подзатянулось, может кто-нибудь поделиться опытом сборки .deb для ubuntu 14.04?

[@PaulIsh]

Если у вас появится какая-то информация, то пожалуйста поделитесь ей. Тоже сильно надеялся на скорое появления пакетов под ubuntu.

[@dyemanov]

по ссылке выше теперь доступна финальная версия (в данный момент для trusty и xenial)