28
Содержание
Интересное получилось столкновение
Разработчик провел собственное исследование, сравнив производительность Redis и PostgreSQL в роли кэша.
Он ожидал увидеть очевидное превосходство Redis, но результаты оказались не такими однозначными — особенно с учетом unlogged-таблиц в Postgres.
Как проводили тест
- Был написан простой HTTP-сервер на Go с двумя эндпоинтами:
GETиSET. - В качестве кэша использовались: Redis (через go-redis) и PostgreSQL с
unlogged-таблицей (через pgx). - Оба сервиса запускались в k8s с лимитами: 2 CPU и 8 ГБ ОЗУ.
- Генерация нагрузки — с помощью
k6, с предзаполнением кэша 30 млн записей. - Тестировались три типа нагрузки: только чтение, только запись, смешанная (80% чтения и 20% записи).
Что показали тесты
1. Redis быстрее почти по всем метрикам
- При чтении Redis обработал более 11 000 запросов в секунду против 7400 у PostgreSQL.
- Задержки в Redis в среднем были на 20–30 мс ниже.
- При записи разрыв еще больше: Redis справлялся с ~10 700. запросов в секунду, а PostgreSQL — с ~6000.
2. Unlogged-таблицы действительно ускоряют PostgreSQL
- При использовании обычных таблиц производительность записи в Postgres падала почти в 3 раза.
- На смешанной нагрузке
unlogged-таблицы дали прирост примерно в 25%.
3. Redis стабильно использовал меньше ресурсов
- Redis не превышал 1.3 CPU и держал стабильное потребление памяти (~4–4.5 ГБ).
- PostgreSQL упирался в лимит CPU и требовал до 6 ГБ ОЗУ при нагрузке.
Когда стоит выбрать Postgres
Автор поста подчеркивает: несмотря на более высокую производительность Redis, он лично предпочитает Postgres в небольших и средних проектах:
- База данных все равно уже используется в проекте.
- Нет нужды в сложных TTL или автоудалении.
- Не хочется тянуть в проект еще одну зависимость.
- От 7000 до 8000 запросов в секунду — более чем достаточно для большинства задач.
7425 запросов в секунду — это больше полумиллиарда в день. Все на 10-летнем железе и обычном PostgreSQL. Мало кто работает на таких нагрузках.