LINUX.ORG.RU

Вышла СУБД Firebird 2.5

 , ,


0

0

Firebird — свободная кроссплатформенная система управления базами данных для GNU/Linux (других POSIX-совместимых ОС) и Microsoft Windows. Основана на исходном коде свободной версии Interbase 6.0 от Borland, выпущенной в 2000 году.

Основные изменения:

  • многопоточная обработка запросов, использующая преимущества симметричной многопроцессорной обработки (SMP), которая значительно повышает производительность на многопроцессорных и многоядерных системах;
  • встроенные библиотеки libfbembed.so (POSIX) и fbembed.dll (Windows) теперь поддерживают многопоточные и поточно-ориентированные вызовы.

Также добавлены новые возможности и улучшения:

  • система аудита и трассировки запросов через Services API, позволяющая отслеживать и анализировать изменения БД в режиме реального времени;
  • отслеживание пользователем своих соединений;
  • более подробная информация в таблицах мониторинга;
  • управление учётными записями с помощью SQL-выражения «CREATE/ALTER/DROP USER»;
  • дополнительное предоставление/аннулирование прав пользователю, отличного от текущего (по умолчанию);
  • встроенные функции для преобразования строк UUID CHAR (16) OCTETS в RFC4122-совместимый формат и наоборот;
  • результаты запросов, согласно стандарту SQL-2003 — возврат 5-символьного кода завершения операции (SQLSTATE);
  • и другие.

Страница загрузки

>>> Подробности

★★★★★

Проверено: svu ()

ох счщит... как борланд жала все свои дальнейшие наработки, открыли, потом прикрыли...

а оно вот как обернулось, от борланда на рынке и след простыл, а Интербейз еще шевелится.

Deleted ()

Оно кому-нибудь нужно в век, когда PostgreSQL имеет нативную потоковую репликацию?

anonymous ()
Ответ на: комментарий от anonymous

Например, там, где SQLite уже мало, а Postgresql - еще много.

yaws ()

отвратительно нестабильная СУБД.

boo32 ()
Ответ на: комментарий от boo32

совершенно не согласен. 3 года интенсивной работы FB 1.5.3 на продакшене, ни одного сбоя по вине FB..

sur02111976 ()
Ответ на: комментарий от boo32

угу. 8 лет в продакшне - ни одного гемороя.

anonymous ()
Ответ на: комментарий от anonymous

> Оно кому-нибудь нужно в век, когда PostgreSQL имеет нативную потоковую репликацию?

Например тому, кто много лет живет с Firebird (мигрировав с Interbase). Я понимаю что вы посоветуете все выкинуть и переписать на Postgre - но боюсь что финансировать откажетесь.

ISanych ()
Ответ на: комментарий от boo32

> отвратительно нестабильная СУБД.

Вы, наверное, имеете в виду Interbase. Firebird вроде неплоха.

northerner ★★★ ()
Ответ на: комментарий от dimich33

>FB 2.1.2, база более 30 гигов

Ого. И для чего вы её используете, если не секрет?

anonymous ()

Поздно ... все проекты давно переписаны на PostgreSQL ...

I_one ()
Ответ на: комментарий от anonymous

10 лет на продакшине. Нареканий к текущей 1.5 нет

cab ★★★★ ()

>>управление аккаунтами с помощью SQL-выражения «CREATE/ALTER/DROP USER»;

А как было до этого Guinness event-a? Аккаунты самозарождались?

anonymous ()
Ответ на: комментарий от cab

Тоже 10, версии до 2.0.4 включительно. Полет нормальный.

Даже в условиях где могут по питанию несколько раз в день тачку ребутать.

anc ★★★★★ ()
Ответ на: комментарий от dimich33

FB 2.1.2, база более 30 гигов

Ого. И для чего вы её используете, если не секрет?

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

dimich33 ()

мда, похоже субд без будущего. в 2004 году по планам должен был выйти firebird 3.0 с нормальным SMP, сегодня у нас 2010 и нормальным SMP не пахнет. судя по всему товарищам еще лет 5 понадобиться, чтоб допилить это чудо-субд до наворотов которые были еще в mysql 4. и что плохо - с каждым годом firebird все больше отстает от postgres и mysql.
еще в mysql4 был единый буферный пул, кеш под SQL, бинарный лог, архитектура superserver с SMP. когда все это появиться в firebird разрыв с mysql6 будет гигантский, postgres будет уже просто не досигаем.

anonymous ()
Ответ на: комментарий от anonymous

управление аккаунтами с помощью SQL-выражения «CREATE/ALTER/DROP USER»;

А как было до этого Guinness event-a? Аккаунты самозарождались?

Через Services API

dimich33 ()
Ответ на: комментарий от boo32

> отвратительно нестабильная СУБД.

Подтверждаю, говнецо еще то. Если база по ходу своей жизнедеятельности раздувается до нескольких мегабайт, то все работает через жопу. Зато если сделать дамп и восстановиться из него - о чудо! все снова работает, и размер уменьшается в разы. Пока снова не засрется.

