Все новости от 25 июля 2001 г.

Продолжаем искать альтернативы

Тема популярности СУБД на мировом и отечественном рынке интересует многих читателей. В ответ на заметку “Есть ли альтернативы Oracle и DB2?” (см. PC Week/RE, № 20/2001, с. 45) пришло несколько писем, из которых мы публикуем два, на наш взгляд, наиболее интересных письма (их авторы высказывают личное мнение).

DB2 — лидер в технологическом плане...

В порядке восстановления исторической правды и устранения политнекорректности в отношении Oracle хотелось бы прежде всего расставить точки над i: “кто первее” на рынке клиент-серверных СУБД.

Пятая версия сервера Oracle, где появился SQLNet, действительно вышла раньше, чем Sybase (не сразу официально названная клиент-серверной). Вышедший несколько позже SYBASE SQL Server изначально был предназначен для работы в клиент-серверной архитектуре.

Поэтому, когда в Sybase говорят, что SQL Server был первой c/s СУБД, то это означает, что в компании Sybase вообще никогда не существовало не клиент-серверного продукта. Технически Sybase еще в 1992 г. могла сделать “универсальный сервер”, но решила, что и так хорошо.

А с DB2 ситуация примерно следующая. Раньше они вообще не ориентировались на отличные от IBM платформы. Даже для OS/2 была очень скромная версия. Но с середины 90-х годов появились полноценные версии DB2 для NT, Solaris, SCO Unix, HP-UX, затем для Linux и т. д.

Так что сейчас стоит говорить только об успешном или неуспешном росте доли DB2 в чужих сегментах, потому что в своем их потеснить довольно непросто. На IMS-DB продано около 17 млн. клиентских лицензий. У Oracle на мэйнфреймах мизерное количество установок, поэтому то, что они по TPC-C обогнали DB2 на pSeries, погоды для них вообще не сделает.

А уж если искать ответ на вопрос, какая СУБД на компьютерах IBM самая быстрая, да еще по тестам TPC, то лучше это делать на www.tpc.org, но никак не на сайте самого Oracle.

Тесты TPC, пожалуй, наиболее объективны. Они безусловно не всеохватны, но зато в них регламентировано моделируемое окружение теста, а результаты проходят две фазы аудита. Моделируемые в TCP задачи сильно отличаются от реальных, однако возможность откровенного жульничества минимизирована.

Если же возвращаться к истории, то именно Oracle больше всех любила TPC-A (как наиболее подходивший для подгонки под технологические возможности СУБД). После того как этот тест был отменен, Oracle обнародовала все свои не прошедшие аудит результаты (формально ничего не нарушив), а вот про TPC-C говорила, что он плохой и корпорация вообще будет его игнорировать (пока не улучшила свой сервер). Злые языки утверждали, что так называемая loop-back-оптимизация, реализованная Oracle, нигде, кроме TPC-A, и не нужна.

Три года назад, когда Oracle оказалась вытесненной по результатам TPC-C с SMP-платформ, она пыталась отыграться на Microsoft — мол, покажите нам, как SQL Server работает на OLAP-задачах. Теперь эти призывы с заглавной Web-страницы сайта Oracle убраны, так как и по TPC-C на кластерах, и по остальным TPC-тестам СУБД Oracle обогнали все кто хотел.

Когда Microsoft SQL Server показывает в OLTP- и OLAP-тестах высшие результаты, то это означает, что времена Microsoft/Sybase SQL Server 4.x (СУБД, имевших единый корень) ушли и MS SQL Server стал СУБД, сравнимой с остальными на очень больших задачах.

Просто в отличие от Oracle MS SQL Server до версии 7 не мог утилизировать ресурсы какого-нибудь железного монстра. С 7-й — научился. А в 2000-й версии упростилась работа с кластерами. Oracle ведь тоже не на одном процессоре тысячи запросов обрабатывает. Но и на кластерах СУБД Microsoft по-прежнему требует меньше ресурсов. Надежность в реальных задачах обеспечивается в основном за счет дублирования узлов, так что и этот вопрос SQL-сервер Microsoft решает “как большой”.

