FirebirdSQL в качестве СУБД крупной системы

[Irina Galtsova-Rus]

Хотелось бы услышать мнение профессионалов по такому вопросу : На сколько критично использование в качетве СУБД Firebird в системе, которая должна работать 24 часа в сутки, 7 дней в неделю и т.д. ?

[Nadir Zaitov]

Хотелось бы услышать мнение профессионалов по такому вопросу : На сколько критично использование в качетве СУБД Firebird в системе, которая должна работать 24 часа в сутки, 7 дней в неделю и т.д. ?Это вопрос к железу или к ПО? Я не спец - я только учусь.

[Irina Galtsova-Rus]

Хотелось бы услышать мнение профессионалов по такому вопросу : На сколько критично использование в качетве СУБД Firebird в системе, которая должна работать 24 часа в сутки, 7 дней в неделю и т.д. ?Это вопрос к железу или к ПО? Я не спец - я только учусь. К ПО... с железом более или менее понятно

[Dolphin]

На сколько критично использование в качетве СУБД Firebird в системе, которая должна работать 24 часа в сутки, 7 дней в неделю и т.д. ?
То есть "насколько критично"? Мы должны решить, насколько это для вас важно?

[Irina Galtsova-Rus]

Есть ситема, от которой зависят жизни людей.... Может ли в этой системе использоваться указанная СУБД?

[Eldar Fattakhov]

Хотелось бы услышать мнение профессионалов по такому вопросу : На сколько критично использование в качетве СУБД Firebird в системе, которая должна работать 24 часа в сутки, 7 дней в неделю и т.д. ?
Не профессионал. Не видел ни одной реализации более или менее критичной системы на FireBird. Есть попытки местных разработчиков (одна группа людей, мигрирующих между разными компаниями) делать чуть ли не биллинговые системы. Но это, на мой взгляд, чистый лохотрон по отношению к заказчику

[Dolphin]

Есть ситема, от которой зависят жизни людей.... Может ли в этой системе использоваться указанная СУБД?
Никакой принципиальной разницы между СУБД нет. Можете хоть SQLite использовать, тут все зависит от качества софта, с этой базой работающего.
В кривых руках и оракл падает.

[Renat Akhtyamov]

Есть ситема, от которой зависят жизни людей.... Может ли в этой системе использоваться указанная СУБД?
примерная нагрузка известна? Количество транзакций в секунду, в минуту? Пиковые нагрузки какие предполагаются? Объёмы данных какие будут? Какие выставляются нефункциональные требования к системе (типа время отклика, кол-во одновременно работающих юзеров)?
Потом можно подумать о СУБД. Я так думаю, что первое требование - это бесплатная СУБД для системы, от которой зависят жизни людей?

[Irina Galtsova-Rus]

Я так думаю, что первое требование - это бесплатная СУБД для системы, от которой зависят жизни людей?
почему?

[Renat Akhtyamov]

Есть ситема, от которой зависят жизни людей.... Может ли в этой системе использоваться указанная СУБД?
Никакой принципиальной разницы между СУБД нет. Можете хоть SQLite использовать, тут все зависит от качества софта, с этой базой работающего.
В кривых руках и оракл падает.

Зависит не только от качества софта, в первую очередь от характера софта.

[Renat Akhtyamov]

Я так думаю, что первое требование - это бесплатная СУБД для системы, от которой зависят жизни людей?
почему?
если нет требования к бесплатности СУБД, то обычно не рассматривают таких кандидатов как FireBird.

[Irina Galtsova-Rus]

в первую очередь от характера софта. что вы понимаете под характером софта?

[Irina Galtsova-Rus]

если нет требования к бесплатности СУБД, то обычно не рассматривают таких кандидатов как FireBird.

какие тогда рассматривают? и почему на рассматривают FireBird ?

[Renat Akhtyamov]

в первую очередь от характера софта. что вы понимаете под характером софта?
функциональное назначение софта.
Например -
1)Биллинговая система для сотового оператора с абонентсткой базой более 6 млн.
или
2)Система складского учёта частного магазинчика (ларька с 1-м продавцом)
3) Карточная игра "Дурак" с хранением таблицы лидеров

скажем для первого случая никаких SQLLite и FireBird, только промышленная СУБД
для 2-го случая, можно FireBird и даже SqlLite
для 3-го вообще без СУБД лучше обойтись

[Irina Galtsova-Rus]

1)Биллинговая система для сотового оператора с абонентсткой базой более 6 млн.
или

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

[Irina Galtsova-Rus]

скажем для первого случая никаких SQLLite и FireBird, только промышленная СУБД
почему?

[Akmal Bafoev]

скажем для первого случая никаких SQLLite и FireBird, только промышленная СУБД
почему?

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

[Renat Akhtyamov]

1)Биллинговая система для сотового оператора с абонентсткой базой более 6 млн.
или

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

Количество заявок в день большое?

[Irina Galtsova-Rus]

устойчивость к отказам, отработанная процедура резервного копирования, время восстановления после сбоев или проблем с железом etc.[/QUOTE]

спасибо, а можно ли увидеть Ваше мнение в голосовании?

[Irina Galtsova-Rus]

