Oracle, это даже не вопрос..... стандарт де-факто!

Цитата(Pegas @ 02.11.2002, 12:57)

Oracle, это даже не вопрос..... стандарт де-факто!

Стандарт то он конечно стандарт, спору нет хорошая база особенно если пишется что-то жутко большое, но вот незадачка - цена-то кусается, и даже очень! Тот же MS SQL Server при практически той же производительности стоит в 3 раза дешевле, а на многопроцессорных системах цена может различаться уже на порядок, про более дешёвые сервера я уже молчу, их нет даже смысла сравнивать с Ораклом. У нас на фирме было время начали задумываться на переходе на Oracle, но подсчитав все плюсы и минусы выяснилось что будет в 3 раза дешевле купить ещё штук 5 серверов и установить MS SQL Server и что аналогичной производительности можно добится на MS SQL Server увеличивая число серверов и докупая железо, что обойдётся гораздо дешевле...

Коллеги, а чем вам InterBase не нравится ?  Очень простой, очень компактный, очень надежный и очень мощный сервер. Его клоны под названиями FireBird (Штаты) и Yaffil (Россия) даже бесплатны. Сервер кросс-платформенный, имеются драйвера ODBC, JDBC, OLEDB-провайдеры, SQL-линки для BDE, компоненты прямого доступа для Delphi и BCB; и коммерческие, и бесплатные. Можно работать напрямую с IB API. Сервер полностью поддерживает ANSI SQL-92 Entry Level. Его российский клон Yaffil также готовится в embedded-варианте, встраиваемый прямо в разрабатываемое приложение. В общем, арсенал для работы с InterBase вполне приличный  

А есть у кого-нибудь реальный опыт работы с IB и c MS SQL/Oracle чтобы он мог поделиться впечатлениями? Прес-релизы, реклама, документация это одно, а реальный опыт это другое, особенно если есть опыт работы с обоими серверами, чтобы была база для сравнения...

Шесть лет работаю на InterBase   С позиций опыта имею основания заявить, что IB вполне покроет сектор от малых проектов, до средних и сложных (даже иногда залезая в тяжелые - есть сведения о базе размером в 180 Гб, работающей под InterBase). С размером рабочего дистрибутива сервера IB - ~900 Кб - не может поспорить даже local-Paradox !!! Также пробовал MSSQL, но отказался от него. Главная причина отказа - InterBase практически не требует администрирования, что делает его очень предпочтительным в тиражируемых системах. Мой личный рекорд - база ~300 Мб, проработавшая "без ухода" в течение 4 лет.   А мощь InterBase мало в чем уступает мощи MSSQL...
А в стане "соперника" - клона FireBird - готовится сервер нового поколения с еще большими возможностями. Об InterBase, его клонах и инструментарии лучше читать тут - http://www.ibase.ru

Очень интересно. Мои требования к серверу баз данных для тех продуктов которые я разрабатываю примерно следующие:

1) Поддержка баз данных размером до 200-300 Gb
2) Одновременное подключение около нескольких тысяч пользователей - возможно, что каждый под своим логином (пока можно считать разумным максимум в 5000 одновременных подключений)
3) Примерное количество запросов - до 100 в секунду (имеются ввиду простые и небольшие запросы), задержки времени выполнения запроса более 1 секунды не допустимы
4) поддержка не менее десятка баз данных на одном сервере
5) поддержка репликаций, DTS
6) поддержка удалённого доступа (через интернет)
7) поддержка tape backup
8) поддержка многопроцессорных серверов
9) поддержка true loading balansing

Есть ли такие возможности в IB и насколько хорошо они работают?

По п.1. Я сам, конечно, с такими гигантскими базами не работал еще   Скажу только следующее - база IB может резаться на части до 2Gb (InterBase <=6.0) и до 4Gb (Firebird, IB > 6.0), всего может быть 65536 частей. Так что суммарный размер базы может быть вполне приличным.

По п.2. Нет проблем, число подключений ограничивается только "пропускной способностью" ОС и железа.

