Сергей Бобровский

     Сервер, не суетись под клиентом!

     Мудрость из ФИДО

Зачем выбирать СУБД?

Задача выбора СУБД рано или поздно встает перед большинством коллективов, разрабатывающих ПО. От этого стратегического шага подчас зависит, выживет ли компания или ее решение окажется слишком дорогим (медленным, немасштабируемым и т. д.) для заказчика. А ведь СУБД нередко выбираются просто по известному названию или по совету знакомых (бывают и “политические” причины, например приказное внедрение того или иного продукта).

Как выбирать СУБД?

Лучший способ, рекомендуемый профессиональными консультантами, - подробно изучить каждую СУБД (из списка заранее отобранных по наиболее очевидным критериям) с учетом решаемой задачи. Сгенерировать логическую модель данных можно с помощью CASE-системы, пробные версии СУБД сегодня легко доступны, и протестировать основные бизнес-операции будущей системы не очень сложно. Желательно попросить специалистов соответствующей компании - разработчика СУБД помочь в оптимизации их сервера под конкретную задачу и конкретное оборудование - выигрыш в эффективности может достигать тысяч процентов!

А вот всевозможные рекламные заявления и стандартные тесты, превратившиеся сегодня в средство маркетинга, использовать в качестве критериев отбора СУБД для серьезной системы нельзя.

Какую серверную архитектуру выбрать?

Особая тема - выбор архитектуры СУБД. СУБД может работать в файл-серверной архитектуре (ФСУБД), когда база данных находится на сервере, а обрабатывается на клиентских местах, в клиент-серверной (КСУБД), когда и хранение, и обработка данных осуществляется на сервере, или в распределенной (данные хранятся и обрабатываются в разных узлах сети). ФСУБД во многих случаях заметно обгоняют по производительности КСУБД, при этом они на порядки дешевле и способны устойчиво работать с сотней клиентских мест. Например, Андрей Ярцев из Витебска (yart@polymir.belpak.vitebsk.by) рассказал, как его коллективу удалось добиться оптимизации сложных запросов из FoxPro к большой базе, грамотно используя индексы, что повысило скорость выполнения этих запросов в тысячи раз!

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

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

Время выполнения теста, секунды

Но в КСУБД значительно возрастает нагрузка на сервер, который выполняет всю бизнес-логику, обычно представляемую в виде хранимых процедур. Это может вызывать задержки с обновлением экранов и т. д. Многозвенные системы, когда для сервера приложений выделяется отдельный компьютер, - тоже не идеальный выход. Чем больше компьютеров включено в цепочку обработки, тем ниже общая надежность системы.

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

Главный критерий выбора

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

Скорость обработки информации определяется способом доступа к данным. Эти способы можно поделить на 10 категорий (упорядоченных по снижению эффективности).

1. Работа с жестким диском на уровне команд контроллера. В хорошей ОС внутренняя система защиты такие режимы работы пользователей не допускает.

2. Низкоуровневые функции (классические fread/fwrite). Они представляют собой простые “оболочки” системных прерываний и выполняются очень эффективно, обеспечивая программиста минимумом сервисных возможностей.

3. Высокоуровневые функции (ReadFile/WriteFile в Windows), позволяющие работать с различными объектами ОС как с файлами.

4. Прямой доступ к файлам во внутреннем формате конкретных СУБД. Этот способ аналогичен созданию собственной СУБД и очень трудоемок, однако для локальных задач используется довольно часто - как правило, для быстрого создания отчетов путем считывания информации из файлов (в основном форматов db, dbf).

5. Прямой доступ к файлам, организованным в виде индексированных таблиц, из файл-серверных систем.

6. Промежуточные технологии доступа для конкретных платформ или средств разработки (Microsoft DAO, OLE DB, Borland BDE и т. д.).

7. Низкоуровневый интерфейс доступа к возможностям выделенного сервера. Выигрыш в производительности в сравнении с п. 8 обычно получается в 2 - 10 раз, но при этом не удается быстро переходить на другие СУБД и сильно усложняется процесс программирования. Некоторые СУБД имеют прямые средства доступа к информации в собственном формате, представляющие собой оболочки API-вызовов.

8. “Родные” (native) драйверы доступа к СУБД (например, SQL Links).

9. Драйверы, выполненные в рамках технологий ODBC (Open Database Connectivity), JDBC (Java Database Connectivity), UDBC (Universal Database Connection), X/Open, позволяющих приложению абстрагироваться от конкретных СУБД.

10. В процессе развития распределенных технологий предпринимаются попытки организовать высокоуровневую СУБД-независимую поддержку доступа к данным, но пока достигнутые результаты далеки даже от неформальных стандартов.