Количество заявок в день большое?
в ЧНН около 3000. Система должна рабоать разветвленн по городу , в дальшем должно поддерживаться расширение на уровень республики

[Dolphin]

скажем для первого случая никаких SQLLite и FireBird, только промышленная СУБД
А что вы понимаете под "промышленной СУБД"? По каким критериям определяется эта "промышленность", кроме проприетарности и стоимости?

каждый из которых может просто умереть если его заявка не будет выполнена
Так заявку не база данных будет выполнять, я думаю?
Задача сводится к отказоусточивости базы данных, если у вас все так серьезно и нужна репликация - тогда firebird таки не подойдет. Выбирайте между Oracle и PostgreSQL - у них есть вменяемые механизмы репликации. У MSSQL репликация тоже заявлена, но из-за его виндовости он несерьезен.

[Irina Galtsova-Rus]

тогда firebird таки не подойдет
можно отразить ваше мнение в голосовании?

[Renat Akhtyamov]

1)Биллинговая система для сотового оператора с абонентсткой базой более 6 млн.
или

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

Oracle, DB2, MsSql - однозначно справятся в Вашими потребностями

FireBird, MySQL - не исключено, что удовлетворят их

Если уже известна структура БД, то стоит произвести небольшое испытание. Заполнить БД тестовыми данными и погонять несколько часов в приближенных к реальным условиям. Сымитировать необходимое количество одновременных обращений к БД на вашем железе.
Потом всё встанет на свои места. Годится или не годится... Тут врядли кто вам даст однозначный ответ. Всё бесплатное нужно проверять...

[Irina Galtsova-Rus]

и погонять несколько часов в приближенных к реальным условиям
Вы считаете этого достаточно?

[Renat Akhtyamov]

и погонять несколько часов в приближенных к реальным условиям
Вы считаете этого достаточно?

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

[Dolphin]

можно отразить ваше мнение в голосовании?
Я проголосовал. "За", потому, что я считаю FireBird годной системой, а отказоусточивость достигается грамотной настройкой и обслуживанием сервера.

Если уже известна структура БД, то стоит произвести небольшое испытание. Заполнить БД тестовыми данными и погонять несколько часов в приближенных к реальным условиям. Сымитировать необходимое количество одновременных обращений к БД на вашем железе. Потом всё встанет на свои места. Годится или не годится... Тут врядли кто вам даст однозначный ответ. Всё бесплатное нужно проверять...
Так ведь не в производительности вопрос. 3000 транзакций в сутки (даже если в них по 5000 запросов) - фигня для любой СУБД и любого мало-мальски современного сервера. Firebird - форк Interbase и существует не первый год, работоспособность его вполне доказана.

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

[Irina Galtsova-Rus]

3000 транзакций в сутки

3000 в ЧНН - в час наибольшей нагрузки

[Renat Akhtyamov]

Так ведь не в производительности вопрос. 3000 транзакций в сутки (даже если в них по 5000 запросов) - фигня для любой СУБД и любого мало-мальски современного сервера. Firebird - форк Interbase и существует не первый год, работоспособность его вполне доказана.
Так вопрос не только в количестве транзакций в виде поступающих заявок, есть ещё и запросы юзеров. Имитировать надо, чтобы проверить насколько удовлетворительна работа системы. Кому нужна система, имеющая время отклика 10-20 сек?
был опыт работы с FireBird в качестве биллинговой системы для одной коммунальной службы. Удовлетворяло всё, кроме операции закрытия месяца. На том же железе MsSQL производил операцию закрытия месяца в разы быстрее. Сутки, против 2 часов, для 500 тысяч абонентов.

[Irina Galtsova-Rus]

а если усложнить задачу и повесить на эту же систему отчеты по поступившим заявкам, котрые нужно делать ежедневно....

[Renat Akhtyamov]

А что вы понимаете под "промышленной СУБД"? По каким критериям определяется эта "промышленность", кроме проприетарности и стоимости?
И в самом деле, затруднился дать(найти) точное определение понятию "Промышленная СУБД". :)
как-то так:
Промышленная СУБД - СУБД ориентированная на создание ИС оперирующих, большим объемом информации с повышенным требованием безопасности.
Способная обеспечить работу ИС масштаба среднего и крупного предприятия.

[Renat Akhtyamov]

а если усложнить задачу и повесить на эту же систему отчеты по поступившим заявкам, котрые нужно делать ежедневно....
Всё зависит от сложности бизнес процесса и сложности отчётов по нему.

Как сказал Dolphin - "И оракл в кривых руках падает".

Может дадите взглянуть на ТЗ ?

[Irina Galtsova-Rus]

Может дадите взглянуть на ТЗ ?
поздно.... :) оно уже работает

[Dolphin]

поздно.... оно уже работает
К чему тогда сыр-бор?

[Irina Galtsova-Rus]

Нужно понять перспективы развития системы и ее возможности....

[Talgat Ravilov]

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

[Irina Galtsova-Rus]

Если мы Вас сейчас отговорим, Вы остановите систему и отправите на доработку?

так Вы считате, что нужна доработка ? в плане перходда на другую СУБд?