По п.3. Тоже нет проблем. Скажу больше - со скоростью работы IB может конкурировать, пожалуй, только Oracle. Конечно, на простых тестах с одним-двумя-тремя-десятком коннектами показатели IB не столь впечатляющи, как, скажем, у MSSQL. Но InterBase - сервер с версионной архитектурой, в котором блокировки отсутствуют, как класс. И во всей красе он себя проявляет при одновременной интенсивной работе большого кол-ва юзеров, с большим числом транзакций, запросов и т.д. В нем нет, например, такой неприятной проблемы MSSQL, как эскалация блокировок (правда, я не в курсе возможностей новейших версий MSSQL). Ну и плюс, конечно, железо - на рядовой писишке вряд ли высокую скорость получим...  

По п.4. - тоже никаких проблем, баз может быть сколько угодно. Но! В одной базе можно обращаться только к собственным объектам (таблицам, вьюхам и т.д.). К объектам других баз обращаться нельзя (в-принципе, это правильно, т.к. противоречит принципам целостности данных). Если такая фишка нужна - придется писать приложение/аппсервер, который подключается к разным базам, и выдает юзерам select по объектам из разных БД.

По п.5. Вот этого, к сожалению, нет. Может быть, будет в сервере FireBird нового поколения. Для нынешних версий есть репликаторы от сторонних производителей, которые добавляют к таблицам служебные поля, создают служебные триггеры и т.д. для обеспечения механизма репликации.

По п.6. Никаких проблем - протоколы NetBEUI, IPX/SPX, TCP/IP. Плюс локальное подключение к файлу базы (желательно в однопользовательском режиме, чтобы не испортить базу), ежели сетевые протоколы не установлены. Клон Yaffil, помимо этого, содержит экспериментальный локальный протокол XNet, для быстрого и безопасного локального подключения (предназначается для использования в embedded-версии).

По п.7. Есть утилита GBak для снятия бэкапа. Стартует как юзер в snapshot-транзакции, делает backup закоммиченых на момент старта транзакции данных (юзеры при этом продолжают работать). Для больших баз настоятельно рекомендуется делать контрольный restore на другой машине. Во избежание.
Иногда встречаются базы с такой навороченной логикой, рекурсиями в триггерах, рекурсиями в calculated-полях и т.п., что restore такой базы просто не проходит.

По п.8. Надо отметить, что InterBase существует в 2 вариантах - ClassicServer и SuperServer. Первый - отдельный процесс на каждый коннект + процесс-диспетчер. Отлично масштабируется на многопроцессорных серверах. Второй - сервер представляет собой один процесс, каждый коннект создает отдельный поток. Масштабируемость у него - хреновая, в силу многих причин. Зато очень быстр на большом кол-ве коротких запросов, да еще и общий для всех юзеров кэш (в Классике - отдельный кэш на каждый процесс). В новом FireBird пытаются это исправить и создают SuperServer2, который хорошо будет масштабироваться на несколько процессоров.

По п.9. Этого точно нет, потому как не нужно в силу архитектурных особенностей InterBase.

Цитата

сервер с версионной архитектурой, в котором блокировки отсутствуют, как класс.

Дык иногда они нужны, хотя конечно очень редко.

Цитата

К объектам других баз обращаться нельзя (в-принципе, это правильно, т.к. противоречит принципам целостности данных).

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

Цитата

Select a From server1.database1.table1,server2.database2.table2 where server1.database1.table1.field1=server2.database2.table2.field2

мне очень нужны.

Цитата

По п.5. Вот этого, к сожалению, нет. Может быть, будет в сервере FireBird нового поколения. Для нынешних версий есть репликаторы от сторонних производителей, которые добавляют к таблицам служебные поля, создают служебные триггеры и т.д. для обеспечения механизма репликации.

Очень существенный минус

Цитата

По п.9. Этого точно нет, потому как не нужно в силу архитектурных особенностей InterBase.

Как это в смысле не нужно? Например у меня сервак который во первых не справляется с нагрузкой, во вторых должен работать ни на минуту не прерываясь - у нас договор, что каждая минута простоя оплачивается в тысячи долларов. Никто не гарантирует что на компе может слететь винт или сгореть процессор... Следовательно ставим например 3-4 сервера вместе, устанавливаем true loading balancing и все 3 компьютера работают как 1 сервер - запрос отправляется наименее загруженному серверу, если один компьютер сдыхает - пользователь этого даже не замечает - система продолжает работать без него без всяких проблем.

