10 принципов правильного бенчмаркинга баз данных

На https://db-benchmarks.com/ мы тестируем различные базы данных с открытым исходным кодом и поисковые системы и разрабатываем платформу с открытым исходным кодом, чтобы вы тоже могли это сделать. В этой статье я хотел бы поделиться 10 наиболее важными принципами, которые мы для себя сформулировали и которые помогают нам делать качественные бенчмарки.

1. Протестируйте разные базы данных на одном и том же оборудовании. В ряде тестов баз данных я видел, как люди сравнивали конкурентов на разном оборудовании. Например, в тесте [Druid vs Clickhouse vs Rocket] (https://imply.io/blog/druid-nails-cost-efficiency-challenge-against-clickhouse-and-rockset/) говорится: «На самом деле мы хотели сделать тест на том же оборудовании, что и m5.8xlarge, но единственная предварительно подготовленная конфигурация, которая у нас есть для m5.8xlarge, на самом деле является m5d.8xlarge… Вместо этого мы запускаем экземпляр c5.9xlarge». Плохая новость, ребята: когда вы запускаете бенчмарки на другом оборудовании, по крайней мере, вы не можете сказать, что что-то «106,76%» и «103,13%» чего-то другого. Даже при тестировании на одном и том же чистом сервере довольно сложно получить коэффициент вариации ниже 5%. Разница в 3% на разных серверах, скорее всего, может быть проигнорирована. При условии всего этого, как можно убедиться, что окончательный вывод верен?

1. Протестируйте с полной очисткой кеша ОС перед каждым тестом. В DB Benchmarks мы специализируемся на тестировании задержки. Мы следим за тем, чтобы какой-то запрос к какой-либо базе данных занимал 117 мс сегодня, завтра и через неделю. Это фундаментальная вещь в платформе, без нее все остальное не имеет значения. Это сложно. Чтобы это произошло, важно убедиться, что при тестировании запроса среда точно такая же, как и в предыдущий раз. Одна из вещей, о которой люди всегда забывают, — это очистка кеша ОС. Если у вас нет шансов, у вас будет часть данных, которые ваш запрос должен прочитать с диска, уже в памяти, что сделает результат нестабильным.

1. Измеряйте холодный запуск отдельно. Диски, будь то NVMe или HDD, по-прежнему значительно медленнее, чем оперативная память. Люди, занимающиеся бенчмарками, часто не уделяют ему должного внимания, хотя это важно, особенно для аналитических запросов и аналитических баз данных, где часто могут возникать холодные запросы. Итак, принцип таков: измерять время холодного запуска отдельно. В противном случае вы полностью скроете результаты того, как база данных может обрабатывать ввод-вывод.

1. Все внутренние кэши тестируемой базы данных должны быть отключены. Еще одна связанная с этим вещь — отключить внутренние кэши базы данных. В противном случае вы просто будете измерять производительность кэша, что также может иметь смысл для некоторых тестов, но обычно это не то, что вам нужно.

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

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

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

1. Протестируйте на фиксированной частоте ЦП. В противном случае, если вы используете регулятор ЦП «по запросу» (который обычно используется по умолчанию), он может легко превратить ваше время отклика 500 мс в 1000+ мс.

1. Тестируйте на SSD/NVME, а не на жестком диске. В противном случае, в зависимости от того, где ваши файлы расположены на жестком диске, вы можете получить в 2 раза более низкую / более высокую производительность ввода-вывода (без шуток, в 2 раза), что может сделать как минимум ваш холодный запрос дает неправильные результаты.

1. Самое главное: больше повторений и контроль над CV. Это, пожалуй, самая распространенная ошибка в бенчмаркинге латентности: люди запускают запрос 2–3 раза, вычисляют среднее значение и все. В большинстве случаев нескольких попыток недостаточно, при следующем запуске того же запроса можно получить другой результат на 50%.

Но есть способ улучшить и контролировать его: делать больше повторений и контролировать коэффициент вариации. CV — очень хорошая метрика, показывающая, насколько стабильны результаты ваших тестов. Если он выше N%, нельзя сказать, что одна база данных на N% быстрее другой. Так что просто делайте достаточно повторений, пока ваш CV не станет достаточно низким (например, 3%). Если вы так и не достигли этого, значит, вы не сделали все возможное, следуя вышеуказанным принципам.

Я надеюсь, что эта статья поможет вам улучшить ваши тесты. Если вам нужно что-то готовое, загляните на https://db-benchmarks.com/. Это на 100 % бесплатная платформа и фреймворк с открытым исходным кодом (включая очень необработанные результаты тестов), которые помогут вам проще и быстрее тестировать базы данных и запросы.