|
|
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Доброго всем дня суток! Скажу сразу, я работаю с Firebird уже несколько лет (3+) и в принципе у меня прямо таки "любовь" :) Система работает прекрасно, достаточно быстро, стабильно, уж не говоря о легкости установки версии 1.5 и очень маленьком размере последнего сервера (2.6Mb). Делал разного рода тесты со вставкой 50000 записей в средную таблицу и вроде было нормально, (1600 записей в секунду) создавал таблицы с 2-3М записек для тестирования SELECT и тоже работает совсем не плохо даже через интернет. Но вот никогда не делал тестирования с 200-300 одновремено подключенными пользователями и с таблицами в 30-40М записей. Просто не знаю как я один могу симулировать такой тест? До сих пор я Firebird всегда использовался для десктоп програм с максимум 2-3 одновременых соединений, но вот назревает проект централизованного управлениями 300 точками и есть желание централизовать базу для улутшеного упревления и всякого рода отчетов. В среднем каждая точка будет делать не более 200-300 вставок в день, но будет постояно подключена и выбирать разного рода информацию из таблиц. Думаю всего будет где-то 30 таблиц. Вот я и думаю стоит испольозовать Firebird или все таки не стоит? Попробовал поставить DB2 и потестировать, но скажу сразу не понравилось. Во первых система весит достаточно прелично, работает жутко медленно (одно только создание пустой базы заняло 2-3 минуты). Вообще говоря создается впечатление вто Firebird единственная програма которая уменьшается в размере :) В принципе это хорошо, может значить что народ очищает код, что уже приятно. Что посоветуете? Заранее спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2003, 20:28 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Где-то читал, что interbase (чем по сути и являеться firebird) предназначен для максимум 50-60 клиентов постоянно работающих. По моему мнению это связано с довольно плохой кэшируемостью, т.к. у многих систем узким местом являеться дисковая подсистема, то мне кажеться и у тебя будет так... например MS SQL может почти всё держать в оперативке (что очень разумно при 200-300 активных пользователей). Возможно с кэшированием данных и дела обстоят достаточно хорошо (хотя в книге данный вопрос довольно мягко обходят стороной). А вообще тебе на ibase.ru надо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2003, 20:47 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Дела такие: если сервер многопроцессорный, то для использования всей его мощи надо ставить класик. Классик на каждое соединение ест много (если не ошибаюсь - 30 метров в среднем, хотя это зависит от то, что соединение делает). вот и получается, что 30 * 300 = 9000 МБ = 9 ГБ, что больше 2-х раз не влазит в 32-разрядное адресное пространство Всё это теория, конечно. На практике я не проверял... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2003, 21:02 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Лучше не надо... Для 200-300 пользователей постоянно онлайн даже на блокировочниках (которые потенциально менее ресурсотребовательные) надо колдовать над каждым запросом, писать хинты оптимизатору, чтобы он не лажанулся в самый неподходящий момент. К тому же обеспечить приемлимую производительность для 200-300 пользователей можно только на многопроцессорной машине; однопроцессорный даже 3.2 ГГц (атлон или P4) думаю будет в пролете по времени отклика. А если учесть, что многопроцессорность IB не очень помогает, то грустное это будет зрелище. А количество памяти на сервере для хранения версий, висящих транзакций и кэша БД для каждого клиента (в случае Classic) думаю превысит требования блокировочника на схожих условиях если не на порядок, то близко к этому. PS под блокировочником подразумеваю MSSQL и Sybase. PPS думаю, 50 активных пользователей это предел для IB/Yaffil. Непромышленный это сервер и не позиционировался никогда для этой области. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2003, 21:23 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Denis A Спасибо за ответ. У тебя практический опыт? Так если не Firebird, что лутше DB2 или Oracle? Если често не особо хочу рассматривать MS SQL, практита показывает что лет 10 продукты микрософт стабильно не работаю, хотя конечно может многое изменилось. Интерсно былобы знать, как сравнивается цена лицензий, производительность ну и наверно самое главное средства разработки и доступа для Delphi. Что хорошо с Firebird, то что он бесплатный, есть куча тулов для разработки данный и подключения. Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2003, 22:59 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Что-то много по 30 мегов на каждого клиента.... что-то вы путаете наверно.... Это чтож получаеться у меня база на 10 мег... с ней работает 10 пользователей и получаеться нужно 300 мег оперативы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2003, 23:10 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Более чем 120 пользователей в коннекте не видел, но базы до 120 конн размером 4 гига, видел. Живут, точнее требуют ухода, типа ежедневного свипа, валида и пересоздания некоторых индексов, которые имеют обыкновение помирать, реально на мой взгляд это граница, на которой необходимо переходить на Oracle или что то типа этого, хотя как практика показывает, все проблеммы из-за того что большинство пользователей не упсированы, и бывают неожиданные отключения света. Оборудование при этом конечно требует затрат, хотя многопроцессорность не обязательна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2003, 00:11 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Я не очень люблю Майкрософт, но по MSSQL ничего плохого сказать не могу - продукт очень качественный. Знаю нескольких людей, у которых на MSSQL работают базы >10ГБ и количеством коннектов за 100. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2003, 09:50 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Я бы предложил Вам использовать каскадирование БД и репликацию, если это возможно. Управление может осуществляться через головну БД. Только придется немного ручками пописать. Есть такой опыт, БД были территориально разнесены. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2003, 10:09 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
2TheOne Попробовал поставить DB2 и потестировать, но скажу сразу не понравилось. Во первых система весит достаточно прелично, работает жутко медленно (одно только создание пустой базы заняло 2-3 минуты). ИМХО, это не тот критерий по которому выбирают систему для Enterprise приложений. Камаз медленне жигулей, зато везет больше. Что посоветуете? ИМХО, неоспоримые достоинства ИБ для "офисных" БД могут являться недостатками для Enterprise. Ну например бэкап. На Оракле (например) я могу восстановить состояние системы на "за секунду до взрыва". На ИБ такое не сделаешь вроде. Там только простой возврат на бекап. Каждый день его делать для здоровой БД не фонтан. А потеря данных даже за час работы бывает очень критична. Чем больше настроек можно сделать тем лучше можно обеспечить работу для разных приложений/юзеров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2003, 10:58 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
На сайте создателей компонентов FIBPlus читал статью о том, как один из создателей в Германию ездил, продукт толкал. Нувот, там упоминается, что InterBase используется в компании - провайдере сотовой связи, кажется, хранилище системы биллинга. Ну, еще от типа запросов зависит. Если "короткие" пишущие транзакции, и "длинные" читающие, то почему нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2003, 11:16 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Использовать в принципе можно, но осторожно. Тесты требуются, 300 пользователей - это в любом случае серьезно. НАдо ставить классик, и предпочтительнее на nix. Я тестировал в начале лета FB1.5RC4, с кешированием у него все в порядке, чего, действительно, нельзя сказать про IB5 & 6. Для 300 пользователей понадобится примерно dual P4 3ГГц, памяти минимум 512, лучше гигабайт. Классик у меня по-умолчанию жрал памяти раза в два больше супера. Ессно, два RAID для дополнительного зеркалирования БД, как уже сказано, бекап созраняет данные только на момент его начала. К сожалению, FB1.5 супер в моем тесте больше 250 коннектов не держал, слетал. НАсчет RC7 - не знаю, но должен. Тест был очень напряженным, клиенты как можно быстрее тянули записи с картинками, и обновляли записи без картинок. Отлетала сеть после 250, скорее, это болезнь уже win2000, но в любом случае надо пробовать. Классик, кстати, можно настроить параметрами так, что будет работать примерно как супер на большом количестве коннектов. В заключение скажу, что я бы не рекомендовал использовать IB и клоны в такой конфигурации. Это возможно, но требует очень много эмпирических подгонок. Хотя, если большей частью просто чтение - потянет, уверен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2003, 11:34 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
2Roman Ignatiev Ессно, два RAID для дополнительного зеркалирования БД От физических сбоев это предохранит. А вот от фатальных ошибок пользователя.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2003, 11:43 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Была у меня подобная проблема, решение было найдено без смены сервера БД и это как уже говорилось Classic. Но нужно ответить на следующие вопросы: 1. Твоя задача какому типу больше принадлежит - OLTP или DSS ? 2. 20 % заполнение нагрузки сервера выполняется или более 20% - то есть одновременно сервер отрабатывает запросы более 20% пользователей ? Ответы: 1. если во основном DSS то сервер менять нада - смотри в сторону DB/2, Informix 2. Решение есть если задача в основном OLTP - чем больше процессоров и памяти - тем лучше - еще нужно менять параметер DATABASE_CACHE_PAGES рассчитывая размер соединения и правила распределения памяти классика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2003, 12:00 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Кто там мне не верил про 30 Мб? :-) Вот полезная статья , там как раз это есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2003, 12:01 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
В догонку - 1. ОС - это должна быть кто то из юниксов. 2. Вопрос оптимзации запросов становится острым на таких объемах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2003, 12:03 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Похоже, при такой нагрузке требования к аппаратуре для разных серверов (Oracle, InterBase, MSSQL) не очень отличаются. Так что читайте спецификации по требованиям к HardWare, приобретайте оборудование и тестируйте... Будет плохо с InterBase/FireBird - придется что-то другое выбирать. В любом случае, при использовании Oracle e.t.c. затраты на оборудование будут незаметны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2003, 14:34 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Спасибо всем за отклики! Насчет апаратуры так это не проблема. Даже Dual Xeon с прилинчой конфигурацией, SCSI и RAID стоит меньше 3 штук, так что сами лицензии с легкостью перегонят цену харда. Самое главное это надежность, скорость и low maintance. Так чтобы поставили, наладили и все гладко работало, ну конечно если бомба рядом не взорвется и т.д. :) Вот поставил MS SQL 2000, вроде поставился сразу без проблем, не так уж и сложно работать. Написал простенькую програмку потестировать INSERT и скажу не в восторге. Для примера в ИБ в такую же таблицу удалось вставлять 12000 записей в секунду, а SQL максимум дотянуло до 920. Тест велся на тойже машине, такая же таблица и все условия примерно такие же. Насчет юзеров, так 300+ как раз и будут все время висеть :) А всего юзеров может перевалить за тысячи. Хотя эти 300 в основном будут только селектить. Вот думаю а как симулировать такое? Может написать прогру которая создаст столько соединений и начнет бомбить сервер? Если бы кто обясни что такое DSS и OLTP? Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2003, 22:01 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
2TheOne Насчет юзеров, так 300+ как раз и будут все время висеть :) А всего юзеров может перевалить за тысячи Я бы все таки стал смотреть в сторону коммерческих серверов. Для Энтэрпрайз задач нужны Энтэрпрайз инструменты. Причем надо покупать вместе с саппортом . Иначе мало ли чего... Труд тысяч человек псу под хвост... Повесят за яйца, однозначно. Написал простенькую програмку потестировать INSERT и скажу не в восторге. Да брось ты фигней заниматься. Че ты тут проверишь? Если ты этот сервер поставил впервые в жизни, то как ты можешь знать, что "такая же таблица и все условия примерно такие же.". К тому же в одиночку перенести 1000 мешков из комнаты в комнату и 1000 человек по одному мешку - это две большие разницы. Если бы кто обясни что такое DSS и OLTP? OLTP - оперативная обработка транзакций. Когда все читают/пишут/правят примерно в одинаковых пропорциях. DSS - система принятия решений. В основном тяжелые запросы на чтение с аналитикой. Чистые OLTP и DSS системы в природе встречаются редко. В основном смесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2003, 09:24 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
>Gold Цитата: "ДК - объем памяти клиентского процесса в Classic зависит от базового количества страниц кэша (75) и от количества метаданных в базе" Из этого следует, что можно ограничить кол-во памяти на одного классик-клиента. С уважением, Denis Uskov ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2003, 09:59 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Приветик. В принципе можно рассмотреть вопрос о создани многоуровневых приложений. ИМХО при 300+ пользователях на любом сервере гайморит поимеешь. Если задача не очень сложная то можно с криком ура попробовать свой интерфейс между сервером и клиентами, который будет принимать данные с клиентов и писать в базу. А читать клиенты прямо из базы, изврат конечно, но работать будет шустрее Oracl'а. :) Я на буржуйских форумах встречал упоминание о конфигурации клона ИБ с 500+ пользователями. Правда там пользователи много читали и мало писали. Дык всё работало на двух процессорах и 1 Гб памяти. Опять же, народ писал что под виндой они это пустить не смогли по причине глюкавости винды, она глючила при 300+ соединений, так что всё работало под *nix. Еще, насчёт того, что Oracle позволяет восстановить всё "за секунду до взрыва". Теория, однако, гласит что если ИБ упал, то все закрытые тразакции не пострадают. Хотя это конечно теория :). Но мой опыт работы с MS (с Oracle не работал) говорит о том, что если падает нагруженный MS, то с база может сильно пострададть. Да и глюки с бэкапом/рестором на MS были конкретные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2003, 10:29 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Всем привет. Большое количество одновременных коннектов можно снизить. Я, например, знаю пару способов. Пока пользуюсь одним. Оба способа основаны на трёхзвенке и поэтому коннектами управляет сервер-приложение. 1. У компонента TIBDatabase есть проперть IdleTimer. Устанавливаю его в 300000. Если в течении 5 минут пользователь не обращается к базе, значит он осмысливает свои действия или разговаривает с клиентом(посетителем), что-то заносит в свой ClientDataSet или вообще писать пошёл. В этом случае коннект будет разорван. Когда юзер захочет, сохранить свой локальный набор, коннект восстановиться (уже без ввода пароля). В общем юзер никогда не знает есть коннект с базой или нет, ему по барабану. Сохраняется только коннект с сервером приложений. 2. Коннект с базой происходит только на время испонения SQL запроса. Затем сразу disconnect. Фишка в том, что при таком раскладе при 30 одновременно работающих пользователях, число одновременных коннектов не превышает 4-х, 5-ти. Таким образом можно немного обойти ограничение лицензии. Есть одно неудобство - любой запрос выполняется на несколько миллисекунд дольше (время коннекта). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2003, 11:22 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
Вот ссылка http://sr.kiev.ua/howto/TextHelp/Others/FAQ-IB-FB/Answer/FAQ-Ib-Fb-22.htm Обрати внимание что последние 2 проекта явный Enterprise. И что характерно не жалуются :) Даже наоборот :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2003, 14:30 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
У меня интернет-система на Firebird 1.0. Веб-интерфейс на PHP. 800 пользователей базы. 300 тыс записей в базе. Онлайн постоянно порядка 50 пользователей. Сервер 2xPentium IV 1.4, 512 Mb RAM. Проблем никаких, все очень шустро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2003, 15:02 |
|
||
|
Стоит ли исползьовать Firebird в Enterprise приложениях
|
|||
|---|---|---|---|
|
#18+
To Серега ну сервер я конечно впервые поставил, но таблицу созадть научился :) И создал также как и в ИБ стояла. Но вот что интересно. Написал Threaded програмку, каждый сред свой конекшен имеет и все такое и каждый вставляет скажем по 100 записек. Получилось что 20 средов выдержало, после этого начало резко тормозить а когда попытался поставить 100 начал получать connection refused. Надо теперь пробовать тоже самое на MS SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2003, 22:40 |
|
||
|
|

start [/forum/topic.php?fid=40&tid=1579533]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
153ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 472ms |

| 0 / 0 |
