3 самые большие проблемы с Firebird

classic Classic list List threaded Threaded
144 messages Options
123456 ... 8
Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Yurij


On May 22, 12:47 pm, Alexey Kovyazin <[hidden email]>
wrote:

> Вот про внешние языки в виде СП. Получается, побольше логики внутрь БД
> вставляем? Или вообще всю :) Далее учим возвращать XML как результат
> запроса, кастомизуемые запросы прикручиваем общение на разных портах
> (80) и бац - application server родился, да только их и так много,
> более модульных и заточенных под веб-фермы и т.д. - т.е. догнать вряд
> ли.
> Или внешние языки рассматриваются как одним-махом-решаем-проблему с
> недостатками SQL?
> Т.е. хотелось бы услышать конкретную историю - что стоит за хотением
> именно в вашем случае.
Ну вот лично мне лень изучать и подключать отдельные апп-сервера,
потому что все они безумные. У реляционной модели есть строгая теория
и все построенное на ее основе - практически идентично на разных СУБД.
А сервера приложений, жаба, дотнет, ооп, ORM, паттерны и прочий трэш -
там кто во что горазд, "как архитектор с утра очередную страницу из
GoF выкурил".

В итоге все равно конечному пользователю показывается таблица, изредка
- с вложенными деталями. И если ее получать прямо результатом запроса
к FB, а не через десяток слоев на жабо-дотнетах - это гораздо проще и
быстрее будет.

А уж если сравнить деплоймент решения "FB и клиентская прога" с "FB
+сервер приложений+приложение в него+клиентские проги" - это
совершенно разные по трудозатратам вещи.

Я сейчас как раз занимаюсь тем, что проектирую такую пакость для
использования в нескольких проектах поверх fb и mssql, на дотнете.
Редкостная печаль, надо сказать.
Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Yakov Hrebtov-2
In reply to this post by PEAKTOP

PEAKTOP wrote:
>> Если допускается отойти от чисто технических проблем, то имхо очень важны:
>> 1. Цельная, легкодоступная документация в удобной форме.
>
> Это ты про firebirdsql.su ? Дык там, по-моему, все в пордке. Понятное
> дело, шо неполная, дык время идет и "красных" страниц ужо почти не
> осталось.
Я про цельную полную документацию в первую очередь на английском языке,
доступную с официального сайта. Локализация - это, на мой взгляд, значительно
менее важно.

Для примера:
Где новичок должен почитать про приоритет операций?
Сколько времени у него займет поиск этой информации?

Для сравнения:
На главной странице postgresql.org в поле search написать 'precedence'.

Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Вадим Мещеряков
In reply to this post by Alexey Kovyazin

Вот интересно, с какой целью представитель компании разрабатывающей
коммерческий аналогичный продукт задаёт такие вопросы :)

А если серьезно, я сталкиваюсь со следующей проблемой

1. Заказчики развиваются и начинают ворочать все большими и большими
массивами данных.
Проблема не полного использования ресурсов SMTP серверов и отсутствие
возможности собрать их несколько в  кластер что бы они попыхтели вместе.

2.Редко, хорошо что редко, но портятся базы. В моей практике в 99,8 случаев
% виновато железо  (сбои памяти, перегрев сервера, выключение питания), в
остальных 0.2%   портится индекс в таблице где проходит массовые обновления,
удаления, вставки (после установки FB 2.04 не встечалось). Но все таки
обидно, что приходится тратить время на перебэкапы восстановление, ну тут да
же идей нет как бы этому помочь. Скорее всего эта проблема не имеет
отношение к FB как к таковому.

C уважением,
Мещеряков Вадим.


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Alex Cherednichenko

Hello, Vadim!
You wrote  on Fri, 22 May 2009 17:08:19 +0600:

 VM> Проблема не полного использования ресурсов SMTP серверов и отсутствие
 VM> возможности собрать их несколько в  кластер что бы они попыхтели вместе.

А ты ничё не путаешь?
А вместе попыхтеть, это запросто!..

--
With best regards, Alex Cherednichenko.


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Roman Rokytskyy-2
In reply to this post by Alexey Kovyazin


