О сравнительном анализе СУБД

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

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

Так, насколько я понял из статьи, в выполненных тестах СУБД Oracle показала наивысшую производительность, на 1-2 порядка превосходящую производительность двух других систем. При этом по транзакции "Т2" была достигнута скорость 200 транзакций в секунду, что весьма близко к требуемой скорости в 250 транзакций в секунду. Рассуждая с позиций здравого смысла, следовало бы продолжить работу с системой, показавшей наивысшую производительность. Однако авторы статьи делают весьма странный вывод о выборе СУБД, показавшей наихудшую скорость на обоих тестах. Что это за странное тестирование? И таких вопросов очень много, просто нет возможности их обсуждать в рамках данной реплики.

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

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

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

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

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