В целом, с твоих слов, складывается впечатление что IB довольно неплохой сервер, особенно для маленьких проектов, однако с администрированием у него большие проблемы - для средних и крупных проектов он мало пригоден, здесь как всегда вне конкуренции MS SQL и Oracle

Цитата(Guest @ 07.11.2002, 16:58)

InterBase практически не требует администрирования

Штука это обоюдо-острая! Автоматическое администрирование существенно упрощает жизнь новичкам-разработчикам и клиентам, но одновременно с этим очень сильно сужает возможности , делает продукт почти непригодным для средних и больших проектов, когда администрирование начинать играть очень большую роль - backup, subscription, replication, DTS, назначение пользователей, настройка кластеров, настройка взаимодействий серверов и т.п. Мне в этом плане нравится MS SQL Server 7.0/2000 - он вообще без настройки и всякого администрирования позволяет работать на малых проектах, а по мере усложнения можно всё больше и больше вмешиваться во все аспекты работы сервера.

> Автоматическое администрирование существенно упрощает жизнь новичкам-разработчикам

Под минимальным администрированием в InterBase понимается вот-что - достаточно сделать операцию backup-restore файла базы, чтобы все было ОК. При этом производится сборка мусора, перестройка индексов, отметка испорченных страниц, если таковые будут и т.д. Для прочих манипуляций, таких как работа с юзерами, раздача грантов, etc, существует масса инструментария от сторонних производителей, разной степени юзабельности. Если база+программа относительно сложные - должен быть админ БД !
А InterBase особенно привлекателен для клиентов, у которых нет админов, и программный комплекс работает самостоятельно и не требует присмотра.

> Как это в смысле не нужно? Например у меня сервак который во первых не справляется с нагрузкой, во вторых должен

Короче, получается кластер ? InterBase имеет такую штуку, как shadow - теневую копию базы. Делаем несколько массивов RAID, на одном - база, на остальных - теневые копии. По мере последовательной порчи страниц или выхода из строя массива InterBase подключает очередную по счету теневую копию. Управление массивами осуществляется несколькими компами, объединенных в кластер, где перераспределение нагрузки производит ОС, а не сервер БД (это не его функции, однако!). И я не верю в существование серверов баз данных, для которых не нужно проводить профилактику с остановкой сервера. Не царское это дело - непрерывность процесса обеспечивать... В любом случае это получается некая программная система, задействующая возможности сервера БД, ОС, сети и т.д.

> В целом, с твоих слов, складывается впечатление что IB довольно неплохой сервер, особенно для маленьких проектов,

Для маленьких - в особенности годится. Я уже не использую ничего другого в подобных проектах, никаких проблем InterBase мне не доставлял. Для администрирования пишется маленький bat-файл, где производится сеанс backup-restore, и обучается девочка простому клику мышой после окончания рабочего дня или недели  

Цитата(Guest @ 08.11.2002, 08:50)

Короче, получается кластер ? InterBase имеет такую штуку, как shadow - теневую копию базы.

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

Цитата(Guest @ 08.11.2002, 08:50)

И я не верю в существование серверов баз данных, для которых не нужно проводить профилактику с остановкой сервера. Не царское это дело - непрерывность процесса обеспечивать... ;-)

Таких действительно нет, но речь не об этом, мы тоже делаем профилактику (точнее никакую ни профилактику, а глобальные изменения структуры баз данных и софта) пару раз в год, при этом мы за месяц предупреждаем всех клиентов что например в ночь с субботы на воскресенье с 20:00 до 21:30 сервис будет выключен, я же говорю о внезапных поломках системы - например драйв посыпался, блок питания перегорел, мамка сдохла, и т.п. При таких ситуациях сервис не должен прерываться ни на одну секунду, так как клиенты заранее не были предупреждены.

Посмотрите информацию на сайте www.shushu.boom.ru там интересненькая база данных на высоких скоростях и бо о о льших обьемах данных

Цитата

Так что суммарный размер базы может быть вполне приличным

А backup, а в особенности restore базы такого объема будет длится тоже вполне приличное время - не менее нескольких суток. Ничего не имею против - Interbase замечательный сервер, но ИМХО ниша его - базы <10-15 Гб и юзеров <200.

ИМХО ВЫ не правы (если вы имеете в виду firebierd) то вот ссылка Читать здесь