[JackDaniels]

FireBird, MySQL - не исключено, что удовлетворят их
Слово в защиту MySQL — 6 лет работает сервер (24/7) с нагрузкой ≈600 000 запросов в час (пик до 2 000 000).
Ничего, прекрасно справляется.

[Renat Akhtyamov]

Если мы Вас сейчас отговорим, Вы остановите систему и отправите на доработку?

так Вы считате, что нужна доработка ? в плане перходда на другую СУБд?

Сами разработчики, что говорят? Есть у них уверенность в том что система протянет много-много лет?

[Eldar Fattakhov]

После полученных уточнений голосование должно состоять только из одного пункта "ни за что". :)

[Irina Galtsova-Rus]

Сами разработчики, что говорят? Есть у них уверенность в том что система протянет много-много лет?

пока молчат ....

[Eldar Fattakhov]

Сами разработчики, что говорят? Есть у них уверенность в том что система протянет много-много лет?

пока молчат ....
Газовикам они предлагали свой биллинг?

[Irina Galtsova-Rus]

Оффтоп:После полученных уточнений голосование должно состоять только из одного пункта "ни за что".

пока счет ровный :)

[JackDaniels]

Irina Galtsova-Rus, Вообще, я бы обратил внимание не на количество запросов в минуту/час/год и не на стабильность (оба вопроса больше к железу), а скорее на размер самой базы, которую вынуждена таскать «Жарптица».
Если база маленькая, ну пусть там 100-200 Мб, то что угодно справится, а если что-то из разряда 50-100 гигов, то много-много раз подумать и потестить.
Да и раз уже работает, сомневаюсь, что будут переливать на другое СУБД, если только не грохнется.
(По самой FireBird — я бы не стал ее применять, ибо что за птица — черт ее знает, сегодня у вас есть разработчик ее «любящий», а завтра он уволился.
Лучше юзать более распространенные решения.)

[Shitikov Roman]

Дело в том что система под которой работает данная СУБД писалась изначально под мелкие конторки типа таксопарков, но ей поменяли суть и логику и теперь она работает несколько в других условиях. Железо неплохое или не совсем плохое Proliant DL 160 G6. При пиковых нагрузках случаются длительные задержки при обработке информации, грешу на узкий канал связи с подразделениями, на сервере и 12 удалённых точках по 512 кб/с, имеет ли смысл только расширять канал или стоит менять СУБД напрочь? Насчёт пиковых загрузок пока не уверен, не было времени на тесты, но факты сбоя налицо, СУБД просто перестаёт отвечать. Толи вопрос в канале, толи СУБД реально не годится и нужно решать вопрос с Разрабом о переводе на другую СУБД. Спасибо всем, кто откликнулся.

[DarkUser]

При пиковых нагрузках случаются длительные задержки при обработке информации, грешу на узкий канал связи с подразделениями, на сервере и 12 удалённых точках по 512 кб/с, имеет ли смысл только расширять канал или стоит менять СУБД напрочь? Насчёт пиковых загрузок пока не уверен, не было времени на тесты, но факты сбоя налицо, СУБД просто перестаёт отвечать. Толи вопрос в канале, толи СУБД реально не годится и нужно решать вопрос с Разрабом о переводе на другую СУБД.Как-то несерьезно, ИМХО. Сначала выясняют узкое место, а потом уже решают что с ним делать, оптимизировать или менять архитектуру. А так - гадание на кофейной гуще.
FB, при грамотном подходе (разработчике, архитектуре etc), вытянет побольше, чем полторы транзакции в секунду (особено, если не всю БЛ на сервере держать).
Однако, RHD прав, при популярности птица куда меньшей чем у тех-же Oracle/MSSQL, найти смену разработчику под Firebird (если вдруг что), будет не просто.

[Eldar Fattakhov]

СУБД просто перестаёт отвечатьКанал, как и сервер, тут непричём (явно хватает как пропускной способности канала, так и мощности любого из процессоров Xeon серверов 6-поколения ProLiant. Скорее всего затыки связаны с конкуренцией запросов. Нужно посмотреть - как выглядит дисковая подсистема и (если есть встроенная аналитика СУБД) посмотреть на ее работу.

[Shitikov Roman]

СУБД просто перестаёт отвечатьКанал, как и сервер, тут непричём (явно хватает как пропускной способности канала, так и мощности любого из процессоров Xeon серверов 6-поколения ProLiant. Скорее всего затыки связаны с конкуренцией запросов. Нужно посмотреть - как выглядит дисковая подсистема и (если есть встроенная аналитика СУБД) посмотреть на ее работу.
Спорить не возьмусь, для реальных тестов не было времени, по поводу каналов спросил неспроста, мне кажется есть узкое место , т.к. 12 удалённых подразделений "долбятся" через канал 512 кб/с, чего по сути маловато, прогляжу сниффером на досуге скажу точнее, просто очень мало времени было, успел только поднять систему и запустить, сбой пока один видел. После тестов отпишусь. Завтра постараюсь отскринить пиковые (если они будут) загрузки. Пик приходится на промежуток с 18:00 до 24:00 ориентировочно. Проблем в железке я пока не нашел.