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

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

Проблема быстро перестала быть вопросом «какой запрос выполнился быстрее». Одна система хорошо показывала себя в нагрузочных испытаниях, другая проще разворачивалась, третья лучше вписывалась в существующие инструменты. Часть характеристик измерялась секундами и гигабайтами, часть — ответами «да/нет» или экспертными баллами.

В статье покажу весь путь: как мы сформулировали задачу, почему выбрали TPC-DS и SSB, какие ещё инструменты изучали, как составляли экспертные критерии и как свели разнородные результаты через метод комплексной оценки П. А. Гудкова. Главная цель — не назвать универсального победителя, а дать повторяемый способ сравнения, который читатель сможет применить к своим СУБД и своим требованиям.

Исходная задача: найти OLAP-СУБД для больших данных

Мы рассматривали современные распределённые и аналитические решения как возможную альтернативу Greenplum. Поле кандидатов включало отечественные, международные и открытые продукты. В исходных материалах исследования отдельно зафиксированы результаты и наблюдения по StarRocks, YDB и TiDB; Arenadata, Postgres Pro и Citus рассматривались в общем поле доступных альтернатив.

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

• выполнять сложные соединения, агрегации и подзапросы;

• сохранять приемлемое время на растущем объёме данных;

• эффективно использовать диск и вычислительные ресурсы;

• работать при параллельной нагрузке;

• быть понятным в развёртывании, наблюдении и сопровождении;

• поддерживать нужные SQL-возможности и интеграции.

Так появились два независимых слоя оценки:

1. нагрузочные испытания — то, что можно измерить на стенде;

2. экспертная оценка — функциональные, эксплуатационные и технологические свойства.

Только вместе они отвечают на практический вопрос: подходит ли СУБД для нашей задачи.

Почему TPC-DS стал основным инструментом

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

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

TPC-DS давал нам несколько полезных результатов:

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

• сколько занимает полный последовательный прогон;

• какие запросы образуют тяжёлый хвост;

• как система ведёт себя при параллельном запуске;

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

• как настройки и ограничения ресурсов влияют на результат.

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

Что ещё мы изучали

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

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

Как проводить нагрузочное испытание

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

Для каждого запроса полезно сохранять отдельную строку журнала:

Из журнала можно получить долю успешных запросов, суммарное время, медиану, p95/p99 и потребление ресурсов. Ошибка или тайм-аут не должны исчезать из аккуратного среднего.

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

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

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

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

Как мы выбирали критерии экспертной оценки

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

Например, вместо абстрактной оценки «безопасность хорошая» критерий можно разложить на пять проверок: ролевая модель, внешняя аутентификация, шифрование соединения, аудит действий и управление секретами. Если каждая подтверждённая возможность даёт один балл, исходная оценка уже опирается не на общее впечатление, а на проверяемый перечень.

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

При формировании критериев мы придерживались следующего порядка:

1. Зафиксировать назначение будущей системы и ограничения проекта.

2. Отделить обязательные требования: кандидат, который их не выполняет, не должен компенсировать это скоростью.

3. Разложить общие свойства на проверяемые подкритерии.

4. Убрать дублирование, чтобы одно преимущество не учитывалось несколько раз.

5. Заранее определить шкалу и направление оценки.

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

• секунды, минуты, гигабайты и стоимость;

• ответы «да / нет»;

• словесные оценки «отлично / хорошо / удовлетворительно / плохо»;

• упорядоченные состояния «полностью / частично / с ограничениями / отсутствует»;

• баллы 1–5, 1–10 или другой заранее определённой шкалы.

Числа от 0 до 1 появляются только после содержательного перевода исходных значений. Эксперт может сказать «поддерживается частично» или «документация хорошая» — важно заранее определить, что означает каждый вариант и как он будет нормализован.

Примеры содержательных шкал

Два варианта для «да / нет» не противоречат друг другу. Значения 1 и 0 подходят, когда отсутствие свойства означает полную потерю полезности. Значения 0,67 и 0,33 можно применять, когда даже худший вариант сохраняет некоторую ценность. Выбор шкалы является частью экспертного суждения и должен быть зафиксирован до сравнения.

Как сделать субъективную оценку почти объективной

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

1. Сначала определить шкалу и признаки каждого балла.

2. Дать экспертам одинаковые материалы и одинаковые практические задания.

3. Собирать оценки независимо, до общего обсуждения.

4. Привлекать специалистов разных ролей: администратора, разработчика, специалиста по безопасности, инженера эксплуатации.

