Обоснованный выбор или обоснование выбора?

"Компьютерные журналы очень осторожно подходят к публикации статей о тестировании". (Глеб Ладыженский, СУБД, # 5-6, 1997 год).

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

Надо ли говорить, что в таких группах работают люди, что придает дополнительный вес пресловутому "субъективному фактору". Следуя этой логике, в результатах любого тестирования можно усмотреть субъективный подход.

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

С другой стороны, существует целый ряд достаточно очевидных аспектов выбора, в большинстве своем - нетехнического характера. При всей их очевидности "вес" многих характеристик может оказаться даже значительно больше, нежели "вес" результатов тестирования.

Именно поэтому содержание данной статьи, возможно, кому-то покажется очевидным. В ней не содержится никаких конкретных примеров, своим "видом" могущих дать пищу для подозрений в субъективизме. По той же причине здесь отсутствуют ссылки на продукты каких бы то ни было компаний, или на их опыт по внедрению.

Стандартные тесты

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

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

Модель тестирования

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

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

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

В том случае, если модель тестирования создается не для подтверждения выбора, а для его осуществления, должно соблюдаться два требования: во-первых, модель должна максимально соответствовать реальной задаче - как бы та ни была понята, - во-вторых, условия проведения тестирования должны быть максимально приближены к "боевым". Выполнить эти требования чрезвычайно сложно, в результате многие начинают относиться к тестированию скептически - дескать, чтобы понять, годится ли СУБД, нужно ее купить.

Характеристики СУБД как критерии выбора

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

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

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

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

Кроме того, внедрение автоматизации в новые области бизнеса уже поставило задачу поддержки объектно-ориентированного подхода. Производители пытаются обогнать друг друга в реализации объектно-ориентированных возможностей, и наличие той или иной функции может оказаться решающим для оказания кому-либо предпочтения.

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

Крупная база данных планируется не на один год, причем время будет отражаться не только на увеличении объема данных. Меняется и структура информации, меняется бизнес-логика, меняются требования к интерфейсу. Видимо, это крайне трудно учесть при тестировании, которое само по себе производится на основании "урезанного варианта" данных.

Важным критерием выбора с точки зрения перспектив на будущее становится наличие эффективных средств разработки. Такие средства, обладающие удобным интерфейсом, позволят специалистам предприятия самостоятельно и быстро настраивать информационные системы в соответствии с требованиями бизнеса. Для баз данных, которые становятся основой информационных систем сервисных компаний или электронной торговли, наличие подобных средств особенно важно.

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

Выбрать сразу, исправить потом?

Даже очень тщательно проведенное тестирование не может гарантировать, что выбран наилучший продукт. Любая внедренная система все равно требует доводки, а доводка может повысить производительность не в один раз. Доводка выполняется специалистами производителя, знающими тончайшие струны своего инструмента и способными обеспечить возможности, которые трудно было предусмотреть при тестировании. Ее можно проводить по четырем направлениям: на уровне схемы, что может выражаться в ее переработке или оптимизации индексов; на уровне приложений (например, оптимизировать запросы); на уровне сервера, что предполагает использование возможностей операционной системы, распределение нагрузки в случае использования кластерной конфигурации, а также использования специальных утилит; а также на уровне аппаратуры, подразумевающей добавление процессоров или памяти, либо введение тиражирования и распределения нагрузки. Здесь важно то, что все эти операции производятся на реальной базе и на реальных данных в отличие от упрощенной модели в случае тестирования.

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

Разговор о земном в храме науки

Возможно, затронуть в очередной раз непростую и щекотливую тему выбора СУБД нас побудил семинар Московской секции ACM SIGMOD, состоявшийся в МГУ 14 мая. Несмотря на "причастность" к двум столь солидным организациям, семинар оказался чужд академической скуке. Организаторы пригласили независимых специалистов и представителей разработчиков, которые, хотя и придерживались сходных взглядов по основным вопросам, вступали порой в оживленную полемику.

В начале семинара выступил Владимир Пржиялковский (ВЦ РАН) с коротким и очень полемичным сообщением, которое строилось, по существу, на основе мини-опроса компаний - пользователей СУБД. Опрос этот, хотя его ни в коем случае нельзя назвать репрезентативным, дал весьма интересные результаты. Из общего числа респондентов 16 компаний работали с Oracle, 5 - с FoxPro, 4 - с Access, 3 - с Clipper и 1 - c Informix. Пожалуй, наиболее показательно здесь не значительное превосходство Oracle, и не столь же разительное отставание Informix, а присутствие довольно значительной прослойки поклонников продуктов, которые практически сходят на нет. Предпочтения этих компаний заслуживают самого пристального анализа, тем более что они явно окажутся среди потенциальных заказчиков тестирования новых продуктов. Пржиялковский также задал нескольким респондентам (в числе которых оказались представители иностранных компаний), ведущим разработчикам и администраторам - и вопрос о причинах выбора СУБД. Большинство "наших" на первый план выдвигали технические характеристики, производительность, наличие хороших средств разработки, а вот для иностранных специалистов гораздо важнее оказались переносимость, гибкость.

Лейтмотивом выступления Евгения Зиндера (LVS/Price Waterhouse) стала необходимость адекватного соответствия экспертиз, проводимых при проектировании системы, реальным условиям задачи и требованиям заказчика. Чем ответственнее задача, тем больше проводится экспертиз, охватывающих экономические, технические и другие показатели; необходимо отдавать себе отчет в корректности результатов каждой. Чтобы прогнозировать поведение сложных систем, необходимо всестороннее рассмотрение, то есть оценка архитектуры проекта, анализ задействованных данных, а также программных и аппаратных ресурсов, как требуемые, так и уже имеющиеся. Кроме того, необходимо оценить СУБД, четко различая виды оценок. Последние можно подразделить на две группы: паспортные оценки, характеризующие продукт в некоторых стандартизированных условиях безотносительно проекту, - и оценки, ориентированные на проект. Для тех и других можно предложить элементарные и интегральные характеристики. В 80-е годы была развита методика получения элементарных характеристик. Опираясь на них, по некоторой известной зависимости вычислялись показатели, которые служили основанием для заключения о выборе той или иной системы. В современных условиях этот подход уже "не работает".

Сложности, связанные с тестированием, объясняют и известное предубеждение, касающееся тестирования продуктов независимыми экспертами (в особенности если принять во внимание стоимость этих услуг). Возникает вопрос - не проще ли купить систему, да и дело с концом?

На семинар были приглашены представители крупнейших производителей CУБД. Oracle представлял руководитель группы серверных технологий Виталий Сиколенко, Informix - консультант по проектам Андрей Грачев, Software AG - директор по маркетингу Ольга Китова.

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

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

Как устроены стандартные тесты

Тестовый комплекс TPC Benchmark C был одобрен Transaction Processing Performance Council (TPC) в июле 1992 года. Он предназначен для испытания систем оперативной обработки транзакций (OLTP). Комплекс TPC-C предполагает выполнение пяти одновременных транзакций различных типов либо в оперативном режиме, либо в отложенном, при этом транзакции организуются в очередь. База данных содержит записи пяти типов. Результат TPC-C измеряется в транзакциях в минуту (tpm).

TPC-C моделирует полную вычислительную среду, обрабатывающую транзакции клиент - база данных. В качестве основной операции выбрана типовая обработка заказа (New-Order), которая предполагает ввод и доставку заказа. Кроме того, вносятся записи об оплате, выполняется мониторинг состояния заказа и контролируется степень заполнения склада (Payment, Order-Status, Delivery, Stock-Level). Хотя этот тест более всего соответствует деятельности оптового поставщика, результаты тестирования характерны для любого сегмента бизнеса, в котором выполняется управление, продажи и распределение продуктов и услуг.

Число, обозначающее производительность по TPC-C, определяет количество транзакций типа New-Order, которые система обрабатывает одновременно с четырьмя транзакциями других типов (Payment, Order-Status, Delivery, Stock-Level). Каждая из этих транзакций имеет определенные требования по времени отклика, при этом время отклика для New-Order установлено в 5 секунд. Таким образом, показатель, к примеру, 710 tpmC означает, что система обрабатывает в минуту 710 транзакций типа New-Order.

Показатель цена/поизводительность по TPC-C определяется как частное от деления общей стоимости владения и производительности. То есть, если общая стоимость системы составляет, к примеру, 859 100 долл., а производительность - 1562 tpmC, то значение цена/производительность составит 550 долл. за tpmC.

Первый тестовый комплекс TPC Benchmark D был одобрен TPC в апреле 1995 года. Он предназначен для испытания широкого спектра систем поддержки принятия решений, требующих обработки сложных запросов к сложным структурам данных. Для этой модели было разработано 17 запросов, отражающих реальные бизнес-ситуации.

TPC-D моделирует среду принятия решений, в которой к большой базе данных направляются сложные "горячие" запросы. Для обработки запросов могут быть задействованы большие фрагменты базы, а также одна или несколько следующих операций: объединение нескольких реляционных таблиц; сложная сортировка; группировка и агрегирование; последовательное сканирование.

TPC-D позволяет установить, соответствуют ли параметры конкретной системы показателям цены и производительности, требуемым для определенного типа приложенией. Модель TPC-D допускает масштабирование, что позволяет тестировать базу именно такого объема, который соответствует данной задаче.

В то время как OLTP-приложения предполагают интенсивное обновление базы и более короткие транзакции, которые обращаются к меньшим участкам базы, приложения поддержки принятия решений требуют выполнения сложных запросов - часто в режиме "только чтение", - которые обращаются к большим участкам базы. Базы данных таких систем обновляются нечасто и не содержат данных реального времени.

Схема базы данных, применяемой для тестирования по TPC-D, состоит из восьми таблиц плюс необязательная девятая таблица TIME. Такая схема характерна для базы данных компании-дистрибьютора, ведущего торговлю в разных странах мира и приобретающего продукты у многочисленных производителей. Две самые крупные таблицы Order и Lineitem по объему составляют 85% базы. Другие таблицы содержат сведения о партнерах, поставщиках и покупателях. Все таблицы, за исключением двух небольших - Nation и Region, - допускают линейное масштабирование в зависимости от объема базы данных.

Тестовые запросы разрабатывались на основании предложений всех членов подкомитета TPC-D. Отбирались запросы, отражающие возможные бизнес-ситуации и реализованные в стандартном SQL. В результате анализа всех предложений был выработан комплекс из 17 определений Functional Query Definitions. Стандарт ANSI SQL оказался выбран в качестве наиболее широко принятой производителями спецификации, гарантирующей понятность языка и функций SQL-запроса. Полная версия SQL-92 была выработана как эталонная версия ANSI SQL.

Определения Functional Query Definition в деталях определяют функцию (функции), которые должны быть выполнены по тому или иному запросу. Это шаблоны, основанные на формальном синтаксисе Structured Query Language (SQL). Для преобразования Functional Query Definition (FQD) в запрос в синтаксисе SQL на основании ограничений, определенных в разделе Substitution Parameters каждого определения, производится подстановка допустимого значения для каждого параметра FQD.

Результат теста (QthD) может считаться классическим показателем производительности, характеризующим способность системы сбалансированно поддерживать многопользовательскую нагрузку. Для тестирования выбирается число пользователей (S), каждый из которых выполняет 17 запросов в различном порядке. В фоновом режиме происходит обновление, состоящее из последовательно выполняемых операций вставки и удаления (одна пара для каждого пользователя). Выбор числа пользователей зависит от потребностей организации, проводящей тестирование.

Результат тестирования вычисляется как общий объем работы (S*17) в секундах, соотнесенный с объемом базы и поделенный на общее время работы, начиная с момента обработки первого запроса и кончая завершением последнего запроса или функции обновления.

Аналитики бросают производителям новый вызов

Четверо аналитиков представили на суд производителей баз данных новый набор контрольных задач.

"Набор тестов TPC-D является полностью открытым, - пояснил президент компании Information Paradigm Франсуа Рааб. - Вы можете опубликовать результаты в любое время. Это как легкая атлетика. Очередной мировой рекорд может быть побит в тот же день. Но при этом остается открытым другой вопрос: если улучшение производительности представляет собой непрерывный процесс, то когда же следует выпускать очередную версию тестовых примеров?"

Рааб, а также президент корпорации Winter Ричард Уинтер, один из руководителей компании Strategic Technologies and Systems Стивен Бробст и президент ирландской компании Data Warehouse Network Син Келли организовали мероприятие Data Warehouse Challenge. Производители получили 30 дней на подготовку, а затем началось тестирование, которое должно было показать, чья концепция на сегодняшний день лучше. Все происходившее было очень похоже на олимпийские старты.

Компании подготовили свои продукты для стандартных испытаний. Тесты TPC-D проводились на 100- и 300-гигабайтной базах данных. После того как тестирование началось, авторы проекта предложили ряд новых запросов, "слегка модифицировав" алгоритм TPC-D.

Другое отличие тестов Data Warehouse Challenge (www.datachallenge.com) заключалось в том, что испытания проводились в многопользовательской среде и, что самое главное, разработчики баз данных заранее не имели представления о том, какие задания им предстоит выполнить.

В результате вызов приняли только две компании - IBM и NCR. Жан-Франсуа Горю был расстроен тем, что корпорация Oracle не участвовала в испытаниях: "Я рассчитывал на это и надеялся, что руководителей Oracle удастся уговорить. Но поскольку этого не случилось, многие, судя по всему, не станут доверять новым тестам".

Тестирование баз данных: от любви до ненависти

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

Менеджер корпорации Oracle Джим Энрайт, курирующий вопросы быстродействия, свое отношение к испытаниям, предложенным Советом по обработке транзакций (Transaction Processing Council, TPC), выразил следующим образом: "Я не стал бы утверждать, что мы в восторге от этого, но наша компания с уважением относится к любым методам тестирования и сравнения различных продуктов, даже если эти методы искусственные".

Питер Толи, директор компании Sybase, отвечающий за разработку перспективных архитектур, солидарен с ним: "Контрольные примеры TPC очень важны с маркетинговой точки зрения. Однако сегодняшние клиенты стали гораздо грамотнее и прекрасно понимают, что стандартные испытания не могут дать полной картины того, насколько тестируемый продукт подходит для реализации конкретного проекта".

В прессе звучат самые противоречивые высказывания о процедуре тестирования, и все же производители оборудования и баз данных ежегодно тратят на проведение испытаний огромные суммы.

Два наиболее распространенных набора контрольных тестов, TPC-C и TPC-D, специально предназначены для анализа оперативной обработки транзакций и оценки качества среды, влияющей на процесс принятия решений. Представительница организации, называемой Советом по обработке транзакций, Ким Шенли заметила, что, хотя тесты TPC-C и TPC-D регулярно подвергались пересмотру, настало время внести в них принципиальные изменения.

"Нужно имитировать более серьезную загрузку, - подчеркнула Шенли. - Мы со своей стороны стараемся увеличить число операций ввода/вывода, добавляем новые таблицы и типы транзакций".

Вскоре Совет представит новую контрольную задачу для Web - TPC-W. Несмотря на заверения Шенли о том, что обновление стандартных тестов будет способствовать прогрессу, многие настроены скептически и не жалуют ни сам Совет TPC, ни его тестовые наборы.

"Вряд ли можно оздоровить сложившуюся ситуацию, - признался президент аналитической и консультационной фирмы Alternative Technologies Дэвид Макговерен. - Я не вижу повода для оптимизма. Разработчики баз данных ничего не выиграют от того, что тесты станут более специфичными. Контрольные задачи используются ими исключительно в маркетинговых целях.

Для того чтобы тесты отражали реальное положение дел, необходимо поднять плату, взимаемую за тестирование. Это сразу уменьшит количество хвастливых заявлений, а также критических выпадов в адрес других компаний".

Надо сказать, что даже в среде производителей преобладают скептические настроения. Одной из причин можно назвать сложность поиска варианта, который устроил бы сразу 45 компаний. К примеру, на ратификацию TPC-C потребовалось четыре года. Кроме того, контрольные задачи очень быстро начинают отставать от непрерывно растущих компьютерных мощностей, а результаты тестирования в большей степени зависят от конкретных аппаратных средств, чем непосредственно от баз данных.

"Давать объективные оценки сейчас стало значительно сложнее, поскольку существенное значение имеет платформа, выбранная для испытаний: количество процессоров, наличие и организация дисковых массивов. Фактически для каждой конкретной машины нужно проводить отдельные испытания".

Директор канадского отделения компании NCR Жан-Франсуа Горю согласен с тем, что результаты испытаний необходимо анализировать, отталкиваясь не от полученных цифр, а от того, что стоит за ними: "Клиентов, как правило, не интересует "устройство" контрольных задач. Им гораздо важнее понять, что же в итоге сделали производители и каким образом можно сравнить между собой различные продукты".

В частности, при тестировании терабайтной базы данных непосредственно данные могут занимать не более 50 Гбайт. Все остальное пространство отводится под таблицы предварительной выборки, объединения и схемы связей между элементами базы данных.

Спецификации TPC-D содержат всего 17 тестовых примеров, и все они прекрасно известны специалистам по базам данных.

Президент компании Winter Ричард Уинтер отметил, что, помимо уже известных, имеется и множество других недоработок: "Результаты выборки TPC-D распределяются одинаково. К примеру, если запрос производится по 50 штатам, каждая колонка имеет одно и то же представление. На самом же деле число жителей Нью-Йорка значительно превышает аналогичные показатели штата Монтана. Отсутствие учета пропорций в тестах TPC-D улучшает показатели баз данных, поскольку не проверяется качество управления процентной выборкой".

Предполагается, что при повторном выполнении тестов TPC будут получены те же результаты, однако Макговерен выражает сомнение в их правильности.

"Где гарантия, что при очередном тестировании будут выполняться те же самые программы, а данные на диске будут размещаться точно так же, как в прошлый раз? Полностью воспроизвести все нюансы практически невозможно".

Можно выполнять тесты TPC повторно и включать в отчет не все результаты. Для этого производителям необходимо настроить свою систему и официально обратиться с просьбой провести тестирование для выбранной конфигурации.

Специалисты критикуют тесты, моделирующие однопользовательские запросы к базе данных, - подобный сценарий в реальной жизни встречается редко.

Однако, несмотря на все недостатки, ведущий консультант компании Price Waterhouse по хранилищам данных Джим Стоун уверен, что потребность в тестировании все равно существует, просто его необходимость следует рассматривать применительно к конкретным условиям. Пользователю необходимо знать, какие наилучшие результаты можно получить с помощью того или иного приложения в данном контексте.