Раньше MS SQL Server выигрывал исключительно на том, что его проще “накрутить” на конкретную задачу, сам же он был не очень умным (как Oracle примерно). Теперь другое дело. Мне приходилось сталкиваться с примерами совершенно безалаберного подхода разработчиков к использованию MS SQL Server.

Попадались люди, которые о проектировании базы даже не задумывались. Имеется несколько сотен таблиц, и чуть что — добавляется новая. А это ведь OLTP-, а не OLAP-задача, и по 10 соединений в одном запросе — для OLTP многовато. Плюс администрирование того же уровня — все параметры выставляются на максимальные значения (пусть сам сервер разбирается, чего и сколько на самом деле нужно), и можно отдыхать. И это в системах на 300—500 пользователей!

MS SQL Server сейчас умнеет по образцу IBM — его новые возможности сосредоточены именно в области обработки данных. У Oracle же, по-моему, кризис жанра — они украшают сервер всякими добавлениями типа встроенного сервера приложений JServer, но ведь и у IBM, и у Microsoft есть мониторы транзакций (причем свои, а не купленные у Borland), просто они работают снаружи СУБД.

По техническим возможностям нынешний MS SQL Server сопоставим с DB2 и Oracle — при том, что удельные накладные расходы на пользователя меньше. А вопрос, потянет — не потянет для конкретной задачи, в большей степени относится к железу, а не к СУБД.

Я выслушивал истории от людей из американского Sun / Netscape Alliance о том, как ИТ-менеджеры проклинали их, когда исчерпывались ресурсы (n+1)-го восьмипроцессорного Web-сервера Sun и надо было выбивать деньги на (n+2)-й.

Если расставлять СУБД по полочкам, то, с моей точки зрения, локомотивом технологии остается DB2. Для IBM важна не столько производительность, сколько надежность и сбалансированность. IBM свою СУБД оптимизирует не на тупую скорость, а на скорость в несбалансированных задачах.

Я читал как-то их полузакрытые бумаги — политика IBM незатейливая и упрямая. Если новый алгоритм дает прирост производительности на 90% в существующих задачах, а 10% задач будут работать медленнее, то этот алгоритм отвергается. Причем ни хэш-индексов, ни оракловского connect-by-prior в DB2, как и в SQL Server, нет. Что там еще в Oracle — безблокировочное чтение? Тоже спорная вещь. И тоже нет в DB2.

Зато оптимизатор DB2/400 может “на лету” решить построить битовый индекс для оптимального выполнения запроса. Плюс рекурсивные запросы. Плюс СУБД-в-памяти (in-memory database — то, от чего Microsoft отступилась, а Oracle даже не приступала). Плюс полное отсутствие настроек оптимизации (optimizer hints) — IBM убеждена, что SQL-процессор должен сам строить правильный план доступа.

Но как будет конкретная СУБД (неважно, SQL Server, Oracle, DB2 и т. д.) вести себя в реальных задачах, предсказать все равно трудно. В обычной компании нет ресурсов, чтобы проводить более-менее объективное тестирование на более-менее реальной задаче. Да еще, как положено, в многопользовательском режиме. К примеру, проведение одного теста TPC-C, когда он только появился, отнимало полгода времени и обходилось в несколько сотен тысяч долларов.

Вадим Индриков

...А Oracle — лидер в плане организационном

Я работал на предприятии электросвязи г. Кирова и застал переход с биллинговой системы на базе DB2 на систему большего масштаба (но вполне реализуемую на DB2) на Oracle, вызванный следующими причинами:

1) недостаток в штате квалифицированных сотрудников, способных сопровождать DB2;

2) отсутствие региональных представителей IBM и соответственно поддержки на месте;

3) наличие регионального представителя Oracle, обеспечивающего поставку и сопровождение.

Были еще моменты, связанные с условиями приобретения СУБД и, насколько я знаю, не в пользу IBM.

Из опыта общения с коллегами с других предприятий могу привести еще один существенный фактор, влияющий на выбор СУБД, — “опыт” системного интегратора, на который руководители предприятий полагаются подчас безоглядно. Для региона этот фактор существен, так как число системных интеграторов невелико и выбор зачастую определяется не здравым смыслом, а степенью знакомства.

Евгений Шихов