anonymous ()
Ответ на: комментарий от anonymous

>Если база по ходу своей жизнедеятельности раздувается до нескольких мегабайт, то все работает через жопу

I mean нескольких гигабайт

anonymous ()
Ответ на: комментарий от anonymous

> еще в mysql4 был единый буферный пул, кеш под SQL, бинарный лог, архитектура superserver с SMP

SMP? В MySQL 4? Конечно, могу ошибаться, но патчи для SMP в MySQL были добавлены то ли в ветку 5.4, то ли в 5.5.

sjinks ★★★ ()
Ответ на: комментарий от anonymous

Подтверждаю, говнецо еще то. Если база по ходу своей жизнедеятельности раздувается до нескольких мегабайт, то все работает через жопу. Зато если сделать дамп и восстановиться из него - о чудо! все снова работает, и размер уменьшается в разы. Пока снова не засрется.

Из Firebird FAQ :

В версионном движке при удалении записей свободное место не возникает, а наоборот, возникают новые версии, т.е. файл базы данных может увеличиться. Эти версии будут находиться в базе данных до тех пор, пока не будут убраны как мусор. И даже в этом случае файл базы не уменьшится, просто в нем будет больше свободного пространства для новых или измененных данных.

Так что это фича. При этом глюков не было

dimich33 ()
Ответ на: комментарий от dimich33

Так что это фича. При этом глюков не было


из-за этой фичи всем приходиться читать кучу пустых/полупустых блоков раздувшихся таблиц вместо полезных данных. херово на перфомнс влияет

anonymous ()
Ответ на: комментарий от sjinks

SMP? В MySQL 4? Конечно, могу ошибаться, но патчи для SMP в MySQL были добавлены то ли в ветку 5.4, то ли в 5.5.


отчетливо помню, что долго искали какого mysql 4 на 4х процессорах масштабировался практически линейно, а дальше громадный провал. вроде потом нашли глючек в реализации линуксовых тхредах. единый кеш (буферный пул) для всех конектов в SMP в mysql4 точно было, может там нюансы какие были, нужно покопать.

anonymous ()
Ответ на: комментарий от anonymous

из-за этой фичи всем приходиться читать кучу пустых/полупустых блоков раздувшихся таблиц вместо полезных данных. херово на перфомнс влияет

В моем случае на перфомнс сильно не влияло. Не имея под рукой проблемной базы сложно понять причину падения производительности

dimich33 ()
Ответ на: комментарий от djenterprise

> не нужно

совсем.

PostgreSQL/mySQL/ SQL Server/Oracle


все



Спасибо за столь авторитетное мнение. Просветили всех незрячих. Все что уже написано вы лично перепишете? быстро и бесплатно?
Напомните, пожалуйста, как зовется аналог Firebird embedded в вышеприведенных БД.

ISanych ()
Ответ на: комментарий от djenterprise

Где в MySQL управление транзакциями, где многоверсионность

anonymous ()
Ответ на: комментарий от djenterprise

Сравнивать mySQl и Firebird это как сравнить Трактор и Легковой автомобиль.

anonymous ()
Ответ на: комментарий от ISanych

>Напомните, пожалуйста, как зовется аналог Firebird embedded в вышеприведенных БД.

+1

Вот только про него хотел написать!

yurkis ()
Ответ на: комментарий от yaws

> Например, там, где SQLite уже мало, а Postgresql - еще много. Там есть MySQL...

ma1uta ★★ ()
Ответ на: комментарий от ma1uta

Не там. MySQL - он больше в нише **MP (где ** - всякие LA, WI)

yaws ()
Ответ на: комментарий от anonymous

А вы не замечали что MySQL работает так же, ibdata точно так же растет?

Оракл тоже работает аналогично, и только в десятке появилось:

ALTER TABLE sometable enable row movement;
ALTER TABLE sometable shrink space;
А до этого shrink работал только если пустые блоки в конце таблицы. Про фрагментацию тейблспейсов оракла, которая лечится созданием нового тейблспейса и move всех объектов туда я вообще молчу.

ventilator ★★★ ()
Ответ на: комментарий от anonymous

товарищам еще лет 5 понадобиться, чтоб допилить это чудо-субд до наворотов которые были еще в mysql 4.

А как обстоят дела с основным свойством РСУБД — ACID, ради которого всё это действо и затевается. собственно говоря, — в этой вашей MySQL? Что, до сих пор всё плёхо? Без InnoDB не обойтись?

iZEN ★★★★★ ()
Ответ на: комментарий от yaws

> Например, там, где SQLite уже мало, а Postgresql - еще много.

Честно - не понимаю, где с PostgreSQL больше хлопот, чем с сабжем.

hobbit ★★★★★ ()
Ответ на: комментарий от boo32

> отвратительно нестабильная СУБД.

