ЭЛЕКТРОННАЯ БИБЛИОТЕКА КОАПП
Сборники Художественной, Технической, Справочной, Английской, Нормативной, Исторической, и др. литературы.


гадать на будущее онлайн - подробнее. Узнайте!

 

Что мы тестировали

                                         Марвин Брайан
                                         Marvin Bryan

     Мы выполняли шесть тестов для выяснения характеристик каждой из
шести оцениваемых СУБД при помощи базы данных, состоящей из банка вре-
менно предоставленной информации, которая в качестве отчета поступала
в Федеральное правительство от фирмы Home Mortgage Disclosure Act. Ба-
за данных включала 16 символьных и 11 числовых полей. Выборка, состоя-
ла из 5000 записей. Также проводился тест на скорость индексного чте-
ния (Index Read) на выборках в 5000 и 50000 записей для того, чтобы
увидеть будут ли скорости выполнения оставаться сравнимыми со скорос-
тями, получающимися при обработке меньших файлов. Некоторые СУБД хоро-
шо работают с более маленькими файлами, но "вязнут" на более больших.
Именно это происходило с DataEase'ом, который постоянно " дергался и
пыхтел" на дисковом драйвере, когда в течение 72 часов на нем "тянули
пробку" и снимали данные тестирования.
     Используемое оборудование было предоставлено нам фирмами. Началь-
ные тесты проводились на Compag DeskPro 286, использующем 90 Мб жест-
кий диск фирмы Core International. Так как окончательные эталонные
тесты требовали больше дисковой памяти, то для этих тестов использо-
вался компьютер Tandon PAC 286. Это устройство идеально подходило для
целей тестирования: мы смогли отделить файлы программ от файлов баз
данных для каждого программного пакета, разместив их на собственных
съемных 30 Мб жестких дисках. Так как Oracle требовал дополнительной
памяти, то при его тестировании использовалась плата AST RAMpage Plus
286. Фирма Intel также предоставила Above Board, использовавшуюся для
доведения тестов до конца.
     Первый тест, Sequential Read (последовательное чтение), просто
измеряет время, требуемое для чтения всей выборки в последовательном
порядке (в порядке, в котором записи вводились).
     Второй тест, Indexed Read (5K) (индексное чтение), также подсчи-
тывает время, требуемое для чтения базы данных от начала до конца. Но
записи читаются в последовательности, отличающейся от последователь-
ности первоначального ввода. Для большинства СУБД это означает, что
операция сопровождается открытием индекса, хотя СУБД, основанные на
SQL, дают тот же результат при помощи команды запроса. Indexed Read
повторялся с файлами объемом 50 К . Результаты этого теста приводятся
отдельно.
     Indexed Rebuild (обновление индекса) измеряет время, требуемое
для обновления индексов из рабочего файла . Строилось два индекса,
один из которых основывался на единственном коротком поле, а другой -
основывался на более длинном ключе, состоящем из нескольких полей.
     Тест Sort (сортировка) исследует сколько времени требуется на
сортировку БД с теми же ключами, что и в индексном тесте.
     Тест Complete Calculation (полный подсчет) суммирует числовые по-
ля по всей базе данных в порядке индексирования, записывая результат в
в новую БД.
     Предложила тесты специалист по СУБД Мириам Лискин. Она также сде-
лала обзор по dBase III Plus и статьи по dBase IV и по семействам
dBase подобных продуктов.
     Для получения точных замеров времени были написаны программы для
каждого пакета таким образом, чтобы тесты проводились автоматически, с
записью начального и конечного времени тестирования.
     При оценке СУБД, функционирование которых основано на разных
принципах, приоритет отдавался тестированию специфических возможнос-
тей. Например, в случае вывода записей на экран в порядке, отличном от
того в каком они были введены, в традиционных СУБД, таких как dBase
III Plus необходимо использовать индексы. Однако другие СУБД достигают
того же результата без индекса, используя запрос. Следовательно, если
целью является вывод записей в другой последовательности, то измеряет-
ся время, затраченное на достижение этой цели наиболее эффективным ме-
тодом, не обращая внимания на то,- был или не был привлечен действи-
тельно индекс. В конце концов, пользователи, в основном интересуются
тем сколько потребуется времени на выполнение задания.
     Было потрачено много труда для того, чтобы тестирование проходило
в одинаковых условиях. Все продукты тестировались на одном и том же
компьютере с частотой 8 Мгц, на жестких дисках с одним и тем же време-
нем доступа - 40 мкс. Так как некоторые 286-е машины и драйверы явля-
ются более быстродействующими и все 386-е компьютеры более быстродейс-
твующие, то используя их, легко достичь лучших показателей для любой
из СУБД, используя те же БД. Важным моментом является то, что каждая
СУБД была тестирована и измерена при использовании идентичного обору-
дования.
     Более того, в течение этого тестирования СУБД, прилагались все
усилия для обеспечения сравнимых сред для всех эталонных тестов. Если
одна СУБД отображает записи на экран в некотором тесте, то при этом
обеспечивалось, чтобы и все программы выводили записи на экран. Это
важно, например, в Sequential Read тесте, где R:Base завершает тест на
50% быстрее, если найденные записи не выводятся на монитор. В Oracle'е
разница была даже более существенной.
     Рассматривалось также несколько других тестов, с которыми прово-
дились испытания. Среди них были: простой числовой подсчет, повторяе-
мый много раз (лучше, чем проводившийся сложный подсчет), простой под-
счет знаковых строк и учет времени, требуемый на импорт файлов. Из -за
ограниченного пространства они не включены в статью, тем более, что
они значительно менее важны для среднего пользователя, чем описанные
эталонные тесты.
     Если вы используете только маленькие файлы, то свойства и "друже-
любие" СУБД может иметь для вас большее значение, чем эти тесты. Но
если создается большая БД, то эти заметки заслуживают внимательного
рассмотрения.


Яндекс цитирования