Тестирование СУБД с использованием tpc-ds и методы сравнительного анализа

Когда мы начали искать альтернативы Greenplum, у руководителя уже был явный фаворит StarRocks. Но мне было непонятно, как доказать, что он действительно лучше других кандидатов, а не просто производит хорошее первое впечатление.

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

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

Мне достались критерии вроде безопасности, зрелости и совместимости. И почти сразу возник вопрос, что означает оценка безопасности, например семь из десяти. Почему семь, а не шесть или восемь? Можно долго спорить о балле, но от этого балл не становится менее субъективным.

В этой статье не будет рейтинга конкретных продуктов. Я хочу показать путь от бенчмарков и спорных экспертных оценок до расчёта, где видно происхождение каждого числа. Реальные наблюдения отделены от учебного примера. Кандидаты A, B и C и их значения синтетические. Они нужны только для объяснения расчёта.

Почему мне не понравились экспертные оценки

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

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

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

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

Я решил, что надо искать не ещё одну шкалу, а сам способ работать с такими оценками. Так нашёл метод комплексной оценки из учебного пособия П. А. Гудкова. Сначала пришлось буквально учиться читать формулы. Что в них подставлять, как не перепутать значения, как проверить результат. После первых двух формул стало заметно легче.

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

В итоге у меня осталось два слоя сравнения:

• измерения на стенде;

• экспертные и функциональные критерии, разложенные на наблюдаемые признаки.

Ни один слой сам по себе не даёт ответа. Скорость без совместимости и эксплуатации мало полезна. Экспертное мнение без проверяемой основы ещё менее надёжно.

Что мы проверяли на стенде

Основным бенчмарком был TPC-DS. Он задаёт схему данных, генератор с коэффициентом масштаба SF и набор сложных аналитических запросов. Мы начинали с небольших наборов, отлаживали загрузку и запросы, затем увеличивали объём.

Нас интересовало не только полное время прогона. Для каждого кандидата было важно понять:

• какие запросы он вообще выполняет;

• где образуется тяжёлый хвост;

• что происходит при параллельном запуске;

• сколько места занимают данные;

• как на результат влияют ограничения CPU, памяти и настройки;

• можно ли затем воспроизвести полученный результат.

SSB использовали как дополнительную компактную нагрузку со звёздной схемой. TPC-H рассматривали как близкий ориентир, но не смешивали его результаты с основным прогоном. Стандартные наборы дают общий язык для разговора о производительности, но они не знают особенностей конкретной системы и её критичных запросов.

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

Результат без описания стенда почти бесполезен

Время выполнения запроса само по себе ни о чём не говорит. Нужно знать, на чём и как его получили.

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

Для параллельной нагрузки можно посчитать пропускную способность:

Здесь N_OK — число успешно выполненных запросов, t — длительность прогона. Например, 294 / 460 = 0,639 запроса в секунду. Сравнивать такие значения можно только при одинаковом числе потоков и одинаковых ограничениях ресурсов.

Что запомнилось по кандидатам

StarRocks был самым простым стартом. Настройки понятны, для бенчмарков есть готовые скрипты, почти всё работало сразу. Эти скрипты я потом взял за основу и для других СУБД, у которых столь готового контура не было.

С YDB ситуация была другой. На момент работы Яндекс ещё не выпустил YDB как решение для аналитической нагрузки с колоночным хранением. Тем интереснее были результаты. При этом ограничении система показывала себя хорошо, хотя и не проходила все 99 запросов. Отдельно понравилась утилита, через которую можно настраивать систему и выполнять SQL-запросы, не собирая вокруг неё отдельный набор разрозненных инструментов.

TiDB запомнилась простотой установки и количеством готовых компонентов. После развёртывания уже есть панель управления, средства наблюдения, Grafana, Prometheus и другие полезные вещи. Плюс TiDB в том, что это гибридная система, в которой сочетаются OLTP и OLAP. Минус вытекает из того же устройства. Данные хранятся и построчно, и поколоночно, а значит есть цена дублирования.

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

Как я раскладывал экспертные критерии

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

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

Есть и более жёсткое правило. Обязательное свойство не должно компенсироваться скоростью. Если без конкретной SQL-возможности невозможна миграция, кандидата лучше исключить до подсчёта итогового балла. Формула не может сделать подходящей систему, которая не решает обязательную задачу.

Как свести разные виды оценок

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