> Вот про внешние языки в виде СП. Получается, побольше логики внутрь БД
> вставляем? Или вообще всю :) Далее учим возвращать XML как результат
> запроса, кастомизуемые запросы прикручиваем общение на разных портах
> (80) и бац - application server родился, да только их и так много,
> более модульных и заточенных под веб-фермы и т.д. - т.е. догнать вряд
> ли.
>
> Или внешние языки рассматриваются как одним-махом-решаем-проблему с
> недостатками SQL?
>
> Т.е. хотелось бы услышать конкретную историю - что стоит за хотением
> именно в вашем случае.

Сейчас запускаем один проектик на Оракле (думаю, что годовой оборот
счетов выставленых системой несколько сотен миллионов составит).
Бизнес-логика там только на PL/SQL, интерфейс на Oracle Forms. Еще один
проектик с которым прихо дилось иметь дело (делал аудит, в разработке я
не участвовал) на связке Oracle/Oracle Forms имеет годовой "оборот"
около трех миллиардов... И нет там никакого аппсервера, если не считать
Oracle Forms. А еще мэйнфрэйм-системы в банках и страховых фирмах, с
которыми приходилось иметь дело, - так там тоже никаких серверов
приложений - бизнес-логика с базой неразделимы.

И ниче так - работает!.. Так что я не совсем уверен (а точнее совсем
неуверен), что отдельный сервер приложений так необходим. Хотя, в данном
случае, думаю, что с точки зрения маркетинга нам бы своя реализация
PL/SQL понадобилась, чем какие-то другие языки.

Что касается веба, то основным популярным AJAX-библиотекам данные
желательно в табличной форма подавать. В случае типичного стэка сервера
приложения [на Java] приходится один раз данные из базы конвертировать в
объекты, потом из объектов в таблички, отсылать клиенту, получать от
клиента таблички, конвертировать в объекты, передавать О/Р-мапперу чтоб
опять в таблички конвертировать...

Роман

Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Евгений Килин
In reply to this post by Dmitry Yemanov

>> 1. Очень геморройно БЭКАП/Ресторе больших баз, особенно, если ошибка на
>> восстановлении какого нибудь триггера, а в результате пустые таблицы
>
> Ты в этом уверен? Что пустые таблицы?


Таблицы конечно не пустые, но лично мне очень не хватает WALа :)
Т.к. для обеспечения _достачно_ _оперативной_ восстанавливаемости БД что
бэкап/ресторе, что nbackup это все очень ресурсоемкие и длительные
процедуры.


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Dmitry Yemanov

Евгений Килин wrote:
>
> Таблицы конечно не пустые, но лично мне очень не хватает WALа :)
> Т.к. для обеспечения _достачно_ _оперативной_ восстанавливаемости БД что
> бэкап/ресторе, что nbackup это все очень ресурсоемкие и длительные
> процедуры.

Давай не будем мешать фичи и их реализацию :-) Ты хочешь обеспечить high
availability. А уж WAL-ом или nbackup завтра начнет в 10 раз быстрее
работать - это не суть важно. Так?


--
Дмитрий Еманов

Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Dmitry Kuzmenko-3
In reply to this post by Oleg Matveyev

Hello, Oleg!

Oleg Matveyev wrote:

> как уже говорилось:
> сначала failover

failover делается на раз с любым существующим ИБ-ФБ, прямо сейчас.

> а потом возникнет вопрос: стоит второй сервер "зря". пусть помогает
> по-возможности.

альтернативный пример - IB 2007/2009 SuperServer, который
распараллеливается элементарно, в базовом виде на 8 ядер.
Так что пожелание кластера должно не только на надежности основываться,
но и на масштабируемости, которой не хватает (если не хватает).
То есть и на надежности (дублировании) и на масштабируемости.
По отдельности пока все ок.

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