5. Сохранять не только балл, но и его основание.

6. Усреднять оценки нескольких экспертов и отдельно смотреть на разброс.

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

Для обычного внутреннего сравнения достаточно прозрачного среднего:

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

Эксперты при этом не обязаны сразу ставить дробные числа. Например, три специалиста могут оценить безопасность кандидата словами: «отлично», «хорошо», «отлично». После применения заранее согласованной шкалы 1; 0,75; 0,5; 0,25 получаем 1, 0,75, 1, а групповая оценка равна (1 + 0,75 + 1) / 3 = 0,917.

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

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

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

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

Как свести всё в одну таблицу

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

После перевода к общей шкале получаем:

Так в одной матрице оказываются и результаты стенда, и экспертные оценки.

Здесь использована простая относительная нормализация из исходной методики: для критерия «меньше — лучше» лучшее ненулевое значение делится на значение кандидата, а для «больше — лучше» значение кандидата делится на максимум шкалы. Поэтому лучший результат равен 1, а остальные остаются между 0 и 1. Если все исходные значения одинаковы, критерий не различает кандидатов и его нужно либо исключить, либо присвоить всем одно заранее согласованное значение.

Метод комплексной оценки Гудкова

Для сведения критериев мы использовали метод комплексной оценки, описанный П. А. Гудковым в учебном пособии «Методы сравнительного анализа». Ниже — наша прикладная реализация этого подхода.

Его идея состоит в трёх действиях:

1. привести разные показатели к общей шкале;

2. определить вес каждого критерия;

3. сложить взвешенные оценки и получить объяснимый итог.

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

1. Экспертные веса

Эксперты оценивают важность критериев. В демонстрационном расчёте средние оценки важности восьми критериев равны 9,5, 8,5, 9, 8, 7, 6,5, 6, 8,5. Делим каждую на общую сумму 63:

Для первого критерия: 9,5 / 63 = 0,151. Остальные веса считаются так же.

2. Вес по разбросу

Если кандидаты почти одинаковы по критерию, он плохо помогает их различить. Если оценки расходятся сильно, критерий заметнее влияет на выбор. В нашей реализации сначала считаем среднее нормализованных оценок:

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

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

Для времени TPC-DS получаем R₁ = 0,036. Аналогично считаем остальные критерии. Затем делим каждый R на сумму всех разбросов:

Для нашего примера получаем веса по разбросу 0,013, 0,032, 0,248, 0,083, 0,031, 0,155, 0,248, 0,190. SQL-возможность и встроенный аудит сильнее других различают A, B и C, поэтому получили больший вес по разбросу.

3. Обобщённые веса

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

Это не единственно возможный вариант метода. Гудков отдельно отмечает: если экспертные веса достаточно надёжны, можно использовать только V; если привлечь экспертов невозможно — только веса по разбросу Z. Мы используем среднее V и Z, потому что хотим одновременно учитывать приоритеты организации и различия текущих кандидатов.

4. Итоговая оценка

Каждую нормализованную оценку умножаем на вес критерия и складываем:

Для 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-возможности не компенсировалось другими преимуществами.

Именно в этом сила метода: можно спорить не с итоговым числом, а с конкретным требованием, шкалой или весом.

Что показало наше исследование

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

• StarRocks стал лидером нашего сравнительного контура: показал лучшие результаты в испытаниях на основе TPC-DS и получил высокие оценки по стабильности, скорости запросов и использованию дискового пространства. Отдельная работа с группами ресурсов помогла понять влияние CPU, памяти и конкурентности на результат.

• YDB показал себя перспективным участником исследования и заслужил дальнейшее внимание.

• TiDB выделился удобством развёртывания и готовыми средствами наблюдения: Prometheus, Grafana и собственной панелью управления.

• Arenadata, Postgres Pro и Citus присутствовали в поле рассматриваемых альтернатив. Но без публикации полного паспорта стенда и исходной матрицы было бы неправильно назначать им места в открытой статье.

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

Что даёт методика

После такого анализа остаётся не только таблица мест, но и полный след решения:

• откуда взялось каждое значение;

• какие критерии были обязательными;

• как словесные и числовые оценки приведены к одной шкале;

• почему критерий получил свой вес;

• за счёт чего кандидат поднялся или опустился;

• какой результат изменится при другом приоритете.

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

Послесловие

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

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

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

Короткий словарь

Материалы

• TPC-DS

• TPC-H

• Star Schema Benchmark

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

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

---