|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #05-06/97
|
|
Я не случайно выбрал для своих заметок заголовок, вызывающий ассоциации с тем необозримо широким, хотя - увы - не слишком глубоким, потоком научных работ "среднекандидатского" уровня, который - я уверен - многим из читателей хорошо знаком. Дело в том, что я взялся порассуждать на тему тестирования СУБД, придав своим рассуждениям некоторое наукообразие. Поскольку сам по себе текст подобного рода я считаю духовной пищей, трудно перевариваемой во всех отношениях, я решил приправить его критическим (пожалуй даже очень критическим) рассмотрением конкретного примера тестирования СУБД, представленного в номере 4 "СУБД" за 1997 год в статье [1]. Не говоря уж о том, что сама статья как-то живо по стилю и глубине анализа напомнила мне некоторые работы, которые я уже считал для себя ушедшими в прошлое, мне кажется, что сама по себе тема, затронутая и в статье [1], и в комментарии к ней Е.Зиндера [2], заслуживает серьезного рассмотрения, а может быть и дискуссии.
В статье [1] - напомню - речь шла о тестировании различных СУБД для задачи резервирования железнодорожных билетов в масштабах страны, основная сложность которой заключается в необходимости обеспечить высокую производительность системы (до 250 транзакций в секунду) при значительном объеме данных. Важным побуждающим мотивом для меня к написанию настоящией статьи послужило то, что заметное место во всей данной истории с тестированием занял ORACLE. С уважением относясь к мнению авторов статьи и признавая за ними полное право делать собственные выводы о каких бы то ни было результатах каких бы то ни было тестов, я никак не могу согласиться с некоторыми формулировками и оценками, которые они приводят в отношении того, как было проведено тестирование со стороны Oracle (а в сущности тем самым в отношении команды, проводившей тестирование). Посколько я сам имел некоторое отношение к данному тесту, то я полагаю, что данная статья затрагивает и мою профессиональную честь тоже.
Хотя в явной форме нигде не говорится о "некорректности" действий при проведении тестов со стороны команды ORACLE, эта мысль фактически присутствует в статье, а вывод "при сравнительном анализе возможностей СУБД результаты ORACLE не будут приниматься в расчет" лишний раз свидетельствуют об этом. В статье приводится ряд претензий к процедуре тестирования ORACLE, которые, на мой взгляд, не дают читателям адекватного представления о причинах, позволивших ORACLE выиграть тест с таким преимуществом, что его результат пришлось "не принимать в расчет". Дабы не вступать в достаточно бесплодную полемику, я решил просто объяснить (не вдаваясь в глубокие подробности), как же все-таки ORACLE добился своих "некорректных" результатов, и пусть читатель сам судит, справедливы ли претензии авторов статьи, или с ними все-таки можно поспорить. Чтобы добавить еще некоторую порцию информации к этим размышлениям, я далее беру на себя смелость (и заранее прошу прощения за это) воспроизвести таблицу 6-1 из статьи [1], содержащую результаты тестирования, но с добавленной в нее еще одной строкой результатов ORACLE, которая зафиксирована в официальном протоколе (кстати, подписанном одним из авторов статьи), и которая, на мой взгляд, снимает целый ряд вопросов, но однако в статью [1] не попавшая. Далее я намерен высказать свою точку зрения на то, какова бы могла быть методика тестирования СУБД в рассматриваемом проекте, если поставить цель найти действительно оптимальное решение. Наконец в заключение я намерен порассуждать о возможных методиках тестирования СУБД вообще, и о том, почему иногда возникают ситуации, когда результаты тестов не хочется "принимать в расчет" (ибо увы, данный прецедент не единственный в нашей практике). Тут я фактически вступлю в дискуссию с Е.Зиндером, с которым я - предупреждаю сразу - во многом согласен, но кое в чем хотел бы и поспорить. Я намерен сформулировать некоторые принципы, которых я - в тех случаях, когда выступаю в качестве ответственного за проведение тестирования - стараюсь придерживаться, и намерен придерживаться в дальнейшем, исходя при этом не столько из моего положения как представителя корпорации ORACLE, сколько из своих личных убеждений. Последний принцип - опять-таки хочу предупредить сразу - относится ко всей моей статье в целом: я везде выражаю свою личную позицию, которая совсем не обязательно совпадает с официальной позицией корпорации ORACLE.
В исходном техническом задании на проведение тестирования содержалась логическая схема данных, подобная той, которая приведена на рис. 2-1 в статье [1]1. Кроме того, были приведены описания транзакций "Т1" (которая, строго говоря, транзакцией не является, ибо это запрос о наличии мест на поездах между требуемыми станциями) и "Т2" (собственно резервирование билета), которые необходимо было выполнить. При внимательном рассмотрении данных схем можно заметить, что они в значительной степени воспроизводят реализацию организации данных и алгоритмов доступа, характерную для использования инвертированных списков в СУБД типа ADABAS (по-видимому это определялось опытом составителей задания). Поскольку в задании не содержалось требования буквального следования приведенным схемам (что, на мой взгляд, абсолютно правильно!), было принято решение воспроизвести все функциональные требования, равно как и требования к содержанию данных, но при этом предложить такую организацию данных и методы доступа к ним, чтобы задействовать преимущества именно реляционной СУБД, а не ввязываться в довольно безнадежное соревнование с СУБД, базирующейся на инвертированных списках, в задаче переходов по ссылкам (а в конце-концов это ли нужно для того, чтобы оценить пригодность системы к решению конкретной практической, а не искусственной задачи?). При этом естественно было также использовать те (во многом уникальные) возможности по оптимальной организации хранения данных, которые обеспечивает ядро сервера ORACLE.
Несложный анализ характера транзакций Т1 и Т2 показывает, что поиск нужной станции обязательно сопряжен с последующим поиском информации о поездах, проходящих через нее (что, впрочем, очевидно и из элементароного здравого смысла). Выполнение такой опрерации в реляционной СУБД неизбежно предполагает т.н. "соединение" таблиц. Ясно также, что именно скорость выполнения указанного соединения во многом определяет и скорость выполнения транзакций в целом (хотя бы потому, что после того, как данные о проходящих через станцию поездах найдены, они уже автоматически считаны с диска в буфер в оперативной памяти, так что последующие операции не требуют обращения к относительно медленным устройствам ввода/вывода).
Описанные выше соображения привели к решению использовать т.н. кластерную организацию хранения таблиц станций и поездов. В кластерах сервер ORACLE по существу хранит таблицы в уже "соединенном" состоянии. В данном конкретном примере это означает, что за записью, описывающей очередную станцию, физически следуют записи обо всех поездах, через нее проходящих. Важно то, что такое группирование записей ORACLE выполняет автоматически, ориентируясь на значение т.н. кластерного ключа, т.е. ключевого поля (или группы полей), которое должно присутствовать в каждой таблице и по которому, собственно говоря, и выполняется операция соединения (в данном примере это, очевидно, название или код станции). Организация данных в кластер полностью прозрачна для приложений (т.е. они не зависят от того, кластеризованы таблицы или нет), отсутствуют также какие-либо ограничения на выполнение стандартных SQL-операций над данными кластеризованных таблиц. Безусловно, эффективность выполнения некоторых операций над данными в кластере ниже, чем в "обычных" таблицах (более конкретно речь идет о таких операциях, как UPDATE, которые меняют структуру хранения данных в кластере), однако в данном конкретном случае - согласитесь - операция перетряски расписания поездов случается гораздо реже операции продажи билетов, да и скорость ее выполнения далеко не столь критична!
Что касается организации самого кластера, то возможны два ее варианта. При первом с кластерным ключом ассоциируется обычный индекс (в виде B-дерева), по которому и осуществляется поиск записей, имеющих данный ключ. Во втором случае последняя операция выполняется путем вычисления хэш-функции от кластерного ключа (соответственно по значению этой функции и группируются записи в кластере). Именно этот вариант был выбран при тестировании: в самом деле, он позволяет за одну операцию проверить правильность входных данных, найти информацию о требуемой станции и обо всех проходящих через нее поездах. При этом в лучшем случае потребуется только одно чтение с диска (в худшем случае ненамного больше).
Кластерное представление связанных таблиц явилось решающим фактором, ускорившим выполнение транзакций (что и было фактически доказано при повторном тестировании, которое обсуждается ниже). Рассмотрим теперь все претензии авторов статьи к тестированию ORACLE (я буду цитировать их курсивом, а затем давать свой комментарий).
Введены вспомогательные данные, например, о количестве свободных мест каждого типа в поезде.
Почти верно. Почти, поскольку эти данные не "введены", а вычисляются "на лету" при выполнении каждой транзакции. Достаточно очевидная и несложная оптимизация, отнюдь не запрещенная условиями теста. Что же в ней некорректного?
Упрощены структуры данных, например, битовая кодировка мест.
В первом варианте теста действительно использовались битовые строки для кодировки мест, что, впрочем, едва ли можно считать "упрощением". Это скорее опять-таки несложная оптимизация, к тому же не имеющая решающего значения (что было доказано повторным тестом).
Сделаны определенные допущения о максимальном количестве поездов, проходящих через одну станцию, а также о последовательности станций на маршруте.
А вот это уже принципиально неверно. Никаких допущений подобного рода (в смысле ограничения функциональности теста) не было. Первое утверждение основано, скорее всего, на результатах обсуждения свойств хэш-кластеров между представителями ORACLE и представителями заказчика тестов. Наша команда играла "в открытую" и ничего не пыталась скрывать. В частности, шла речь и о том, что одним из параметров кластера является размер области на диске, сразу отводимой под хранение записей, соответствующих одному значению хэш-функции (т.е. в данном случае фактически информации о поездах, проходящих через станцию). При этом неоднократно разъяснялось и подчеркивалось, что указанный параметр является чисто настроечным, т.е. никак не ограничивает максимальное количество записей с заданным ключом. Достаточно странно после этого читать о "допущении о максимальном количестве поездов". В данном случае в статье неправильно проинтерпретированы.
В действительности в связи с указанным параметром встал совсем другой вопрос (который в принципе был намного более оправдан по сравнению с претензией, высказанной в статье [1]). Состоял он в том, насколько изменится скорость работы с хэш-кластером в случае большого разброса в количестве проходящих поездов от станции к станции. Объяснения, что это во многом будет зависеть от возможности выделения дополнительного дискового пространства (можно выделить большую начальную область, допуская сразу, что для части станций она не будет заполнена полностью), но даже без этого эффект будет не очень значительным4, на веру приняты не были, и в повторном тесте было предложено смоделировать неравномерность количества поездов, проходящих через станции (я хочу подчеркнуть, что такое требование было выдвинуто только в отношении ORACLE, остальные СУБД тестировались при фиксированном указанном параметре).
Никаких предположений "о последовательности станций на маршруте" при подготовке теста не делалось.
В разработанных тестах отсутствует моделирование серий независимых заявок (одна заявка - одна транзакция) и случайности данных в каждой заявке.
В каждой из моделируемых заявок название станции выбиралось независимым случайным образом. Это же справедливо и для других параметров при выполнении транзакции Т2. Ограничение при этом состояло только в том, что при заявке на билет поезд выбирался из списка реальных поездов, проходящих через указанную станцию, полученного в результате транзакции Т1 (что вполне соответствует реальной жизни, ибо трудно представить себе потенциального пассажира, требующего билет на поезд, не проходящий через нужную ему станцию).
Собственно говоря, единственной серьезной (по крайней мере с нашей точки зрения) функциональной претензией к проведенному тесту явилось то, что в нем не была учтена возможность резервирования билета на место, освободившееся на промежуточной станции, расположенной по маршруту поезда до станции отправления пассажира. Хотя такое требование не содержалось в исходной спецификации теста (и оно не предъявлялось другим участникам тестирования), оно было сочтено справедливым и учтено при повторном выполнении теста со стороны ORACLE.
С учетом высказанных заказчиком претензий и пожеланий было проведено повторное тестирование (опять подчеркну - только со стороны ORACLE). Главным обстоятельством, повлиявшим на модификацию структуры данных, явилось последнее требование, упомянутое в предыдущем разделе (возможность резервирования места, освободившегося по маршруту поезда на промежуточной станции). Кроме того, фактически были удовлетворены и все остальные претензии, включая буквальное следование схеме данных из рис. 2-1 статьи [1] в одном из вариантов теста (далее этот вариант фигурирует под названием "тест с полностью нормализованной структурой данных"). Поскольку в вычислении "на лету" некоторых агрегированных значений с целью их использования для ускорения выполнения транзакций представители ORACLE по-прежнему не видели (и не видят) ничего некорректного, был выполнен также вариант теста с использованием таких значений ("тест с денормализованной структурой данных"). Количество поездов, проходящих через станции, моделировалось распределенным от 1 до 100, но не равномерно, а с пиком в районе 10. Результаты проведения теста зафиксированы в соответсвующем протоколе, поэтому я считаю возможным привести их в таблице, которая представляет собой не что иное, как таблицу 6-1 из статьи [1] с добавлением после строки 4 (относящейся к ORACLE) еще двух строк, отражающих результаты повторного тестирования с дополнительными требованиями.
Прежде всего я начал бы не с тестов как таковых, а с анализа проблемы и, соответственно, формулировки как задачи тестов, так и критериев анализа результатов.
Собственно говоря, сложность данной прикладной задачи определяется двумя параметрами:
Обсудим для начала первый из параметров.Сам по себе большой объем данных не представлял бы собой большой проблемы, если бы все эти данные можно было разместить в области оперативной памяти соответствующего размера. В самом деле, если скорость доступа к любому элементу данных одинаково высока независимо от того, в каком порядке осуществляется доступ (как это имеет место в оперативной памяти), то все "упиралось" бы исключительно в процессорную мощность (естественно при условии выбора оптимального алгоритма поиска по таблицам). Ввиду того, что такой вариант представляется нереальным (если он и возможен в принципе, то безусловно немыслимо дорог), то придется признать, что большой объем данных порождает проблему оптимизации доступа к системе кэширования данных на дисках, каковой в сущности является СУБД5. Соответственно сравнение (в том числе, и тестовое) различных СУБД должно обязательно включать вопрос о том, насколько эффективные методы минимизации обращений к диску (причем не вообще, а при выполнении конкретных наиболее критичных операций!) она предлагает. Недооценивать значение такого исследования ни в коем случае нельзя, ибо скорость обмена данных с самым быстрым диском несравнима со скоростью обращения к самой медленной оперативной памяти.
В принципе, независимо от выбора СУБД проблему можно смягчать путем увеличения объема оперативной памяти: тогда и значение упомянутого вопроса уменьшается. Однако нужно обязательно иметь в виду, что резервы повышения производительности за счет увеличения ресурса оперативной памяти далеко не безграничны - особенно в задачах класса OLTP (к каковому относится и обсуждаемая задача). Дело в том, что исключить необходимость обменов с медленным устройством (то бишь диском) нельзя, даже когда объем оперативной памяти превышает размер базы данных. Происходит это потому, что диск, в отличие от оперативной памяти, не только обладает значительно большим показателем емкость/цена, но еще и обладает свойством сохранять информацию в случае остановки программы или выключения питания. Поскольку последним свойством должна обладать и база данных, очевидно, что по крайней мере, записи информации на диск не избежать. Несомненным требованием к системе должно быть полное восстановление всех завершенных транзакций после сбоев (нужно иметь в виду, что некоторые СУБД позволяют работать в режимах, не дающих такой гарантии - что, естественно, получается быстрее, но для мало-мальски серьезной системы это попросту недопустимо). Общепринятым механизмом СУБД для достижения этой цели является ведение журнальных файлов изменений БД в сочетании с периодическими "контрольными точками" (т.е. переписыванием всех модифицированных блоков из буфера в оперативной памяти на диск). Эффективность выполнения данных двух операций становится во многом определяющим фактором для производительности СУБД при интенсивной транзакционной нагрузке и больших ресурсах оперативной памяти на сервере.
Если нет возможности провести тестовую проверку указанных механизмов (вернее, независимо от тестовой проверки, ибо "выделить" изучаемый эффект в тестовых результатах довольно сложно), необходимо тщательно проанализировать реализацию журналирования и контрольных точек в рассматриваемых СУБД. В качестве примеров приведу следующие вопросы.
Поиск ответа на эти (и не только эти) вопросы, еще раз подчеркиваю, очень важен, особенно если предполагается повышать производительность системы за счет увеличения ресурсов оперативной памяти на сервере.
Обсудим теперь вопрос о поддержке большого числа одновременных транзакций. При оценке СУБД здесь наиболее важными представляются два аспекта:
Первый аспект исключительно важен в силу того, что применение оптимальных алгоритмов доступа к данным, выполнения требуемых операций может оказать куда больший эффект на конечную производительность, нежели увеличение ресурсов, не говоря уж о "микрооптимизации" (типа "глубокой интеграции с ОС", которой часто придают преувеличенное значение6). Предположение о том, будто все СУБД имеют примерно одинаковое алгоритмическое наполнение, очень далеко от истины. Зачастую оптимальные решения конкретной задачи в различных СУБД могут принципиально различаться. С другой стороны, возможности выбранной СУБД сильно ограничивают разработчика в выборе оптимального метода доступа к данным (если только не принимается решение организовать собственную систему хранения данных, фактически подменяя универсальную СУБД в большинстве ее функций, что очень и очень трудоемко и может привести к многочисленным проблемам): в самом деле, не очень понятно, как можно полностью корректно реализовать, например, собственный метод индексирования данных в БД. Из перечисленных соображений следует вывод о том, что при тестировании необходимо для каждой СУБД использовать оптимальный для нее метод организации и доступа к данным, не ставя при этом искусственных ограничений, ибо они могут очень сильно исказить полученный результат.
Что касается масштабируемости (т.е. возможности СУБД адекватно адаптироваться как к увеличению нагрузки, так и к расширению конфигурации или увеличению мощности сервера), то ее исчерпывающая оценка по результатам тестирования, как правило, затруднена (иногда вообще можно получить только косвенные характеристики, которые нужно при этом уметь правильно интерпретировать). Поэтому начинать оценку масштабируемости СУБД стоит опять-таки с ее "теоретических" аспектов (немного выше я уже обсуждал фактически те из них, которые оказывают влияние на масштабируемость по параметру увеличения оперативной памяти). Перечислим (опять же только некоторые!) аспекты, которые необходимо проанализировать.
При тестировании некоторые данные о масштабируемости СУБД можно получить путем варьирования как нагрузки СУБД, так и ресурсов сервера. Хочу отметить сразу, что задача серьезно затруднена чисто технически, кроме того, если даже проведены замеры производительности при разных значениях параметров сервера, попытка экстраполяции полученной функциональной зависимости в область более высоких параметров (что собственно, как правило, и представляет интерес) сопряжена с возможностью серьезной ошибки.
С другой стороны есть косвенный показатель, который позволяет с высокой вероятностью оценить степень масштабируемости СУБД (с конкретным приложением разумеется) по заданномк параметру конфигурации сервера. Таким показателем является степень загрузки данного ресурса при проведении теста. Например, в рассматриваемой задаче при тестировании ORACLE процессор был загружен почти на 100%, что позволяет с высокой степенью уверенности говорить о хороших перспективах масштабируемости системы при увеличении процессорной мощности сервера (т.е. использовании более быстрого процессора либо подключении дополнительных процессоров). Мне остается лишь недоумевать, почему замер таких параметров не производился и не анализировался авторами статьи [1].
Попробуем теперь оценить с точки зрения предложенной концепции то, что реально было сделано. Во-первых, не видно никаких реальных оценок и анализа технологий СУБД с точки зрения поддержки высокой транзакционной нагрузки на больших объемах данных: есть только туманная фраза о том, что "любая из СУБД, участвовавших в тестировании, по функциональным возможностям принципиально пригодна для реализации на ее основе системы Экспресс-3", которая, в сущности, не несет в себе никакой информации. Те описания, которые приводятся в отношении тестируемых СУБД, носят чисто формальный характер, и опять-таки ничего не говорят по существу решаемой задачи. В этих описаниях, кроме того, допущены существенные неточности (во всяком случае, в отношении ORACLE - об этом ниже), при этом совершенно не понятен принцип выбора приводимых характеристик СУБД: с одной стороны они не дают никакого представления о технологических свойсвах систем, с другой - они не являются и отличительными признаками рассматриваемых СУБД на платформе OS/3909.
В отношении тестирования как такового, на мой взгляд, главное заключается в том, что отсутствует четкая формулировка как цели, так и методики его проведения. Если целью являлась оценка характеристик СУБД при решении поставленной задачи, то совершенно непонятно, зачем в таком случае был наложен (вернее даже не наложен формально, а как выяснилось в ходе проведения тестирования, подразумевался) целый ряд искусственных ограничений, не связанных с существом решаемой задачи? Тестирование СУБД в заведомо неоптимальном для нее режиме - что я обосновал выше - не дает никакой практически ценной информации. (в качестве аналогии представьте себе, что гоночные автомобили, предназначенные для эксплуатации на скоростной трассе, сравнивались бы по результатам их испытаний на проселочной дороге.) Полезными для оценки как пригодности СУБД, так и возможных путей повышения производительности системы до требуемого уровня можно считать лишь те результаты, которые получены в режиме, максимально приближенном к тому, который может быть использован в реальных условиях. С этой точки зрения "не приниматься в расчет" должны были бы не результаты ORACLE, а как раз результаты ADABAS и DB/2 (а если авторы считатают, что указанные СУБД тестировались в оптимальных для них режимах, то "не приниматься в расчет" должны были бы сами эти СУБД).
В реальности заказчики тестов поступили в точности наоборот. Поскольку результаты ORACLE оказались как бы слишком хорошими, их решено было "не принимать в расчет" (как кстати и саму СУБД ORACLE). Не могу отказать себе в желании прокомментировать выводы, сделанные авторами.
Реляционная модель данных и СУБД могут быть использованы для реализации системы "ЭКСПРЕСС-3".
Очень хорошо, хотя с учетом игнорирования результатов ORACLE непонятно, из чего это следует.
При следовании требованиям классической реляционной модели данных неизбежна существенная потеря производительности как по отдельным прикладным задачам, так и по всей системе в целом.
А вот это утверждение ничего, кроме недоумения, вызвать не может. Во всяком случае, из результатов теста это никоим образом не следует. Непонятно также, что имеется в виду под "классической реляционной моделью" (какая-то из нормальных форм?).
При использовании реляционной модели данных лучшие результаты показывает СУБД, специально ориентированная на поддержку SQL и реляционной модели.
Ну что ж, чтобы прийти к такому нетривиальному выводу, стоило провести дорогостоящее тестирование.
Реляционная модель данных приводит к существенному увеличению количества объектов, хранимых в базе данных и обрабатываемых прикладными программами.
Ну а это произошло в тесте только потому, что заказчики спроектировали реляционную модель данных, ориентируясь на структуру, характерную для инвертированных списков, но не для реляционных СУБД. Все бывает хорошо, только будучи примененным на своем месте.
Дальше - после игнорирования результаов ORACLE - перед авторами встала очень непростая задача: сформулировать, как же все-таки добиться необходимых характеристик системы, располагая данными, слишком сильно отличными от требуемого результата (согласитесь, между 11.90 и 250 разница весьма велика), чтобы можно было говорить о решении, обладающем сколько-нибудь приемлемой степенью предсказуемости и реалистичности. Попробуем проанализировать, что же они предлагают.
Применение данных специального типа (битовые шкалы).
Ну что ж, это действительно некая оптимизация, вопрос лишь в том, насколько существенный эффект она способна дать. Сравнение результатов ORACLE в первом и повторном тестировании может дать представление об этом.
Группирование однородных значений данных (множественные поля). Группирование однородных структур данных (периодические группы).
Интерпретировать буквально эти предложения можно только в контексте СУБД типа ADABAS, в то время как ориентация вроде бы принята на реляционную СУБД. Если руководствоваться только результатами тестов (а тест для ADABAS, насколько я понимаю, включал указанную оптимизацию), то оснований для серьезного оптимизма по поводу конкретно понимаемого данного предложения не видно. Другое дело, если речь идет об оптимизации представления данных вообще. Тут нужно учесть и особенности реляционной модели вообще и особенности конкретной СУБД в частности (что - повторюсь - в любом случае накладывает существенные ограничения). Чтобы иметь хотя бы приблизительные оценки того, каков будет эффект от оптимизации, нужно бы провести тестирование с ее учетом, выполнено же это было - и то в весьма ограниченном объеме из-за искуссственных дополнительных требований - только для ORACLE. Но именно эти результаты и решено было проигнорировать. Однако не будем повторяться...
Построение и поддержка вторичных данных, например, табло наличия свободных мест в поезде по станциям маршрута и категориям мест.
Мы с самого начала доказывали, что ничего плохого в этом нет, и даже реляционной модели это никак не противоречит. В повторном тестировании мы фактически предоставили информацию о том, каков может быть эффект от данной оптимизации в ORACLE. Насчет других СУБД никаких данных нет...
Упрощение процедур поиска и перебора данных.
Звучит заманчиво, но непонятно. Что имеется в виду: упрощение процедуры продажи билетов? За счет чего? Если же речь идет об оптимизации алгоритмов поиска, то тут опять-таки разработчики серьезно ограничены возможностями любой конкретной СУБД, если только они не предполагают реализовать хранение и поддержку базы данных самостоятельно - со всеми вытекающими последствиями. ORACLE - опять-таки в некотором приближении - дала представление о своих возможностях, остальные, скорее всего, нет. Остается непонятным, чем можно руководствоваться в оценках, если ORACLE из рассмотрения исключена.
Построение специализированных индексов для доступа к данным.
Тут вопрос в том, что при этом имеется в виду. Если речь идет о собственной реализации специализированных индексов, то возникнет серьезная проблема их интеграции с используемой СУБД. В принципе на рынке СУБД известны примеры реализации "внешних" индексов (Sybase IQ), но их использование не случайно жестко привязывается к системам, работающим в режиме DSS (что означает редкую, но массированную загрузку данных, а в промежутках выполнение только операций чтения). В режиме же OLTP возникнет весьма сложная (мягко говоря) проблема синхронизации индексов с изменениями в базе данных. Если же речь идет об использовании индесов внутри СУБД, то здесь возможности специализации опять-таки жестко ограничены ее конкретными механизмами - и, соответственно, требуется проверка, насколько эффективно данные возможности в данной конкретной СУБД могут быть использованы.
Существенный (!) выигрыш в производительности дает также использование прямого обращения к средствам СУБД из программ на языках низкого уровня, например на ассемблере.
Когда я вижу такое, то, честно говоря, даже не знаю, как это комментировать. То ли надо начинать объяснять общеизвестные вещи о свойствах режима "клиент-сервер", то ли ...
Впрочем, лучше, наверное, вообще ничего не говорить: по-моему, приведенное утверждение говорит все само за себя.
Применение рассмотренных способов повышения производительности дает качественный скачок (10 - 40-кратное ускорение).
Что производительность можно увеличить, это понятно, но вот откуда цифры взяты? И что же, они никак не зависят от выбора СУБД? Впрочем дальше вроде бы дается пояснение.
Специальные структуры данных повышают производительность в 8-10 раз (от DB/2 к ADABAS постреляционной модели).
Ну, положим, сетевые и реляционные СУБД все-таки работают принципиально по-разному, поэтому такой вывод более чем сомнителен, да и испытания, как уже говорилось, на проселочной дороге проводились ...
Тщательное программирование на языке низкого уровня повышает производительность в 2-5 раз (от ADABAS к ORACLE).
То, что клиентская часть теста была написана на языке C, объясняется исключительно технологическим удобством для целей тестирования (моделирование случайных параметров запросов, моделирование потока запросов без использования разветвленной сети клиентских рабочих станций и т.п.). То, что высокий результат ORACLE достигнут отнюдь не за счет "программирования на языке низкого уровня", авторам статьи прекрасно известно. Два определяющих фактора, влияющих на скорость выполнения интерактивного клиентсткого приложения, работающего с базой данных - это скорость передачи данных по сети (для каждой клиентской рабочей станции в отдельности), и скорость выполнения запросов сервером (для всей совокупности одновременно работающих клиентов). Если используется графический интерфейс пользователя, то приобретает также значение скорость "отрисовки" графики. "Тщательность программирования" (равно как и используемый язык программирования) способны повлиять разве что на последний фактор, да и то тут большую роль играют используемая графическая библиотека и скорость выполнения графических операций аппаратурой. Если клиентское приложение выполняет достаточно сложные вычисления над получаемыми или передаваемыми данными (т.е. в сущности является не совсем OLTP-приложением), то картина может измениться, но в данном конкретном случае это явно не так. Ни эффекты передачи данных по сети, ни графический интерфейс при проведении тестов не моделировались (что совершенно правильно, поскольку это индивидуальные характеристики каждой рабочей станции, практически не влияющие на производительность системы в целом). Получается, что единственный параметр, замеренный при тестировании - это скорость выполнения транзакций сервером БД, которая по понятным причинам не зависит от того, на каком языке написана клиентская часть. Хочу заметить также, что эффект от "микро"-оптимизации, как правило, получается того же масштаба даже на обычных (т.е. не клиент-серверных) задачах, что уже много лет доказывается во всех учебниках по программированию.
В последнем разделе статьи - "выводы" - мне хочется особо обсудить предложения под номерами 2 и 4. В первом из них предлагается загружать часть информации в оперативную память, т.е. фактически организовать еще один программный кэш в дополнение к тому, который и так реализуется СУБД. Хочу заметить, что положительный эффект при этом возможен только в том случае, если разработчикам удастся реализовать поддержку и доступ к такому кэшу эффективнее, чем это делается в самой СУБД (причем намного эффективнее, если учесть появление заметных дополнительных накладных расходов). Корректная же реализация предложенного метода - так же как и в случае с "внешним" индесом - будет сопряжена с решением ряда очень непростых проблем. В конце-концов, если разработчикам удастся эффективно решить такую задачу, то это будет практически эквивалентно созданию специализированной СУБД, так что, скорее всего, и надобность в универсальной СУБД отпадет.
В предложении 4 предлагается использовать "многоядерную" архитектуру СУБД, т.е. загружать на каждый процессор по ядру БД и притом так, чтобы одно ядро модифицировало базу, а другие только читали ее. Мотивировка предложения ("значительный выигрыш при недостатке мощности одного процессора") наводит на подозрение о том, что авторам статьи неизвестен тот факт, что реляционные СУБД (во всяком случае и ORACLE, и DB/2) прекрасно масштабируются в многопроцессорных архитектурах безо всяких уловок со стороны пользователей.
Остальные предложения раздела либо фактически повторяют мысль о возможности оптимизации структур данных (что уже обсуждалось), либо касаются наращивания конфигурации сервера (то бишь мэйнфрейма). Последний путь в принципе правилен, но конкретные пути его осуществления (т.е. определение на каждом шаге того, что именно лучше всего наращивать) должны выбираться исходя не из информации о тех или иных аппаратных возможностях, которые в принципе можно применить, а отталкиваясь от тщательного исследования и определения "узких мест" прикладной системы на имеющейся конфигурации, для чего в каждой СУБД существует (во всяком случае за ORACLE я ручаюсь) хорошо развитая методика.
Наконец, меня совершенно поразило то, что в результате применения всех предлагаемых мер (включая, если я правильно понимаю, наращивание конфигурации) предполагается достичь той производительности системы, которую "отвергнутый" ORACLE и так показал при тестировании!
Собственно этот раздел несколько выпадает из общей темы моих заметок, но мне кажется уместным все же помеcтить его, ибо, как я уже упоминал, при описании СУБД ORACLE для мэйнфреймов авторы статьи допустили ряд существенных неточностей. В принципе я не в претензии к ним за это, ибо среди них нет ни одного специалиста по ORACLE, но я представляю, что у людей, знакомых с ORACLE, приведенная информация может вызвать недоумение, и создать впечатление, будто ORACLE под OS/390 - это совсем другой программный продукт, чем ORACLE под UNIX или Windows NT. В действительности же сервер ORACLE на любой платформе - это один и тот же программный продукт, ибо он получается путем портирования (т.е. разработки только системно-зависимой части, составляющей около 20% всего продукта) одного и того же кода (еще раз подчеркиваю: одного и того же кода, а не одних и тех же спецификаций). В соответствии с особенностями платформы могут быть также добавлены специфичные для нее интерфейсы, утилиты и пр. В точности так же обстоит дело и в случае с мэйнфреймами, хотя здесь, конечно, специфики намного больше, чем, к примеру, при сравнении реализаций под разными UNIX-системами.
При этом ORACLE под OS/390 не имеет "специального компонента" MPM: это просто термин для обозначения подсистемы OS/390, включающей в себя все "рабочие задачи" (эквивалент процессов под UNIX) ядра ORACLE. Другая подсистема, взаимодействующая с MPM, может поддерживать серверную часть SQL*Net. Перечисленные в статье опции сервера, названные "дополнительными возможностями, не входящими в базовую реализацию", на самом деле таковыми - как и на других платформах - не являются (за исключением опции поддержки пространственных данных, которая, видимо, имеется в виду в последнем пункте). Это стандартные возможности, не требующие специального лицензирования, выделение их в опции связано с побуждением предоставить возможность использовать "облегченную" сборку ядра, когда соответствующая функциональность заведомо не нужна.
Наконец, ORACLE Access Manager - это, конечно, никакой не ключевой компонент. Это как раз специфическая для мэйнфреймов дополнительная возможность, нужная только если пользовательские приложения взаимодействуют с сервером ORACLE через CICS или MS/TM (в тесте, естественно, это не использовалось). При этом CICS, конечно - как любой монитор транзакций - может управлять распределенными транзакциями, но это отнюдь не означает, что сервер ORACLE не способен этого делать самостоятельно.
В общем, как говорится, ORACLE - он и на мэйнфрейме ORACLE.
В последнем разделе я в основном уже дискутирую с Е.Зиндером [2]. Соглашаясь со многими его мыслями в целом, я все же испытываю ощущение их неполноты и некоей внутренней противоречивости. Мне кажется, это происходит потому, Е.Зиндер, так же как и авторы статьи [1], не проводит четкой грани между двумя - на мой взгляд принципиально различными - видами тестов, которые я сам называю "формальными"и "функциональными" (или точнее проблемно-ориентированными)10.
Под формальными я понимаю такие тесты, которые предполагают выполнение неких стандартных операций при неких стандартных условиях на заданном наборе данных. И операции и условия при этом задаются не в терминах прикладной задачи, а в терминах самой СУБД. Данные могут в какой-то степени моделировать некую предметную область, но при проведении теста их смысловая нагрузка не играет никакой роли, ибо все операции, проводимые над ними, равно как и методы их выполнения, жестко фиксируются.
Под функциональными я понимаю тесты, ориентированные на исследование характеристик СУБД при решении определенной прикладной задачи. При этом требуется реализовать заданные функции (именно функции, представляющие моделирование наиболее критичных частей прикладной задачи, а не формальные реляционные операции), а исходные данные либо берутся непосредственно из "реальной жизни", либо в максимально возможной степени их моделируют.
Обсудим сначала формальные тесты. Очевидно, они очень полезны для разработчиков СУБД11, а также в какой-то степени для службы технической поддержки этих систем. Что же касается пользователей и разработчиков прикладных систем, то для них - как мне кажется - результаты формальных тестов могут иметь лишь очень ограниченную ценность. Причина заключается в проблеме сопоставления полученных результатов с решаемой задачей. Только в случае, когда есть уверенность в оптимальности тестируемых операций, структур данных и условий в смысле их соответствия прикладной системе12, можно смело полагаться на результаты тестов. В противном случае применение формальных тестов, по моему мнению, может быть оправдано только невозможностью адекватного построения модели прикладной системы на этапе тестирования. Однако в такой ситуации и "вес" результатов тестов при проведении оценок и принятии решений должен быть соответствующим.
Следует иметь в виду, что по результатам формальных тестов далеко не всегда можно даже оценить, скажем, сравнительную производительность различных СУБД при выполнении конкретной операции в приложении. К примеру, если тест показывает, что СУБД A выполняет операцию T на 30% быстрее, чем СУБД B, то это отнюдь не означает, что такое же соотношение сохранится и в приложении P. Вполне вероятен даже такой вариант, при котором СУБД B будет выполнять ту же (в принципе) операцию T существенно быстрее! Это может быть связано с различной оптимизацией выполнения операции в том и в другом случае (как сказал бы математик, с достижением различных условных экстремумов). В качестве практического пояснения данного тезиса приведу такой пример. Высокая "пиковая" производительность порой достигается за счет предельного "облегчения" программного продукта (либо условий его применения). Если - в нашем примере - СУБД A выигрывает за счет этого фактора, то может оказаться, что в приложении P использованная при тестировании A методика вообще неприменима для реализации операции T, тогда как в случае СУБД B тестовая методика продолжает работать (если опять обратиться к математической аналогии, у СУБД A пик экстремума выше, но при этом уже, чем у СУБД B).
Чтобы по возможности избежать подобных эффектов, нужно стремиться при выполнении формальных тестов добиться максимального соотвествия хотя бы условий тестирования условиям реальной задачи. Если это не выполнено, то результат теста может быть совершенно дезориентирующим. Мне приходилось сталкиваться с ситуациями, когда при тестировании использовались условия, "уравнивающие" не только СУБД сравнимого класса, но и вообще практически любые реляционные СУБД (например, зачастую используются однопользовательские тесты в ситуации, когда прикладная система должна быть многопользовательской).
Если перейти теперь к функциональным тестам, то нужно отметить, что они в принципе дают гораздо больше практически полезной информации пользователям, нежели тесты формальные. Основная проблема с ними - это добиться максимального соответствия тестовой модели реальной задаче. В случае, когда этого не удается достичь, результат теста может оказаться даже еще более дезориентирующим, чем в случае формального теста Причина данного эффекта состоит в том, что при функциональном тестировании различные СУБД могут применять принципиально различные - и порой достаточно специфические - методы достижения требуемой функциональности. Соответственно, если допущена ошибка в определении условий тестирования, вполне реально может получиться так, что для достижения оптимального решения в реальной ситуации той или иной СУБД потребуется применение совсем других методов.
Помимо достаточно очевидной проблемы тщательного проектирования самого теста, встает еще и проблема воспроизведения в тесте условий реальной задачи. Не говоря уж о том, что порой технически невозможно (или слишком дорого) обеспечить для тестирования те же ресурсы, которые предполагается использовать в "рабочем" режиме, зачастую встает проблема "курицы и яйца", заключающаяся в том, что тесты как раз для того и проводятся, чтобы оценить потребные ресурсы! Отсюда следует, что может потребоваться проведение экстраполяции полученных результатов на иные (чаще всего большие) значения внешних параметров, что является (как я уже подчеркивал и хочу подчеркнуть еще раз) весьма и весьма нетривиальной задачей. Для ее решения представляется необходимым проведение теоретического анализа технологии и характеристик СУБД, причем анализа весьма тщательного, далеко выходящего за рамки рекламных проспектов и общих рассуждений, обычно базирующихся в значительной степени на тех или иных стереотипах13. Необходимо также исследовать все имеющиеся возможности моделирования, позволяющие в рамках самой СУБД предсказать поведение системы при изменениях внешних параметров14. Безусловно проведение теоретической части исследования является, пожалуй, наиболее сложной задачей, однако без нее ценность тестовых испытаний самих по себе будет достаточно ограниченной. С другой стороны, грамотно проведенный теоретический анализ может позволить упростить модель тестирования, иногда ограничиться испытаниями в облегченных вариантах конфигураций и пр.
Упрощение применяемой при функциональном тестировании модели задачи, как правило, производится за счет ее некоторой формализации, т.е. фактически введения некоторых дополнительных ограничений на виды выполняемых операций, условия их выполнения и пр. Если проведение такого рода упрщений по каким-либо причинам становится неизбежным, нужно быть предельно осторожным, и всякий раз в максимально возможной степени обеспечивать, чтобы вводимые ограничения носили "естественный", т.е. согласующийся с сутью решаемой задачи характер. Более всего следует избегать ограничений, приводящих к невозможности использования оптимизированных структур данных и алгоритмов: во всяком случае тщательное обоснование таких ограничений должно быть обязательным правилом. Связано это с тем, что как раз такого рода оптимизация (я предпочитаю называть ее "макро-оптимизацией" в отличие от "микро-оптимизации", связанной с настройкой параметров системы, применением всякого рода чисто технических ухищрений) дает максимальный эффект15, поэтому ее ограничение может наиболее серьезно исказить результаты тестирования.
Мне кажется, именно отсутствие четкого ответа на данный вопрос служит причиной многих недоразумений и ошибок при планировании, проведении и анализе результатов тестирования. Некий парадокс при этом состоит в том, что, по моим наблюдениям, зачастую планируется не проведение теста как таковое, а как раз его результат. Это ожидание результата, как правило, базируется на наборе стереотипов, иногда на информации о каких-то других тестах (например TPC-C или TPC-D16). Я отнюдь не собираюсь утверждать, что планирование результата - это плохо, как раз наоборот: я считаю, что в определенной степени ожидаемый результат нужно планировать. Вот только планирование это должно основываться на четком понимании того, какие именно характеристики СУБД могут "сыграть", и соответственно как с учетом этого можно будет оценить полученные результаты. Чтобы пояснить свою мысль, я приведу два примера распространенных стереотипов, и постараюсь показать, как они могут повлиять на методику тестирования и на оценку результата.
Стереотип 1. "Все СУБД примерно одинаковы". Наиболее интересным в этом стереотипе мне кажется то, что его можно довольно легко "доказать", соответствующим образом спланировав тест. Более того, принятие данного стереотипа порой как раз и побуждает планировать тест именно таким образом. Кажется парадоксальным, но моя мысль станет ясна, если учесть, что, для достижения требуемого результата, вполне достаточно провести формальный тест в "облегченных" условиях (т.е. без значимой многопользовательской нагрузки, без значительного объема данных в БД, без серьезных тебований к целостности и сохранности данных, к устойчивости работы системы, без использования параллельной архитектуры сервера). Но с другой стороны, а не заманчиво ли не усложнять свою задачу дополнительными "наворотами", если все равно результат вроде как примерно ясен? Почему бы не попробовать сначала "по-простому", а дальше уже разбираться, если выяснится, что кто-то окажется сильно лучше? Беда в том, что не окажется, а если и окажется, то не факт, что это будет лучшая СУБД для реальной задачи, а не для теста. В реализации интерпретации языка SQL уже давно ни для кого нет особых секретов, а архитектурные, алгоритмические (и где-то даже идеологические) различия СУБД в "облегченных" условиях всерьез не скажутся.
Стереотип 2. "Преимущество будет иметь СУБД, лучше интегрированная с ОС". Я думаю, вряд ли кто-то в здравом уме станет отрицать тот факт, что интеграция СУБД с ОС имеет большое значение. Но и преувеличивать практическое значение данного фактора отнюдь не стоит. Чтобы доказать такую точку зрения, предлагаю от абстрактного восприятия сформулированного тезиса перейти к более конкретному, и попробовать понять, в чем же именно может проявиться разница в степени интеграции СУБД с ОС. Самым неприятным фактором могла бы явится плохая общеархитектурная совместимость данных программных продуктов. Однако после некоторых размышлений несложно прийти к выводу, что во всяком случае для комбинации серьезных (что называется brand name) СУБД и ОС это крайне маловероятно: в конце-концов при всем разнообразии конкретных решений все многопользовательские ОС строятся по более или менее общим принципам, конечно же хорошо известным разработчикам ведущих СУБД. Более реальным фактором могли бы быть специфические технические детали взаимодействия с ОС, которые в состоянии заметно повлиять на производительность программного продукта. Однако помимо того, что производители ОС и производители крупных СУБД, как правило, тесно контактируют при реализации "стыковки" своих продуктов, для данного аспекта серьезным ограничивающим фактором является особенность рынка труда программистов (и, кстати, не только программистов) в США (а именно в этой стране производятся все ведущие СУБД). Особенность эта состоит в исключительной подвижности рядовых программистов в плане выбора и смены места работы. Эта подвижность неизбежно приводит к тому, что все технологические идеи и приемы, ориентированные на использование именно рядовыми программистами (а все особенности интерфейсов с ОС относятся к такому классу) неизбежно быстро становятся общим достоянием. Во всяком случае можно с большой уверенностью утверждать, что реализацию модулей, ответственных за поддержку интерфейса с ОС в ведущих фирмах-производителях СУБД осуществляют специалисты примерно равной квалификации17.
Реальным "ноу-хау" производителей СУБД могут считаться по той же причине только архитектурные и алгоритмические решения достаточно высокого уровня, соответственно - как мне кажется - именно эти аспекты прежде всего могут реально продемонстрировать разницу между рассматриваемыми СУБД. В соответствии с этим, именно от использования функциональных возможностей СУБД, а также от степени оптимальности ее архитектурных решений для рассматриваемой прикладной задачи можно ожидать наиболее значимых результатов в проведении тестов - если конечно тесты позволяют все эти аспекты реализовать!
В известном смысле ожидание именно таких результатов как раз и побуждает планировать тесты таким образом, чтобы дать возможность продемонстрировать возможности каждой СУБД не вообще, а при решении конкретной прикладной задачи (или, вернее, наиболее критичных ее компонентов).
Конечно же, оценка полученных в результате такого (очевидно, в максимально возможной степени функционального) тестирования должна быть осторожной. Важно убедиться, что в условиях тестирования не допущено ни одного принципиального пробела (это достаточно нетривиальный аспект, ибо воспроизвести реальные условия на 100%, как правило, невозможно), способного повлиять на методику проведения теста той или иной СУБД. Наверняка нужно ознакомиться с применяемой методкой и оценить границы ее применимости. Однако ни в коем случае не следует, как мне кажется, подменять эту исследовательскую работу введением искусственных ограничений, "нивелирующих" тестируемые СУБД.
Именно неготовность к адекватному восприятию "функциональных", а не "формальных" результатов тестирования (что как мне кажется, проистекает из того, что при формулировании вроде бы функциональных условий теста, подспудно подразумевается тем не менее некое формальное его решение) приводит к "проблемам сопоставимости" типа той, что описана в статье [1]. Желание "аннулировать" результат, выбивающийся из априорных представлений о том, каким он должен быть, вместо того, чтобы признать ошибочность априорной модели и попытаться вывести на требуемый уровень все остальные результаты, является, по-видимому, достаточно естественной психологической реакцией, но вряд ли может считаться правильным решением.
Прошу прощения за заголовок, но я воспроизвожу в слегка модифицированном виде заглавие раздела из статьи Е.Зиндера [2], с которым собираюсь подискутировать. Собственно - как я уже отмечал - со многими положениями статьи я согласен, например с тем, что "интересы проекта требуют сравнивать характеристики СУБД для БД и транзакций, специфичных именно для этого проекта": я тоже, как нетрудно заметить, отстаиваю необходимость проведения функциональных, а не формальных тестов. Я однако совершенно не согласен с мнением Е.Зиндера, что авторами статьи [1] "производился контроль сопоставимости тестов с проектными требованиями к системе". Как я уже пытался доказать, они, как раз наоборот, свели все к чисто формальному выполнению неких действий, не позволяющих получить результаты, сопоставимые с реальными проектными требованиями, что, в свою очередь, привело к достаточно сомнительным оценкам и выводам относительно перспектив решения прикладной задачи.
Мне представляются противоречащими исходному положению (упомянутому выше) все рассуждения насчет "не предусмотренной оптимизации размещения БД", ибо само по себе это ограничение уже достаточно, чтобы перевести тестирование в разряд формальных, а стало быть, мало отражающих "специфику проекта".
Я полностью согласен, что "выбор СУБД для проекта основывается не только на оценке временных и функциональных характеристик" и "что учитывается множество других факторов". Плохо только, если появляется желание "подогнать" результаты тестирования под решение, принятое на основе этих самых факторов.
Я полностью согласен с тем, что "необходимо подобрать команды тестировщиков, обладающие высшим мастерством во владении средствами каждой СУБД". Я даже готов переформулировать это утверждение "от противного": использование при тестировании специалистов, не знающих средств тестируемых СУБД, или не владеющих этими средствами, практически бесполезно с точки зрения полученных результатов. От себя хотел бы добавить, что если оказывается затруднительным или невозможным найти требуемого уровня специалистов по какой-либо СУБД, то это должно быть одним из "других факторов", влияющих на решение.
Трудно спорить с утверждением, что вводимые при тестировании ограничения должны быть связаны "с принятием проектных решений не для тестов, а для проектируемой системы". Непонятно только, почему, вроде бы иллюстрируя данное утвеждение, автор пишет про "определения ограничений на выбор логической схемы БД", "определения параметров физической схемы БД"? Неужели он полагает, что такого рода ограничения могут быть "связаны с принятием проектных решений для проектируемой системы"? Мне представляется, что они направлены как раз в прямо противоположную сторону.
Согласен я также с тем, что "ответственность за принятие ограничений высока", и что "разработка ограничений должна учитывать рекомендации экспертов по конкретным СУБД". Вопрос опять-таки в том, на что должны быть направлены как рекомендации, так и ограничения. Если на "нивелирование" возможностей СУБД, то тест едва ли можно будет считать полезным с практической точки зрения, если же на экспертную оценку свойств, специфических методов и алгоритмов СУБД с последующей тестовой проверкой их характеристик и границ применимости в условиях конкретной практической задачи - то это действительно не только полезно, но и необходимо.
Я считаю очень полезным, если "тестировщики могут натолкнуть разработчиков системы на новые идеи в части проектных решений этой системы", вот только я очень сомневаюсь, что подобный эффект имел место в проекте, описанном в статье [1], как это утверждает Е.Зиндер, ибо решение программировать систему на ассемблере - это совсем не то, что, на мой взгляд, можно было бы назвать "новой идеей", адекватной технологии, продемонстрированной тестировщиками.
В заключение я, как и обещал, постараюсь сформулировать принципы, которые стараюсь отстаивать и проводить в жизнь при проведении тестирования СУБД.
Прежде всего, я исхожу из того, что сведение тестирования к соревнованию СУБД в скорости записи/чтения с диска или интерпретации SQL бессмысленно с практической точки зрения. Напротив, я полагаю, что главным результатом теста должна явиться демонстрация архитектурных и функциональных возможностей СУБД применительно к решаемой задаче. Отсюда вытекает мое стремление рассматривать любой тест в максимальной степени как функциональный, а не как формальный.
Поскольку при формулировке условий теста не всегда в полной мере учитываются требования реального приложения, то следующим принципом, на мой взгляд, должно быть неформальное отношение к этим условиям. Это означает максимально возможный учет специфики и требований самой прикладной задачи при выборе методов выполнения теста. Если при анализе результатов тестирования появляются вопросы относительно применимости реализованной методики в реальных условиях, я считаю допустимым повторение теста с дополнительными требованиями, но при этом полагаю справедливым настаивать на том, чтобы:
1. указанные дополнительные требования вытекали из существа решаемой прикладной задачи, а не из желания любым способом "нивелировать" результаты тестирования,
2. эти требования предъявлялись (или по крайней мере проверялись) в равной степени по отношению ко всем участникам тестирования.
Я считаю некорректным использование в тестах каких бы то ни было недокументированных и/или нестандартных возможностей СУБД. Я считаю допустимым использование исключительно "рабочих" (поставляемых пользователям) версий программных продуктов, если только противная возможность не оговорена в условиях проведения теста18.
Наконец, я всегда стараюсь убедить заказчиков теста в необходимости теоретического анализа архитектурных и функциональных особенностей тестируемых СУБД. Я считаю, что без такого исследования очень сложно правильно сформулировать цель и условия тестирования, равно как и адекватно проанализировать полученные результаты.
Я ни в коем случае не хотел бы, чтобы мои заметки воспринимались как претензия на единственно истинную трактовку вопроса о тестировании СУБД. Это всего лишь изложение одной из возможных точек зрения. Еще больше я не хотел бы, чтобы оценка моей статьи вылилась в рассуждения о том "кто прав, а кто виноват". Нам всем еще достаточно долго предстоит адаптирваться к представлению о том, что правы могут быть разные люди, даже если их точки зрения сильно различаются. Я думаю, что дискуссия по вопросу о тестировании СУБД вполне уместна, хотя к ней следует подходить очень осторожно. Я имею при этом в виду тот факт, что тестирование порой используется при принятии решений в тендерах с выбором СУБД, поэтому они напрямую затрагивают коммерческие интересы различных фирм. Любая иформация о деталях проведения тестов и их результатах по данной причине должна быть максимально корректной и не допускающей двусмысленных толкований. К сожалению, мне кажется, что данный принцип в статье [1] не был соблюден.
Ну и наконец - теперь уж действительно наконец - я еще раз хочу повторить, что все, изложенное в данной статье, отражает мою собственную точку зрения, которая совсем не обязательно совпадает по тому или иному вопросу с официальной точкой зрения корпорации ORACLE.
1 Отмечу сразу, что сама по себе эта схема далеко не оптимальна для реляционной СУБД (дабы не перенасыщать статью техничекими деталями, я не буду приводить более оптимальные варианты с пояснениями, почему они таковы), но поскольку она была зафиксирована в начальных условиях, команда ORACLE старалась выдержать предложенную логику схемы данных.
2 Я еще раз хочу подчеркнуть, что все это делается в рамках предложенной логики схемы данных. При принятии более оптимальной схемы возможно еще более изящное кластерное решение организации данных.
3 Для интересующихся теоретическими аспектами использования хэш-таблиц (включая математические оценки сложности алгоримов) не могу отказать себе в удовольствии сослаться на сильно устаревшую по форме, но не стареющую по содержанию монографию Д.Кнута [3].
4 Я опять-таки рекомендую обратиться к монографии [3], где приводится подробный математический анализ поведения хэш-таблиц с различными параметрами.
5 В шутливом определении "Реляционная СУБД - это система программного кэширования дисков, понимающая по стечению обстоятельств язык SQL", есть немалая доля истины.
6 Я намерен подробнее обсудить данный аспект в заключительном разделе статьи
7 Не следует забывать о том, что точки сериализации могут возникать как на уровне СУБД, так и на уровне самого приложения.
8 Отсутствие скачкообразных изменений каких-либо параметров системы при изменении внешних параметров является одной из самых важных характеристик по-настоящему масштабируемой промышленной СУБД.
9 Иллюстрацией является, например, упоминание о том, что "в качестве структур хранения DB/2 использует VSAM-наборы данных". Если авторы считают нужным упомянуть об этом в отношении DB/2, то непонятно, почему они не говорят о том, что ORACLE тоже хранит свои данные в VSAM-наборах и использует для доступа к ним те же средства низкоуровневого ввода/вывода, что и DB/2 (я не исключаю, что и ADABAS поступает так же)? Дает ли в таком случае приводимая характеристика хоть какую-то информацию в отношении сравнения СУБД?
10 Если кому-либо известна другая терминология, я буду весьма благодарен за информацию о ней
11 И они выполняют тысячи таких тестов ежедневно. В ORACLE даже разработана специальная система автоматизации проведения тестов и контроля их результатов. Часть этих тестов просто контролируют соответствие функциональности СУБД ее спецификациям с учетом всех последних изменений, внесенных разработчиками, другие же тесты предназначены для контроля влияния внесенных изменений на те или иные параметры СУБД (например, производительность при выполнении определенных операций), исследование полученных функциональных зависимостей между параметрами СУБД и внешними параметрами (изменение ресурсов, нагрузки, объемов данных и т.п.). Тесты последнего типа часто называют "регрессионными".
12 А также в тех случаях, когда по какой-то причине методика решения задачи заранее ограничивается предлагаемой в тестах реализацией. Если это так, то главный вопрос в том, насколько оправданы подобные ограничения. Даже в наиболее "естественном" из известных мне случаев - требовании портируемости прикладной системы по отношению к разным СУБД - все же гораздо более оптимальным (хотя и более трудоемким) представляется другой подход: создание проблемно-ориентированного интерфейса прикладной системы с СУБД с последующей оптимальной его реализацией для каждой СУБД в отдельности.
13 Одним из аспектов, на который обязательно нужно обратить внимание - это (как я уже упоминал) обеспечение отсутствия скачкообразных измениний характеристик системы при соответствующем изменении нагрузки или ресурсов. Ясно, что если такого рода "скачки" возможны, то говорить о сколько-нибудь надежной экстраполяции не приходится, а также существует опасность достижения пределов применимости СУБД (разработчики иногда называют это "эффектом стены"). Данный вопрос тем более важен, что зачастую методика, обеспечивающая "плавную деградацию" (или соответственно лучшую масштабируемость) требует более сложных архитектурно-алгоритмических решений, так что в результате при небольших нагрузках (небольших ресурсах) соответствующие СУБД могут показать даже несколько худшие результаты, нежели их - в принципе более слабые - конкуренты.
14 Например в ORACLE существует возможность "заставить" саму СУБД собрать в ходе тестирования или даже реальной эксплуатации необходимую статистику, позволяющую оценить эффект от изменения размера буфера в оперативной памяти, используемого для работы с данными БД. Результат, правда, получается не в терминах скоростных характеристик, а в измерении основного параметра, характеризующего эффективность кэширования, т.е. (число физических операций обмена)/(число логических операций обмена)
15 В руководстве по настройке сервера ORACLE утверждается, что 80% эффекта настройки достигается за счет оптимизации приложения, и только 20% - за счет всего остального. Хотя я и не берусь утверждать, что приведенные цифры верны всегда и при всех обстоятельствах, они тем не менее на мой взгляд дают адекватное представление о соотношении эффективности "макро"- и "микро"-оптимизации.
16 Кстати, TPC-тесты являются чисто формальными по своей природе со всеми вытекающими из этого факта последствиями.
17 А в некоторых случаях, возможно, и вовсе одни и те же люди.
18 Использование бета-версий может считаться допустимым, если речь идет о перспективном проекте, и фирма-поставщик может представить информацию, гарантирующую выход продукта в рабочий режим к требуемому для пользователей сроку.
|
|