на определенном этапе умения отладчик разработчику уже не нужен. Скорее
нужен лог трассировки выполнения действий. Даже не так - для понимания,
что имено нужно, надо сначала рассмотреть ряд конкретных примеров, ЧТО
именно отлаживается.
А то может отладчик как раз и нафиг не нужен.
Я понятно, теоретизирую, но иногда желаемое называют не тем словом.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Dmitry Kuzmenko-3
In reply to this post by Vlad Khorsun

Hello, Vlad!

Khorsun Vlad wrote:

>> Это позволит тиражировать готовые БД. Вроде все для этого подготовлено
>> - embeded - есть, read-only - есть/
>> Осталось только закрыть саму БД, чтобы не всякий мог ее открыть.
>
>
>    (1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено
> не нужно.

причина и следствие попутаны. Пример - IB 2007 EUA:
1. есть проверка пользователей через admin.ib
2. есть проверка пользователей через БД

при этом у них наоборот, дубняк в том, что даже в случае 2
сервер все равно тыркается сначала в пункт 1, т.е. без admin.ib
не работает.

Если это убрать, то Embedded вполне сможет использовать
эту схему. В настоящий момент Embedded не проверяет пользователей
потому что их негде взять. Будут в базе - будет брать оттуда, почему
нет?
Люди как раз этого и хотят - баз с защитой от переноса между серверами,
пусть даже и с примитивной защитой.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Vlad Khorsun

"Dmitri Kuzmenko" ...

>
> Hello, Vlad!
>
> Khorsun Vlad wrote:
>
>>> Это позволит тиражировать готовые БД. Вроде все для этого подготовлено
>>> - embeded - есть, read-only - есть/
>>> Осталось только закрыть саму БД, чтобы не всякий мог ее открыть.
>>
>>
>>    (1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено
>> не нужно.
>
> причина и следствие попутаны.

    В где ?

> Пример - IB 2007 EUA:
> 1. есть проверка пользователей через admin.ib
> 2. есть проверка пользователей через БД
>
> при этом у них наоборот, дубняк в том, что даже в случае 2
> сервер все равно тыркается сначала в пункт 1, т.е. без admin.ib
> не работает.
>
> Если это убрать, то Embedded вполне сможет использовать
> эту схему. В настоящий момент Embedded не проверяет пользователей
> потому что их негде взять. Будут в базе - будет брать оттуда, почему
> нет?

    Потому что это embedded. Приложение и так имеет полный доступ
к телу БД.

> Люди как раз этого и хотят - баз с защитой от переноса между серверами,
> пусть даже и с примитивной защитой.

    Это называется - шифрование, уже надцать раз обсуждали. Помни
о том, что FB - open source, так что проприетарные штучки с "хорошо
спрятанным" логином не катят.

--
Хорсун Влад


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Attid-2
In reply to this post by Yurij
> 2. Возможность создавать обычные и агрегатные функции как СП.
> 4. возможность работать с кортежами в тексте SQL и параметрах.

а мне только этих 2х пунктов не хватает. =)

Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Dmitry Lendel
In reply to this post by Yakov Hrebtov-2

Привет

> 1. Цельная, легкодоступная документация в удобной форме.

Поддерживаю. С документацией действительно грустно.
"Читай про 6.0, а потом начиня с 1.0 до 2.5" это фи.

> Ни того ни другого на мой взгляд сейчас нет и это мешает популяризации и
> продвижению FB.

Во-во

Дмитрий


Reply | Threaded
Open this post in threaded view
|

Re: 3 ÓÁÍÙÅ ÂÏÌØÛÉÅ ÐÒÏÂÌÅÍÙ Ó Firebird

pnv82
In reply to this post by Alexey Kovyazin

Hello, Alexey!
You wrote  on Thu, 21 May 2009 05:56:22 -0700 (PDT):

Из трудностей, с которыми столкнулся на практике

1. Система прав - возможность отделить сисдба от админа, группы и т.п. Но
вроде активное движение в этй сторону есть. Для крупных проектов сие
довольно критично.

2. Схемы

3. Масштабируемость по произоводительности (путем кластеризации?)

Пригодилось бы:
  Материализованные вьюхи
  Возможность создания агрегатных функциий
  Шифрация базы
  Кеш препаренных запросов на сервере
  Больше типов индексов - к примеру с гистограммой, частичные, битмап
  Возможность создания "зеркал" серверов, балансировочные прокси - год назад
проскакивала ссылка как это PostgreSQL сделано.
  Партиционирование, тейблспейсы.

--
-=Боюсь огорчить, но результаты Вашего вскрытия...=-
With best regards,  Nikolay Ponomarenko


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Dmitry Kuzmenko-3
In reply to this post by Vlad Khorsun

Hello, Vlad!

Khorsun Vlad wrote:

>>>    (1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено
>>> не нужно.
>> причина и следствие попутаны.
 >    В где ?

в там.  Embedded-у не нужна встроенная в базу аутентификация,
потому что он и так без нее работает. Так?

>> эту схему. В настоящий момент Embedded не проверяет пользователей
>> потому что их негде взять. Будут в базе - будет брать оттуда, почему
>> нет?
>
>    Потому что это embedded. Приложение и так имеет полный доступ
> к телу БД.

похер. Приложение пусть имеет.

>> Люди как раз этого и хотят - баз с защитой от переноса между серверами,
>> пусть даже и с примитивной защитой.
>
>    Это называется - шифрование, уже надцать раз обсуждали. Помни
> о том, что FB - open source, так что проприетарные штучки с "хорошо
> спрятанным" логином не катят.

я помню, и это тоже пофиг, т.к. 99% разработчиков и вообще исходники
а) не уперлись
б) практически бесполезны (не умеют читать).

