|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #01-02/98
|
|
В #4 СУБД за 1997 год мы поместили статью группы авторов (М. Березка, А. Комиссаров и др.) об опыте сравнения СУБД общего назначения в интересах развития системы "Экспресс". Уникальность этого проекта и сложность проблем сравнения СУБД побудили меня сопроводить статью комментарием, описывающим некоторые важные аспекты, не освещенные в статье. В #5-6 СУБД появились два материала - Г.М.Ладыженского и В.В.Сиколенко - с откликами, имеющими неожиданную ориентацию претензий к журналу и авторам.
Так же, как и авторы самой статьи, сначала я посчитал непродуктивным реагировать на эти претензии. Непродуктивным по той причине, что читателям достаточно внимательно прочитать статью, комментарий к ней и указанные претензии, аккуратно сравнить помещенные в них факты и суждения чтобы оценить как технические проблемы, так и качество претензий. Однако, высказанные Г.М.Ладыженским и В.В.Сиколенко - далее, для краткости, "критиками" - суждения затронули также аспекты, которые относятся к этике авторской и издательской деятельности. В сочетании с рядом определенно ошибочных суждений критиков по поводу методических и технических проблем эти суждения составили опасную, на мой взгляд, смесь, действительно способную ввести в заблуждение как читателей, так и авторов будущих статей. Это и заставило написать данную заметку.
Я считаю, что на первом месте для журнала должны быть интересы читателей при естественной защите прав авторов. Если эти условия выполняются, то и о защите "интересов наших бизнес-партнеров и коллег", о которой заботятся критики (здесь и далее в кавычках приводятся цитаты из текстов критиков) специально беспокоиться не надо, поскольку и с их интересами в этом случае должно быть все в порядке. Интересы бизнеса в этом случае могут оказаться нарушеными только в случае недобросовестного в чем-то ведения этого бизнеса (конечно, я не имею ввиду случаи разглашения коммерческой тайны и другие очевидные нарушения норм, а рассматриваю только вопросы, поднятые критиками). Кстати, уж бизнес-то обладает гораздо большими возможностями, чем читатели и авторы, чтобы защитить свои интересы.
По моему мнению, в нашем случае претензии критиков содержали: а) необоснованные принижающие оценки опубликованной работы, б) неоправданные оценки недопустимости публикации в журнале статей по подобным вопросам вообще, в) дезориентирующие читателей оценки, сводящиеся к положению, что они могут получить вред от чтения опубликованной статьи. Именно из-за этого и в соответствии с описанным выше пониманием приоритетов показалось оправданым, даже необходимым защитить интересы читателей и авторов и написать, почему публикация статьи была в интересах читателей и в чем правы ее авторы.
Статья описывает вполне конкретный сравнительный анализ и его результаты. Выражение критиков "в статье нет сравнительного анализа СУБД как такового" наверное предполагает, что сравнительным может быть только исчерпывающий анализ. В этом одна из основных ошибок критики. Анализ может быть сравнительным и адекватным поставленным перед ним целям, но в сложных системах (будь то технических, биологических или юридических) он практически никогда не является полностью исчерпывающим. Это - элементарные азы экспертирования, так что претензии критиков по данному поводу безосновательны и лишь вводят читателей в заблуждение.
Как всякий реальный эксперимент, описанный опыт проведен в конкретных, следовательно - ограниченых условиях. Опубликованные результаты соответствуют этим условиям, а читатели получили о них сведения в объеме, достаточном для интерпретации результатов. Если при интерпретации у читателей возникли вопросы (что вполне допустимо), то авторы были открыты для их обсуждения. (Кстати, критики не высказали претензий к соответствию результатов опытов их условиям.) Мы посчитали, что в интересах читателей - получить опубликованные оценки. Особенно важным это представляется потому, что - при общем большом интересе к производительности СУБД - в нашей практике экспертизам производительности уделяется мало внимания, и цифры для сколько-нибудь реалистичных условий чаще всего неизвестны.
Теперь о методике анализа. Ее безусловная ограниченость состояла, в первую очередь, в том, что не удалось абсолютно адекватно сбалансировать две группы условий. Первая: обязательные ограничения на допустимые возможности выбора способов реализации тестов; вторая: возможности и способы работы разных команд по реализации тестов.
Две причины этого отмечены выше в заметке авторов статьи:
Теперь читатели могут видеть, что авторы вольно или невольно создали в статье лучшее сравнительное впечатление о той СУБД, "защитниками" которой являются критики, и вот по какой простой логике. При планировании последовательности экспертиз для разработчиков системы "Экспресс" вполне оправдан мог бы быть следующий вопрос: поскольку для одной СУБД оказался произведен "второй подход к штанге" для исправления тестовых баз данных и программ, и этой СУБД удалось остаться на уровне хороших (лучших!) числовых показателей, может быть стоит затратить деньги на "второй подход" и для остальных СУБД? Ведь вполне может быть, что, поработав дополнительно, показатели для других СУБД можно улучшить во много раз! Ирония ситуации состоит в том, что критики должны были бы благодарить авторов за публикацию оценок. Теперь же, с учетом изложенных обстоятельств, сравнительное преимущество защищаемых критиками оценок должно снизиться.
Отметим еще раз, что эксперимент авторов не проходил в рамках тендера. Говорить, что такие экспертизы обязательно предполагают хоть какой-то уровень закрытости информации - значит также вводить читателей в заблуждение. В терминах экспертирования это определяется очень четко, и это может быть рассмотрено отдельно и с нужным уровнем подробности. Таким образом, ирония ситуации состоит и в том, что критики предложили закрыть для публикации результаты, лучше которых - в сравнительном, конечно, аспекте - их СУБД, может быть уже и не сможет получить!
Далее. Вполне понятная ограниченность методов этой экспертизы была причиной появления моего комментария, который показывает, какие проблемы, кроме рассмотренных в статье, надо учитывать и какие методы применять для того, чтобы снижать ограничения на область применимости результатов экспертиз. Дело в том, что пользоваться описанными в статье результатами вполне можно, если хорошо представлять себе эти ограничения. Но можно ставить перед экспертизой другие вопросы и расширять область примененимости результатов. Если помнить, что эта область всегда ограничена, то понятна необоснованость всех тех претензий критиков к статье и ее публикации, которые связаны с ложной опасностью использования материалов статьи читателями. Конечно же, статья ценна не только описанием реалий большого проекта, но и полученными результатами и подходом, но при условии ясного учета ограничений. И конечно, для помощи в оценке области применимости результатов тестов я должен рекомендовать читателям внимательно отнестись к упомянутому комментарию.
Критики написали, что со многим из сказанного мною в комментарии они согласны, но многое вызывает у них "ощущение неполноты и некоей внутренней противоречивости". Хочу предложить заинтересованным читателям самим внимательно сравнить пять страниц текста, следующего у критиков за этой цитатой, с положениями комментария, а также и отдельные утверждения этого текста между собой и составить экспертное заключение о качестве критики. Должен предупредить, что придется весьма скрупулезно сопоставлять фразы разных фрагментов текстов. Причина в том, что выбранный критиками литературный стиль основан, в том числе, на многочисленном и необычно эмоциональном использовании не только ошибочных, но и вполне истинных суждений. Таким образом, надо избежать иллюзий восприятия более эмоциональных суждений как более справедливых.
Здесь для примера приведу только два положения комментария, которые оказались непонятны, как они пишут, критикам.
Критикам непонятно, почему ограничения на выбор логической схемы БД и определение параметров ее физической схемы вообще могут быть связаны с принятием решений для проектируемой системы, а не для самих тестов. Критика утверждает, что такие ограничения могут быть направлены "как раз в противоположную сторону". Поясню справедливость комментария простейшими примерами.
Представьте, что бюджетные соображения не дают возможности купить для сервера БД более трех дисководов. Это значит, что при планировании теста надо ограничиться размещением данных не более, чем на трех (может быть - только на двух или даже на одном) устройствах, хотя распределение, скажем, на четыре или шесть устройств потенциально могло бы улучшить временные характеристики. А вот другая, реже встречающаяся, но также вполне реальная ситуация. Можно, к примеру, существенно повысить производительность, если включить в один физический кластер таблицы А и Б (то, о чем много пишут критики, но что используется в развитых СУБД уже около тридцати лет и часто называется хранением одних объектов "вблизи" других). Однако, другие требования (например, безопасности) могут требовать обязательного хранения этих таблиц на разных устройствах, расположенных в разных помещениях.
Что касается ограничений на выбор логической схемы БД, то они могут определяться соображениями независимости структуры БД от особенностей разных, в том числе, еще неизвестных сегодня прикладных программ и соответствующих режимов обработки данных. Либо могут диктоваться уровнем обобщенности модели предметной области, выбранным еще во время проектирования концептуальной модели БД по особым, может быть, стратегически важным соображениям. Существует много других возможных причин, но не их изложение есть цель данной заметки.
Как видно, эти примеры не связаны напрямую с проектом "Экспресс-3", но и сам комментарий связан не с ним, а с правильностью и универсальностью методического подхода как такового, о чем, как они сообщают, заботятся и критики. А для этого проекта хочу отметить два положения. Во-первых, авторы статьи при планировании тестов определили ограничения на структуру БД, которые существенны в этом проекте, и без согласования с ними менять эти ограничения недопустимо (то, что ограничения были нарушены, критики подтверждают). Во-вторых, моделируемая в тестах подсистема не есть просто система OLTP, как ее называют критики, это - система реального времени. Как известно, для систем такого класса часто оправданы совершенно особые архитектурные решения, в том числе - отказ от СУБД общего назначения. И авторы статьи, в отличие от критиков, это учитывают (хотя и стремятся использовать стандартные средства везде, где возможно).
Надо сказать, что и упомянутые выше, и другие ошибочные суждения наших критиков могли бы и не возникнуть, если бы они в своей профессиональной деятельности в большей степени специализировались на проведении экспертиз в соответствии с базовыми, но строгими методами экспертирования вообще как вида деятельности, в том числе - экспертирования сложных технических систем, а в частности - экспертирования СУБД и баз данных. Откликаясь на предложение С.Д.Кузнецова и на основе сделанных в мае и июне с.г. докладах, я попытаюсь включить в свой рабочий план написание статьи по этим аспектам экспертирования. Надеюсь, там можно будет рассмотреть собственно методические аспекты, включая и другие положения из тех, что вызвали у критиков трудности и, как следствие, неудовлетворительные ощущения.
Отметим, что большая часть претензий наших критиков могла бы быть снята в ходе их простого устного обсуждения. Тем более, что у обоих критиков дорога от их офиса в ORACLE СНГ до моего офиса в дни написания ими своих текстов занимала не более пяти минут. А действительно содержательное обсуждение в печати могло бы состояться по другим, весьма актуальным и сложным вопросам обеспечения таких качеств характеристик СУБД как их соотносимость и предсказательная сила. Тогда потраченое время - в том числе, ушедшее на написание этой заметки - могло бы принести всем существенно большую пользу.
О стиле критиков. Он, безусловно, очень ярок, но, с учетом сказанного выше ясно, что им лучше было бы выбрать более спокойный, более предположительный стиль. В связи с этим хочу напомнить один часто забываемый факт: в нормальной маркетинговой терминологии т.н. агрессивная маркетинговая политика в первую очередь базируется на существенном снижении цены на свои товары (услуги), затем на этой базе может строиться и агрессивная, то есть наступательная реклама. Но эмоциональные "наезды" (это - не цитата) суть явление из другой области. "Религиозные войны", против которых предостерегают критики, конечно же недопустимы, но, на мой взгляд, именно стиль их претензий и может подталкивать к таким конфликтам.
Куда как лучше было бы, если бы критики, основываясь на действительно полученых и, как они считают, выйгрышных для них численных характеристиках производительности (конечно не на 1-2 порядка, как пишут критики, если даже учитывать и их исправленный тест), предложили бы статью, в которой спокойно проанализировали бы все причины столь разительных различий в показателях, привели данные по совокупному отношению производительность/стоимость своих предложений на протяжении, скажем, десятилетнего цикла развития "Экспресс-3", высказали бы другие конструктивные соображения. И сделали бы это вне зависимости от по-человечески понятных эмоций, возбужденных тем, что они и защищаемая ими СУБД не оказались выбранными в проект.
Журнал не может и не должен публиковать только учебные статьи или статьи-справки о новых версиях программных продуктов, то есть то, благодаря чему он может быть пособием для студентов. Объективное, открыто описаное сравнение СУБД, инструментов, методик и проектов всегда представляет большой интерес. Если оно описано полно и открыто в достаточной степени, то в интересах всех сторон - читателей, фирм-разработчиков, авторов - иметь его результаты, если, конечно, их закрытость не предусматривалась. Открытость и полнота описания служат хорошей почвой для читательского анализа, для улучшения методик, для исправления ошибок в проведенном сравнении (если они были), для улучшения самих программных продуктов. Этот процесс также в интересах всех сторон. Но пусть этот процесс проходит спокойно, уважительно и конструктивно. И мне хотелось бы призвать все стороны именно к такому стилю общения.
Одно замечание критиков надо безусловно принять: в названии статьи сохранились слова про выбор СУБД, тогда как собственно про этот выбор в самой статье нет ни слова! То, что получилось с названием - обычный просмотр и авторов и редакторов. Примите наши извинения. Но, поскольку в статье про выбор ничего не говорится, все претензии критиков по тому поводу, что авторы делают вывод "о выборе СУБД, показавшей наихудшую скорость", выглядят как минимум странно. Если же выбор был сделан, то это было уже за рамками статьи (и вся эта сторона дела в данном обсуждении не существенна), причем этот выбор учитывал много других аспектов помимо производительности. Учет этих аспектов - также тема для другой публикации.
Однако, ошибка в названии не должна затмевать суть дела. В связи с этим надо напомнить критикам известные им оценки GartnerGroup, в соответствии с которыми по жизненно важным для таких проектов, как "Экспресс-3", показателям на первом месте стоит как раз та СУБД, которая, в итоге, и была выбрана для проекта - я специально во всей этой заметке избегаю названий СУБД, здесь не они для нас - самое главное. (Кстати, оценки GartnerGroup также не являются исчерпывающими, а свой выбор разработчики "Экспресс-3" имеют полное право уточнять и даже менять.)
В заключение еще раз поблагодарим группу авторов статьи за то, что они поделились с нами опытом своей работы и полученными оценками.
Евгений Захарович Зиндер, редсовет журнала СУБД, E-mail: ez@osp.ru.|
|