Типы данных Redis: обзор под задачи Go

Пять базовых типов — строки, хэши, списки, множества и сортированные множества — плюс шестой, Streams, для журналов событий. Строки — универсальный дефолт: кэш ответа, счётчик, флаг, готовый JSON. Хэши хранят объект как карту поле-значение и позволяют менять одно поле, не трогая остальные. Списки — упорядоченные коллекции с быстрыми операциями по краям, из них собирают очереди задач. Множества хранят уникальные значения без порядка и умеют пересечения и разности. ZSET — то же множество, но у каждого члена есть числовой score, и выборка идёт по диапазону очков: отсюда лидерборды и тренды. Streams — журнал с чтением по позициям и группами потребителей, старший брат списков для серьёзных пайплайнов. Таблица ниже — шпаргалка, к которой стоит возвращаться при проектировании схемы: она отвечает на вопрос «каким типом хранить» за пару секунд.

Строка — единственный тип, который нужен для классического кэша: SET кладёт значение, GET достаёт. Называть её строкой честно только с натяжкой: значение может быть текстом, числом, JSON-документом или произвольными байтами — Redis бинарно-безопасен, а потолок одного значения — 512 мегабайт, до которого почти никто не добирается. Числовые строки получают суперспособность: INCR и DECR атомарно меняют значение, поэтому счётчик просмотров — это строка с числом, и никакой мьютекс не нужен. В go-redis метод Set принимает значение как интерфейс, так что положить можно строку, int, float или слайс байт; структуры сериализуют в JSON руками — этому посвящён отдельный урок про кэш структур. Строки — правильный дефолт: сомневаетесь, каким типом хранить, — кладите строку и усложняйте, только когда упрётесь в задачу.

Хэш — карта внутри ключа: HSet пишет поля, HGet читает одно, HGetAll возвращает всё сразу. Профиль пользователя — канонический пример: имя, возраст и статус обновляются по отдельности, хэш экономит трафик и не даёт затереть соседнее поле, как случилось бы с перезаписью целой строки. В Go значения полей — обычные аргументы через запятую или готовая map. Список — упорядоченная коллекция с быстрыми операциями по краям: LPush кладёт в голову, RPop забирает из хвоста, и на этой паре держится простейшая очередь задач — продюсер кладёт, воркер забирает. Блокирующий BRPop усыпляет воркер до появления задачи вместо дежурного опроса пустого списка. Множество — набор уникальных значений без порядка: SAdd добавляет, дубликат тихо игнорируется, SIsMember проверяет наличие за константное время, SInter находит пересечение двух множеств. Уникальные посетители дня, теги статьи, права пользователя — всё это множества. Для сопоставления с Go: hash — map, list — двусторонняя очередь, set — map с пустыми значениями.

Сортированное множество — визитная карточка Redis. Каждый член хранится с числовым score, и структура держит порядок по нему постоянно: ZAdd записывает очки, ZIncrBy добавляет к существующим, ZRevRange вытаскивает топ N, ZRank отвечает, на каком месте участник. Лидерборд игры собирается тремя строками кода, и тот же механизм обслуживает тренды: score — число просмотров за час, member — идентификатор статьи. Второе применение — временные окна: score как timestamp превращает ZSET в скользящее окно для rate limiter — добавляем время каждого запроса, чистим устаревшее, считаем размер. В Go-коде запись выглядит как структура redis.Z с полями Score: 1500 и Member: user:42 — score всегда float64, поэтому большие целые идентификаторы в score не кладут — им место в member, а score остаётся метрикой.

История из реального проекта: корзину хранили строкой с JSON, в релизе переехали на хэш — удобнее менять поля по отдельности. Новый код записывает HSet, а старый воркер отложенных заказов по-прежнему зовёт GET по тому же ключу — и тут тонкость: GET по хэшу сервер вернёт ошибку WRONGTYPE ровно так же, как LPUSH по строке. Воркер стал падать на каждом заказе, очередь копилась, пользователи не получали подтверждений — классический инцидент из-за смены типа под живым ключом. Разбор дал два урока. Первый: тип ключа — часть контракта, и менять его можно только с миграцией, которая переименовывает ключи или переливает данные под новым именем. Второй: конвенция префиксов в имени — cart:, cart:v2: — дешёвый способ развести версии схемы и развести старый и новый код. WRONGTYPE в логах после релиза ищите сразу: это почти всегда переходный период смены схемы.

Правило выбора стоит проговорить как чек-лист. Значение пишется и читается целиком — берите строку. Объект с полями, которые меняются по отдельности, — хэш. Важен порядок обработки, задачи приходят и уходят — список. Нужны уникальность и проверка наличия — множество. Нужен порядок по числовому критерию, топы и диапазоны — ZSET. Нужен журнал, который переживает чтение и распределение между воркерами, — Streams. Если задача попадает в два пункта сразу, начинайте с более простого типа: хэш вместо строки окупается, только когда полей много и они живут своей жизнью, а Streams вместо списка — когда сообщениям нужна подтверждаемая доставка. Простые типы дешевле обслуживать, а миграцию между типами в Redis не завезли.

Вопрос, который всплывает на планёрках по лимитам памяти: зависит ли расход от типа. Зависит, и заметно. Каждый ключ в Redis — это не только значение, но и служебные структуры вокруг него, поэтому миллион мелких строк весит ощутимо больше, чем сумма их содержимого. Мелкий хэш, список или множество сервер хранит компактной кодировкой вроде listpack — несколько полей в одном ключе обходятся дешевле, чем несколько отдельных ключей-строк. Но у компактной кодировки есть порог по числу элементов и по размеру значений: после него структура переключается на общую кодировку, и компактность уходит. Практических следствия два. Объект с десятком полей выгоднее держать хэшем, чем рассыпать по ключам user:42:name, user:42:age. А список на миллион записей — это не компактность, а нагрузка на память и на команды по краям; для таких объёмов существует Streams и посвящённый им урок.