Хмм, правда? Не замечал на небольших (гиги) базах.

sv75 ★★★★★ ()
Ответ на: комментарий от anonymous

автовакуум в постгресе тоже не так давно сделали, так что пустозвоните, батенька

Deleted ()
Ответ на: комментарий от sv75

давно не работал с этой СУБД, может, уже что-то и изменилось в лучшую сторону. а вот в прошлом. база ломалась при двух потоках, выполняющих какие-нибудь «неудобно» конкурирующие запросы. оставляла «фантомные» объекты при удалении каких-нибудь триггеров или индексов - при создании, мол, объект с таким именем уже существует, хотя я его удалил. также абсолютная недееспособность при массовом потоке простых инзертов - в блокировку уходит навечно, пока не грохнешь всех писателей. пользовался продолжительное время и йаффилом, и фаербёрдом.

boo32 ()
Ответ на: комментарий от iZEN

>Без InnoDB не обойтись?

А в чём проблема? Тем более оно сейчас по умолчанию используется.

Diffor ()
Ответ на: комментарий от anonymous

> в 2004 году по планам должен был выйти firebird 3.0 с нормальным SMP

В чьих планах? Анонимного курильщика?

допилить это чудо-субд до наворотов которые были еще в mysql 4

После того, как мускул доползет до тех возможностей в хранимках/тригерах/ACID/надежности, которые были в сабже изначально, поговорим. Если будем живы, конечно.

Честно - не понимаю, где с PostgreSQL больше хлопот, чем с сабжем.

На рабочих станциях незначительно компьютеризированных предприятий, которые просто выключаются из розетки. И еще там, где нет человека, который регулярно проделывает регламентные работы. Ну и firebird embedded, аналога которому у постгреса и мускуля просто нету.

давно не работал с этой СУБД, может, уже что-то и изменилось в лучшую сторону. а вот в прошлом. база ломалась при двух потоках, выполняющих какие-нибудь «неудобно» конкурирующие запросы. оставляла «фантомные» объекты при удалении каких-нибудь триггеров или индексов - при создании, мол, объект с таким именем уже существует, хотя я его удалил. также абсолютная недееспособность при массовом потоке простых инзертов - в блокировку уходит навечно, пока не грохнеш

Ничего не изменилось. Как не было ничего вышеперечисленного, так и дальше нету.

anonymous ()

> * многопоточная обработка запросов, использующая преимущества симметричной многопроцессорной обработки (SMP), которая значительно повышает производительность на многопроцессорных и многоядерных системах;

* встроенные библиотеки libfbembed.so (POSIX) и fbembed.dll (Windows) теперь поддерживают многопоточные и поточно-ориентированные вызовы.

Т.е. вы хотите мне сказать, что серверная система не использовала SMP? В версии уже 2.5 после 6ти версий Interbase?? Хахаха.

управление учётными записями с помощью SQL-выражения «CREATE/ALTER/DROP USER»;

И этого тоже не было? Кто посмел назвать ЭТО сервером?

дополнительное предоставление/аннулирование прав пользователю, отличного от текущего (по умолчанию);

Или переведите, или дайте затянуться.

Господам, использующим это чудо в production. Я верю, что оно у вас работает. Но от flat file и Paradox до сих пор оно отличалось не сильно. Чтобы понять, чем именно, надо сьесть с ним пуд соли. Но половина перечисленного в сообщении - это самые базовые вещи. Без них это просто файл с хитрым кешированием и SQL-движком, т.е. - постаревший Paradox. И до нормальных баз ему еще развиваться и развиваться. Версии 2-3 еще до уровня MySQL (тоже то еще чудо, но все же). И совсем долго - до уровня PostgreSQL и Oracle.

Для оптимистов Firebird: Я уже с десяток баз сделал на разных движках и OS. И несколько из них портировал MS SQL -> Informix, MySQL -> (PostgreSQL, Oracle). Эффект очень интересный. Тратится какое-то кол-во времени, от месяца до полугода. После чего база начинает работать намного быстрее, на некоторых запросах - в десятки раз. При этом про любую из баз до портирования можно было сказать: «работает несколько лет в production».

Пример: После портирования базы на MySQL в Oracle время генерации довольно сложных XML репортов путем вызова сложных stored procedures, вызывающих друг друга в цикле, уменьшилось с 2..10 сек, до 10..20 миллисекунд, или в 200 раз. Просто за счет нормальной реализации stored procedures в Oracle. Запросы внутри - тривиальны. MySQL проигрывает на каждом вызове процедуры. Я в курсе, что можно переписать все на нескольких embedded loops, но тогда получится процедура в несколько сот строк, которую сложно сопровождать..

Так что, если у вас «все работает в production» - это не значит абсолютно ничего.

HappySquirrel ()
Ответ на: комментарий от anonymous

а до этого аккаунты делали через API или консольную утилитку GSEC из комплекта установки.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.