(Возврат на основную страницу)
Дональд Берлсон (Donald Burleson)
Несмотря на потоки рекламных материалов, извергаемые ведущими поставщиками платформ БД — Microsoft, Oracle, Sybase и Informix, менеджеры часто ощущают недостаток объективных результатов тестирования реляционных СУБД (РСУБД).
Каждый производитель приводит результаты тестов, «подтверждающие», что его БД — самая быстрая. Естественно, каждый производитель выберет тот тест, который позволит представить его продукцию в самом выгодном свете. Чтобы внести хоть какое-то единообразие в тестирование БД, был создан совет Tran-saction Processing Performance Council (http://www.tpc.org/tpcc/default.asp), или TPC.
TPC осознает, что разные приложения обрабатывают данные по-разному. Поэтому для оценки производительности OLTP разработан тест TPC-C (http://www.tpc.org/information/benchmarks.asp), для хранилищ данных и систем поддержки принятия решений — TPC-R (http://www.tpc.org/tpcr) и TPC-H (http://www.tpc.org/tpch) (прежде TPC-DS), а для систем на основе Web — TPC-W (http://www.tpc.org/tpcw). Тест TPC-C считается стандартом de facto для определения производительности оперативной обработки транзакций (OLTP) главным образом потому, что он воспроизводит обработку OLTP в реальных БД.
Несмотря на все усилия…
Но, несмотря на все потуги TPC, производители БД продолжают подтасовывать результаты тестов. Основная проблема здесь в различиях между аппаратными платформами, на которых работали СУБД. Например, СУБД UDB от IBM (бывшая DB2) работает лишь на мэйнфрейме IBM 3090, а БД Informix — только под управлением UNIX. Из-за огромных различий между архитектурой машин, на которых работают эти БД, очень трудно сравнивать результаты их тестов. (Видимо, автор давно не заходил на страницу с результатами испытаний. Обратившись по адресу http://www.tpc.org/tpcc/results/tpcc_results.asp?orderby=dbms, можно убедиться, что IBM DB2 UDB 7.1 еще в 2001 году работала под управлением Microsoft Windows 2000 Advanced Server. Что же касается Informix, то последние результаты по стандарту TPC-C были получены довольно давно, но версия Informix OnLine Workgroup Server 7.30 работала под управлением Microsoft Windows NT 4.0, также как и Informix Dynamic Server 9.30 работает под управлением Windows NT и 2000 (см. http://www-3.ibm.com/software/data/informix/ids/requirements.html). — прим. ред.)
Как производители подтасовывают результаты тестов
Пытаясь «доказать», что их БД превосходит конкурентов, производители пускаются во все тяжкие, чтобы увеличить скорость выполнения тестов. Почти все их хитрости связаны с кэшированием данных и текста запросов в RAM.
Как известно, скорость работы БД во многом определяется скоростью дискового ввода/вывода. Поэтому производители заранее загружают в большие области RAM критические компоненты тестовых заданий, чтобы СУБД вовсе не обращалась к диску. Вот некоторые хитрости производителей:
Подобные хитрости позволяют любому производителю БД сделать так, чтобы его продукт смотрелся лучше, чем у конкурентов. Поэтому чаще всего следует смотреть на результаты тестирования БД со здравым скепсисом.
Как сравнивать скорость БД
Сравнительное тестирование БД — очень сложная задача для менеджера, ответственного за сравнение производительности БД. Хотя было бы неверно говорить, что тесты БД вовсе не дают никакой информации, с их помощью очень трудно «доказать», что одна БД работает быстрее другой. Чтобы представить себе всю сложность сравнения производительности БД при помощи тестов, достаточно взглянуть на публикацию совета TPC (http://www.tpc.org/tpcc/results/tpcc_results.asp?orderby=dbms) с результатами тестов TPC-C для различных аппаратных платформ и СУБД.
Как выбирать СУБД
Как не ошибиться при выборе СУБД, если вокруг столько противоречивой и откровенно запутывающей информации? Конечно, производительность — лишь один из многих критериев при выборе БД. Кроме нее нужно учесть наличие обученных администраторов, технической поддержки производителя и совокупную стоимость владения.
Большинство СУБД так или иначе способны обрабатывать сотни транзакций в секунду. Отталкиваясь от этого, можно сказать о производительности БД следующее.
В заключение можно отметить, что объективная оценка производительности СУБД — дело непростое. Сметливый менеджер должен тщательно и придирчиво оценить, что предлагают ему производители БД, чтобы отделить реальность от рекламной шелухи.
Фабиан Паскаль (Fabian Pascal)
Знакомым с моими публикациями известно, что в последние годы я постоянно жалуюсь на недостаток и практики фундаментальных знаний, и хороших практических приемов в отрасли БД, эта статья не исключение…
«В системах поддержки принятия решений (СППР) традиционная нормализованная схема никогда не догонит по производительности денормализованную схему типа «звезда», призванную обеспечивать скорость анализа, а не обычной обработки транзакций, модифицирующих отдельные записи… Модель, исходно разработанная для обработки таких транзакций, испытывает чрезвычайные [!] нагрузки, когда ей приходится исполнять [СППР-]запросы.»
— практик с 20-летним стажем
«Многие считают, что третья нормальная форма обеспечивает наиболее эффективную работу БД… Однако чрезмерная [!] нормализация БД повышает вероятность излишних соединений таблиц. Поэтому здесь вполне уместно отступить от теоретических правил ради повышения производительности БД в реальном мире.»
— http://www.sqlteam.com/Forums
«Денормализацию можно описать как процесс снижения степени нормализации с целью повышения производительности обработки запросов… мы представляем денормализацию с практической точки зрения и приводим ее фундаментальные правила… денормализация способна поднять производительность запросов, если применяется с четким представлением о прикладных требованиях.»
— Сэндерс, Шин; Государственный университет штата Нью-Йорк, Баффало
Я привел несколько цитат, иллюстрирующих всеобщую тенденцию к злоупотреблению таким аспектом кон-струирования БД, как нормализация. При этом чаще всего используют следующую линию доказательств:
Слабость этой аргументации в том, что пункты 2 и 3 вообще всегда неверны, а если так, то пункт 4 тоже теряет силу. Более того, даже если все эти утверждения окажутся верными, обоснованность применения денормализации все равно остается под большим вопросом, поскольку за повышение производи- тельности БД (если его удастся получить таким способом) неизбежно придется расплачиваться ее целостностью.
Статья призвана разъяснить, почему идея «повышения производительности за счет денормализации» — это опасное заблуждение, чреватое затратой сил и средств, о чем не догадываются практики. Ущерб целостности БД, сопровождающий денормализацию, сведет «на нет» любое повышение производи- тельности, если его вообще удастся получить.
Information Discovery, Inc.
Эта статья представляет собой первую попытку связать OLAP и разработку данных (data mining).
В этой статье компания Information Discovery, Inc. доказывает, что разработка одномерных данных является лишь грубой аппроксимацией анализа многомерных данных и демонстрирует необходимость проведения анализа как подробных, так и суммированных данных. В этой статье представлен материал выступления на Data Mining Summit в 1997 году, в том же году эта статья стала победителем в номинации «The Best of Database Programming and Design». Внедрение технологий, разработанных Information Discovery, Inc., позволяет объединить мощные аналитические возможности OLAP и разработки данных, гарантируя получение максимально точных и подробных результатов. Information Discovery, Inc. — лидирующий поставщик решений и ПО для систем СППР, ориентированных на разработку очень больших объемов данных. Компания предлагает новаторскую технологию PatternWarehouse, использующую анализ зависимостей, и два комплексных пакета. Пакет Data Mining Suite позволяет находить универсальные и разнообразные зависимости, напрямую работая с очень большими многотабличными хранилищами SQL. Пакет Knowledge Access Suite сохраняет зависимости, выявляемые в ходе предварительной обработки, в хранилище Pattern Warehouse, обеспечивая доступ к ним для решения прикладных задач. Компания также предлагает широкий спектр решений для обнаружения и разработки информации, стратегического консалтинга и разработки архитектуры хранилищ данных, а также специализированные решения для банков, финансовых операций, различных видов розничной торговли, промышленного производства и анализа журналов Web-приложений.
Введение
Оперативная аналитическая обработка (OLAP) и разработка данных — неотъемлемые части любого процесса принятия решений. Действительно, большинство современных систем OLAP ориентированы на предоставление «доступа» к многомерным данным, в то время как системы для разработки данных имеют дело в основном с «анализом влияний» на основе одномерных данных. В этой статье показано, что OLAP и разработку данных не следует разделять в процессе принятия решений, поскольку по своей сути они являются связанными и взаимодополняющими операциями (к тому же отчаянно нуждающимися друг в друге).
В статье New Realms of Analysis описан унифицированный набор принципов работы с реляционными БД, OLAP и системами анализа влияний, основанный на четырех пространствах поддержки принятия решений (ППР). Концепцию разработки данных в OLAP (OLAP DataMining) можно представить в терминах этих пространств, организованных в простую таблицу (см. табл. 1).
Табл. 1
|
Пространство |
Пространство подробных данных |
Пространство агрегированных данных |
|
Доступ/просмотр |
Ядро SQL |
Системы OLAP/ROLAP |
|
Анализ/обнаружение |
Ядро DataMining |
OLAP DataMining |
Обращаясь к OLAP, пользователь задает вопрос, например «найти объем сбыта в каждом штате по месяцам», а система дает ответ. Однако самой по себе OLAP не достаточно, поскольку она дает лишь грубую статическую картину или «моментальные снимки» информации, «зарытой» в массиве данных. Чтобы выявить зависимости для значительных массивов данных, существующие в пространстве OLAP, например влияние месяца и штата на размер прибыли, требуется разработка данных по различным измерениям.
Здесь приведен очерк унифицированного подхода к OLAP и разработке данных, который должен показать, что приложения для ППР должны учитывать результаты разработки данных по различным измерениям, а системы OLAP — ориентироваться на выявление информации не меньше, чем на доступ к ней. Действительно, как утверждает излагаемая здесь теория, во избежание неверных результатов OLAP и разработка данных должны работать «в одной упряжке».
Эндрю Заневски (Andrew Zanevsky)
В статье обсуждается реализация пользовательских функций в SQL Server 2000. Автор поделится с вами исходным текстом некоторых из них.
Пару месяцев назад я предсказывал, что написание пользовательских функций для SQL Server 2000 станет таким же «спортом» или развлечением, каким сегодня является написание хранимых процедур. Итак, перед вами первый плод моего труда на этом поприще, предоставляющем все возможности для самореализации. Пользовательские функции позволяют применять многочисленные новые методики программирования и имеют так много практических приложений, что я никак не мог выбрать, с каких функций начать. Участвуя в программе Vendor Advocacy Program (она проводится сообществом профессионалов SQL Server — PASS (www.sqlpass.org) и призвана собрать предложения об улучшении программных продуктов), я обнаружил, что некоторые из предложенных улучшений можно реализовать в виде пользовательских функций. Итак, пока мы ждем, когда Microsoft воплотит пожелания пользователей, собранные через программу PASS, почему бы мне не сыграть роль джинна?
Анджей Козловски (Andrzej Kozlowski)
Мне, как и другим администраторам, в чьем ведении находится много БД SQL Server, массу проблем причиняют задачи по обслуживанию и администрированию.
Некоторые задачи приходится создавать и постоянно выполнять в каждой БД, чтобы обеспечить устойчивость и надежность. В этом мне помогает один инструмент, которым я часто пользуюсь, — мастер Database Maintenance Wizard, он служит для создания планов обслуживания SQL Server.
Хотя мастер Database Maintenance создает в общем неплохие планы, все же часто они бывают далеки от совершенства. К тому же вовсе не очевидно, что происходит «за кулисами» при исполнении плана обслуживания, и недавно я решил выяснить это при помощи SQL Server Profiler.
Для записи профиля трассировки (в SQL Server 2000) я воспользовался предопределенным шаблоном SQLProfilerStandard с двумя изменениями. Я только заменил
RPC: Completed
SQL: BatchCompleted
на
RPC: Starting
SQL: BatchStarting
оставив другие элементы конфигурации профиля без изменений. Эти модификации шаблона SQLProfilerStandard позволят легко собрать интересующие нас данные трассировки.
(Возврат на основную страницу)