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

[Eldar Fattakhov]

Оффтоп:

Сообщение от Irina Galtsova-Rus

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

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

[Irina Galtsova-Rus]

Сообщение от Eldar Fattakhov

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

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

[JackDaniels]

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

[Shitikov Roman]

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

[DarkUser]

Сообщение от Shitikov Roman

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

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

[Eldar Fattakhov]

Оффтоп:

Сообщение от Shitikov Roman

СУБД просто перестаёт отвечать

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

[Shitikov Roman]

Сообщение от Eldar Fattakhov

Оффтоп:

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

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