Шифрованием этим вы себе уже все проели, если честно.
"слабое нельзя, а сильное долго делать". Ну и фиг ли?
Сильное не делается и перспективы мутные, а слабого так и нет.
В любом случае даже к шифрованной базе у embedded так и будет
"полный доступ".

Вообще, кстати, одно другому не мешает. Аутентификация в базе
imho с шифрованием вообще никак не связана. В FB встроеннойа
утентификации нет? Нет. Шифрования нет? Нет.
А в IB2009 уже есть и то, и другое. Сначала они аутентификацию
сделали, а потом шифрование забубенили. И кому что надо,
тот тем и пользуется.

p.s. уел? :-)

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Dmitry Kuzmenko-3
In reply to this post by Dmitry Lendel

Hello, Dmitry!

Dmitry Lendel wrote:

> Поддерживаю. С документацией действительно грустно.
> "Читай про 6.0, а потом начиня с 1.0 до 2.5" это фи.

да я не знаю, давно предлагал тупо сп...ить langref и переписать его.
И как минимум главная часть была бы готова. А остальное склепать
из статей.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Dmitry Kuzmenko-3
In reply to this post by pnv82

Hello, Nikolay!

Nikolay Ponomarenko wrote:

>  Возможность создания "зеркал" серверов, балансировочные прокси - год
> назад проскакивала ссылка как это PostgreSQL сделано.
>  Партиционирование, тейблспейсы.

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

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Yurij

Dmitri Kuzmenko wrote:
> осмелюсь заметить, что это "пальцатые" фичи, т.е. интересуют тех,
> кто не хухры-мухры, а бабло на этом деле зарабатывает, или,
> как минимум, на железо, администрирование и разработку выделяет
> неслабую копеечку.
> В связи с этим вопрос - вот лично Ваша контора на разработку
> ФБ сколько денег перечислила? Или, сколько она готова дотировать
> на разработку указанных фич

Конторы которые неслабые копеечки выделяют, просто покупают оракл и все.
Никакая ИТ служба в здравом уме при достаточном финансировании не станет
связываться с open source проектом неизвестного статуса.
Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Vlad Khorsun
In reply to this post by Dmitry Kuzmenko-3

"Dmitri Kuzmenko" ...

>
> Hello, Vlad!
>
> Khorsun Vlad wrote:
>
>>>>    (1) и (2) не есть одно и тоже. Для embedded, например, (1) совершено
>>>> не нужно.
>>> причина и следствие попутаны.
> >    В где ?
>
> в там.  Embedded-у не нужна встроенная в базу аутентификация,
> потому что он и так без нее работает. Так?

    Да, и ? Я тебя не понимаю - ты кого поправляешь\возражаешь ?