Шкала не является математической истиной. Это экспертное решение. Его нужно определить до того, как станет известно, кто победил в рейтинге.

Если экспертов несколько, оценки лучше собирать независимо и по одной шкале. Простейший вариант это среднее.

Здесь q_ije — оценка кандидата j по критерию i, поставленная экспертом e, а m — число экспертов.

Если компетенции участников различаются и это можно объяснить, используется взвешенное среднее:

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

Учебный расчёт от исходной таблицы до ранга

Дальше будут синтетические данные. Кандидаты A, B и C не соответствуют StarRocks, YDB, TiDB или другим реальным продуктам. Пример показывает ход расчёта.

Исходная таблица

Этап 1. Нормализация

Для критерия, где меньше — лучше, берём отношение лучшего ненулевого значения к значению кандидата. Для времени кандидата A:

Для объёма на диске кандидата B:

Качественные значения переводятся по заранее заданной шкале.

Если исходные значения одинаковы, критерий не различает кандидатов. Его нужно исключить из расчёта или заранее назначить всем одну оценку.

Этап 2. Веса важности

Пусть средние экспертные оценки важности восьми критериев равны 9,5, 8,5, 9, 8, 7, 6,5, 6, 8,5. Их сумма равна 63.

Нормализованный экспертный вес:

Для времени TPC-DS:

Полный набор весов такой. 0,151, 0,135, 0,143, 0,127, 0,111, 0,103, 0,095, 0,135.

Этап 3. Вес по различию кандидатов

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

Сначала считаем среднее:

Для времени:

Затем относительный разброс:

Для времени R₁ = 0,036. Для восьми критериев получаем:

0,036, 0,085, 0,667, 0,222, 0,083, 0,417, 0,667, 0,510.

Их сумма по неокруглённым значениям равна 2,687. Нормализуем разбросы:

Получаются такие веса. 0,013, 0,032, 0,248, 0,083, 0,031, 0,155, 0,248, 0,190.

SQL-возможность и аудит сильнее других различают A, B и C, поэтому их вес по разбросу выше.

Этап 4. Общий вес критерия

Экспертную важность и различающую способность в этом примере объединяем простым средним:

Это не единственно правильное правило. Если экспертные веса надёжны, можно взять только V. Если экспертов нет, можно использовать только Z. Здесь среднее показывает один из возможных способов соединить два источника информации.

Сумма общих весов равна 1 с учётом неокруглённых значений.

Этап 5. Вклад каждого критерия

Нормализованную оценку умножаем на вес:

Например, вклад времени в оценку A:

Этап 6. Итог и граница метода

Складываем вклады кандидата:

Для A:

0,902 × 0,082 + 0,786 × 0,083 + 1 × 0,196 + 1 × 0,105 + 0,7 × 0,071 + 1 × 0,129 + 1 × 0,172 + 0,5 × 0,162 = 0,872.

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

A стала первой не потому, что формула решила. У неё полная SQL-поддержка, надёжность, документация и аудит. B быстрее и удобнее в администрировании, но теряет баллы из-за аудита и частичной SQL-поддержки. C лучше по диску и зрелости эксплуатации, но в этом учебном примере не поддерживает обязательную SQL-возможность.

И тут видно главное ограничение. Если SQL-возможность действительно обязательна, C следовало исключить ещё до расчёта. Интегральный балл не отменяет стоп-требования.

Что дала методика лично мне

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

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

Для меня в этом и была польза. Не притворяться, что один человек знает все особенности каждой СУБД. А превратить разнородные наблюдения в модель, которую можно проверить, обсудить и пересчитать при изменении требований.

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

Где легко ошибиться

У метода есть слабые места.

Полное время выполнения и пропускная способность могут описывать один эффект. Если включить оба показателя без отдельного обоснования, скорость незаметно получит двойной вес.

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

Наконец, формула не исправит плохо заданную шкалу. Если хорошо, удовлетворительно и плохо не имеют наблюдаемых признаков, расчёт всего лишь превратит расплывчатое мнение в дробное число.

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

Послесловие

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

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

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

Материалы

• TPC-DS

• TPC-H

• Star Schema Benchmark

• Актуальные спецификации TPC

• Гудков П. А. Методы сравнительного анализа / под ред. А. М. Бершадского. Пенза: Изд-во Пензенского государственного университета, 2008. Текст учебного пособия.