Тестирование методов доступа

Автор провел сравнительный анализ некоторых упомянутых методов доступа по следующей методике. Было принято, что производительность СУБД ограничена “базовыми” функциями записи в базу данных и считывания из нее. Никакие другие операции ввода-вывода в аналогичной архитектуре (например, работа в многопользовательских режимах DSS (поддержка принятия решений) или OLAP (онлайновая обработка транзакций) не могут превысить граничных значений.

Тестирование проводилось на ПК с процессором Pentium-233 и 32 Мб ОЗУ под управлением Windows 98. Тест представлял собой запись миллиона записей со структурой “ключевой индекс (целое число, 6 байтов) плюс строка длиной 50 байтов” в таблицу. Для клиент-серверных систем проводилось также контрольное считывание этой структуры. Время засекалось только по операциям ввода-вывода. Тест повторялся несколько раз. Разброс значений составил около 15%.

Время для пунктов 2 и 3 составило 10 - 30 с (в зависимости от размера буфера). Файл-серверный доступ к данным (пункты 5 и 6) тестировался на работе с форматами mdb (Access 7.0), dbf (dBase) и db (Paradox 7), при этом комбинировался доступ через DAO 3.5 и BDE из VC++ 5.0 и из Delphi 4. Диапазон значений составил от 1300 с (mdb, VC++, DAO 3.5) до 3200 с (dbf, BDE, Delphi 4). Связка db + BDE + Delphi 4 показала среднее время (2000 с). Медленнее всего функционировал Delphi 4 с “неродным” форматом mdb: 4800 с. И уж совсем никуда не годилась работа ФСУБД с данными через ODBC-драйверы (от 10 900 до 26 000 с).

Аналогично были протестированы три клиент-серверные СУБД (одна “легкая” и две “тяжелые”) в режиме локального сервера. Из-за плохого знакомства автора со способами оптимизации этих СУБД данные приводятся без упоминания конкретных систем, исключительно с целью дать общее представление о возможных различиях в производительности КСУБД и ФСУБД.

“Тяжелые” СУБД показали:

- 3800 с - запись через “родной” драйвер (11 300 с - через ODBC) и 500 с - считывание;

- 20 500 с - запись и 270 с - считывание. результаты “легкой” СУБД:

- 44 000 с - запись и 10 600 с - считывание.

Выводы

- На одной и той же ОС и компьютере производительность разных СУБД может различаться в десятки раз. Поэтому надо очень тщательно подходить к выбору СУБД для каждой задачи (даже в рамках одного проекта).

- Быстродействие во многом зависит от средства разработки, обеспечивающего доступ к СУБД. Наиболее эффективны связки “СУБД и система программирования одного производителя”. Например: Access и VC++; Interbase и Delphi; Sybase SQL Server и PowerBuilder; DB2 и VisualAge; Progress и Progress 4GL; Adabas и Natural и т. д.

- Самый эффективный способ доступа - работа через функции файловой системы. Это может быть полезно, например, при генерации отчетов. Производительность ФСУБД и КСУБД ниже возможностей ОС в тысячи раз. Такова плата за удобство работы, целостность данных и поддержку SQL.

- По базовым показателям производительности ФСУБД не сильно отличаются друг от друга, а КСУБД могут существенно разниться. Поэтому КСУБД надо выбирать, не считаясь с затратами на анализ ее возможностей. А к работе по созданию и внедрению программного продукта надо в обязательном порядке привлекать специалистов по оптимизации используемой СУБД.

- По результатам тестирования методов доступа, описанных в пунктах 2 и 3, файловая система FAT32 работает примерно на 20 - 30% медленнее, чем FAT16. Лучше не экономить несколько десятков мегабайтов на диске с помощью FAT32, а размещать файлы базы данных на логических дисках с FAT16.

- Технология ODBC практически всегда дает более низкую производительность. Поэтому следует очень осторожно подходить к системам, которые провозглашаются “платформно-независимыми” благодаря использованию ODBC-технологии. Скорость работы в ряде случаев определяется качеством драйвера, фирмой, его разработавшей, но при некорректном использовании этой технологии можно потерять в производительности от пятисот до тысячи процентов.

Можно ли выработать более-менее значимый критерий сравнительной оценки производительности СУБД (например, основываясь на тесте, описанном в данной статье)? Читатели предлагают сравнивать степень оптимизации запросов, создавать тесты, характеризуемые типами связей (“один-ко-многим”, “многие-ко-многим”) и их числом в тестовой базе данных и т. д. Хотелось бы услышать по этому поводу мнение пользователей и представителей компаний - разработчиков СУБД.

К автору можно обратиться по адресу: sbo@pcweek.ru.