>>> эту схему. В настоящий момент Embedded не проверяет пользователей
>>> потому что их негде взять. Будут в базе - будет брать оттуда, почему
>>> нет?
>>
>>    Потому что это embedded. Приложение и так имеет полный доступ
>> к телу БД.
>
> похер. Приложение пусть имеет.

    Делать что-то ради галочки, как это принято в покойной ныне компании, мы не будем.

>>> Люди как раз этого и хотят - баз с защитой от переноса между серверами,
>>> пусть даже и с примитивной защитой.
>>
>>    Это называется - шифрование, уже надцать раз обсуждали. Помни
>> о том, что FB - open source, так что проприетарные штучки с "хорошо
>> спрятанным" логином не катят.
>
> я помню, и это тоже пофиг, т.к. 99% разработчиков и вообще исходники
> а) не уперлись
> б) практически бесполезны (не умеют читать).

    *Я сам* завтра под другим именем выпущу бинарники, которые положат с прибором
на всех "встроенных" пользователей и они (бинарники) разойдутся по инету быстрее чем
ты можешь себе представить.

    Тоже пофиг ?

> Шифрованием этим вы себе уже все проели, если честно.

    Это вы нам уже всё им проели. Мне лично оно нафиг не упало, есть вещи поинтереснее,
да и нужнее.

> "слабое нельзя, а сильное долго делать". Ну и фиг ли?

    См. выше про галочки

> Сильное не делается и перспективы мутные, а слабого так и нет.
> В любом случае даже к шифрованной базе у embedded так и будет
> "полный доступ".

    Ключ. Живёт. Отдельно. От. Базы. И. От. Кода. Ась ?

> Вообще, кстати, одно другому не мешает.

    Не может быть !

> Аутентификация в базе imho с шифрованием вообще никак не связана.

    Та ты шо ! А я связывал, ай-яй-яй... :-D

> В FB встроеннойа утентификации нет? Нет. Шифрования нет? Нет.
> А в IB2009 уже есть и то, и другое. Сначала они аутентификацию
> сделали

    Ты хочешь меня на слабо взять ? Или спровоцировать на публичный похер IB ?
Так ты и сам чуть выше прекрасно отозвался об их "встроеннойа утентификации"
с "дубняком" :)

> а потом шифрование забубенили.

    Забубенили... наверное ты что-то ещё знаешь... :-D

> И кому что надо, тот тем и пользуется.

    Конечно. Лог есть, но пользоваться им не рекомендуют, ибо тормозит...
GroupCommit ещё не выкинули или он по-прежнему ломает базы ?
Баги GTT ещё никого не достали ?

    Сказать почему их не правят ? Не потому, что не могут. И даже не потому,
что не хотят. А потому - что никому оно не надо.

> p.s. уел? :-)

    Чем ? Тем, что мы не борланд ? Что мы делаем не то, что дядя сказал,
а то что считаем нужным ? Что мы правим унаследованные от них баги,
вместо внесения сомнительных недоделанных фич с новыми багами ?

    Уел он меня... щаззз ! :)

--
Хорсун Влад


Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Oleg Matveyev
In reply to this post by Dmitry Kuzmenko-3

> failover делается на раз с любым существующим ИБ-ФБ, прямо сейчас.

Как? или я опять проспал очередную революцию...

Программировать прийдется? Если да - то не катит.

Нужно, чтобы любой DBA мог "просто настроить".
Прозрачно для приложения,
просто ставим на еще один сервер FB,
прописываем обоим в firebird.conf пару ключей и вауля.



Reply | Threaded
Open this post in threaded view
|

Re: 3 самые большие проблемы с Firebird

Oleg Matveyev
In reply to this post by pnv82

> ... балансировочные прокси - год назад проскакивала ссылка как это
> PostgreSQL сделано.

можно подробней, что есть "балансировочные прокси" ?


123456 ... 8