Valuable insights
1.Современные СУБД бросают вызов необходимости кэша: Исследование проверяет, могут ли последние версии PostgreSQL и MySQL заменить выделенный слой кэша, такой как Redis, при достижении высокой пропускной способности в миллионы запросов в секунду.
2.Слабое масштабирование Redis по количеству ядер: Redis показывает ограниченную эффективность при увеличении числа ядер, достигая насыщения производительности уже на 6-8 потоках, что делает нецелесообразным развертывание на машинах с большим количеством ядер.
3.Высокая устойчивость PostgreSQL к конкурентным соединениям: PostgreSQL продемонстрировал способность обрабатывать тысячи одновременных соединений, что стало сюрпризом, хотя для достижения максимальной производительности требуется значительное увеличение объема оперативной памяти.
4.Эффективность оптимизированного MySQL (MyDB): Специализированная сборка MySQL под названием MyDB, включающая оптимизации, такие как H-pages, значительно превзошла ванильную версию MySQL, достигнув пропускной способности свыше миллиона RPS.
5.Ограничения использования СУБД без кэша: Традиционные СУБД могут заменить кэш только при строгих условиях, таких как 100% чтение и точечные выборки; смешанные нагрузки или некорректно оптимизированные запросы быстро снижают производительность.
Введение и Контекст Исследования
Выступление посвящено анализу архитектурных решений в контексте достижения высокой производительности, в частности, способности современных систем управления базами данных (СУБД) заменить выделенный кэш-слой. Спикер, Алексей Рыбак, имеет значительный опыт в разработке и предпринимательстве, включая работу в сфере такси и создание облачных образовательных сервисов, ориентированных на высокий перформанс. Основная цель доклада — эмпирически проверить устоявшиеся мифы о необходимости кэширования в сложных приложениях, используя актуальные версии продуктов на современном оборудовании.
Цели и Объекты Тестирования
Исследование сфокусировано на сравнении производительности ключевых кэш-решений и традиционных СУБД при имитации кэш-нагрузки, то есть преобладании операций чтения. В тестирование были включены самые свежие версии PostgreSQL (17), MySQL (8.0.4), а также кэш-системы: Redis, его новый аналог Volty, и Memcached. Тесты проводились на стандартном оборудовании с одним процессором и 48 виртуальными ядрами, стремясь оценить возможность достижения миллиона запросов в секунду (RPS) и масштабируемость по количеству открытых соединений.
Два Мира: Кэш Необходим Против Кэш Не Нужен
Существуют два полярных мнения относительно роли кэша в современных системах. Первое утверждает, что без хорошо настроенного кэша невозможно решить большинство проблем высоконагруженных приложений. Второе, более консервативное, настаивает, что при правильной настройке и тюнинге самой базы данных кэш становится излишним. Эти концепции отражают два разных подхода к проектированию: приверженность одному инструменту против веры в возможности традиционных СУБД.
Современный проект в принципе невозможен без кэша, потому что базы данных со многими вещами не справляются.
Исторический Экскурс: Проблема C10K
Необходимость в специализированных решениях, таких как кэши и NoSQL базы данных, исторически возникла из-за ограничений традиционных СУБД в обработке большого числа одновременных соединений, что стало очевидно в конце девяностых — начале нулевых (проблема c10k). В то время как традиционные СУБД оставались консервативными, развитие In-Memory баз данных и key-value хранилищ, таких как Redis (созданный в 2009 году), предложило более быстрые и легковесные альтернативы для обработки большого количества запросов в секунду.
Архитектурные Компромиссы и Эволюция СУБД
С точки зрения чистой архитектуры, кэш является неудобным дополнением, поскольку вводит потенциальную несогласованность данных, так как информация хранится более чем в одном месте. Идеальным было бы отсутствие кэша или его полная интеграция в базу данных. Однако современные СУБД, такие как PostgreSQL и MySQL, претерпели значительные оптимизации, особенно в части обработки соединений, что ставит под сомнение абсолютную необходимость внешнего кэша.
Модели Обработки Соединений
Кэши обычно используют мультиплексирование соединений (threads/processes), что позволяет эффективно обрабатывать большое количество одновременных подключений. Традиционные СУБД, например, PostgreSQL, долгое время использовали модель 'процесс на соединение'. Однако, начиная с пятнадцатой версии, PostgreSQL значительно улучшил легковесность своих процессов, позволяя работать с большим числом соединений, хотя и не достигая эффективности чистых кэшей в этом аспекте.
Методология Тестирования и Производительность Кэшей
Для проверки мифов было выбрано стандартное, не самое топовое оборудование с 48 виртуальными ядрами и 128 ГБ оперативной памяти, чтобы оценить производительность в реалистичных условиях, а не на пределе возможностей. Тестирование проводилось в режиме чистого кэша (без append-only или снапшотов) на наборе данных из 10 миллионов ключей, с целью достижения миллиона RPS.
Масштабирование Redis и Volty по Ядрам
Тестирование показало, что Redis масштабируется по ядрам неэффективно. При увеличении числа I/O потоков (iothreads) производительность росла, но максимум составлял около 300–400 тысяч запросов в секунду на данном железе. Volty продемонстрировал лучшую производительность, приближаясь к 1 миллиону RPS в точке максимальной отдачи Redis. Однако, дальнейшее увеличение числа ядер свыше шести или восьми не давало существенного прироста производительности ни для Redis, ни для Volty.
- Redis показывает слабое масштабирование после 8 ядер.
- Volty масштабируется лучше, но эффективность падает на большем числе ядер.
- Для преодоления ограничений Redis Cluster требует включения режима append-only и вносит дополнительный Cost на редиректы.
Сравнение с Memcached
При сравнении с Memcached выяснилось, что он обеспечивает значительно более высокую пропускную способность при тех же условиях. Memcached выдавал почти 1.7 миллиона RPS, в то время как Volty едва превышал 1 миллион RPS. Это подтверждает, что для чистого кэширования, если не требуется персистентность, Memcached сохраняет высокий потенциал производительности.
Сравнение Производительности Реляционных Баз Данных
Переход к тестированию СУБД выявил неожиданно высокую устойчивость PostgreSQL к увеличению числа одновременных соединений. Было зафиксировано, что PostgreSQL может стабильно работать при 5000 реальных процессов, что является значительным шагом вперед по сравнению с предыдущими годами. Однако для работы с десятками тысяч соединений требуются машины с гораздо большим объемом памяти, превышающим 128 гигабайт.
Тюнинг MySQL против PostgreSQL
В отличие от мифа о том, что MySQL 'из коробки' готов к большим нагрузкам, а PostgreSQL требует обширного тюнинга, тесты показали обратное: PostgreSQL потребовал минимальной настройки для достижения почти миллиона RPS на кэш-нагрузке. MySQL, напротив, нуждался в изменении ряда параметров для достижения сопоставимых результатов. Специализированная российская сборка MyDB, основанная на MySQL, показала себя отлично, превысив миллион RPS после применения оптимизаций.
Ситуация скорее обратная: PostgreSQL мне, например, совсем не пришлось тюнить, буквально подкрутить парочку параметров.
Пересмотр Мифов и Заключение
Анализ полученных данных позволяет пересмотреть изначальные гипотезы. Утверждение о том, что Redis плохо масштабируется по ядрам, подтвердилось. MySQL действительно может масштабироваться лучше, чем PostgreSQL, но в условиях чисто кэш-нагрузки достигнут паритет. Самым важным результатом стало подтверждение того, что современные традиционные СУБД достаточно производительны для обработки миллиона RPS на недорогом оборудовании.
Когда Базы Данных Достаточны
Слой кэша можно исключить, если нагрузка строго соответствует сценариям, на которых СУБД показывают высокую эффективность: это строгий режим только для чтения (read-only) и точечные выборки (point selects). Однако в реальных проектах практически всегда присутствует процент операций записи или возникают неоптимизированные запросы, которые резко снижают производительность базы данных при попытке имитировать поведение кэша.
- Смешанные нагрузки (чтение/запись) значительно снижают производительность СУБД.
- Невозможно гарантировать, что в базу не попадет плохо оптимизированный UPDATE или сложный запрос.
- При увеличении количества промахов (misses) производительность СУБД резко падает из-за необходимости обращаться к диску.
Направления Будущих Исследований
Несмотря на полученные результаты, остается ряд неисследованных аспектов. В первую очередь, необходимо протестировать смешанные нагрузки, поскольку на них производительность СУБД деградирует сильнее, чем у кэшей. Также стоит изучить производительность кластеров СУБД с использованием Connection Bouncers (например, PgBouncer), хотя предварительные данные показывают, что баунсеры могут снижать общую пропускную способность вдвое. В будущих тестах планируется включить такие продукты, как Tarantool, Dragonfly и ClickHouse в режиме Key-Value хранилища.
Questions
Common questions and answers from the video to help you understand the content better.
С чем связаны провалы и шум на графиках производительности при тестировании Redis и Volty?
Шум и провалы, наблюдавшиеся на графиках, вероятно, связаны с особенностями тестовой машины, в частности, с включенным гипертредингом. Полное устранение гипертрединга стабилизирует графики, но снижает общую производительность, что не соответствует условиям продакшн-среды.
Какая была доля попаданий (hit rate) в запросах при тестировании производительности кэшей?
В проведенных тестах доля попаданий (хит-рейт) была почти стопроцентной. Все тесты проводились после предварительной накачки данных по определенному правилу именованных ключей, что исключало промахи и обращение к диску.
Как увеличится производительность MySQL и PostgreSQL при росте числа промахов (misses) в кэш-нагрузке?
Ожидается, что производительность MySQL и PostgreSQL резко снизится при увеличении количества промахов, поскольку система будет вынуждена обращаться к дисковому хранилищу для поиска отсутствующих данных, вместо быстрого ответа из памяти.
Планируется ли включить в будущие исследования такие системы как ScyllaDB или Cassandra?
В идеале, планируется включить ScyllaDB и Cassandra, а также другие распределенные системы. Однако из-за ограниченности ресурсов и необходимости сравнивать 'яблоки с яблоками' (однотипное железо), это требует создания унифицированного фреймворка для тестирования.
Useful links
These links were generated based on the content of the video to help you deepen your knowledge about the topics discussed.