HSET и HGET
Тема дорожной карты · Redis
HSET key field value [field value ...] сохраняет одну или несколько пар «поле — значение» в хэше Redis, а HGET key field извлекает значение для одного поля. Хэши Redis — это эффективные по памяти структуры данных, идеально подходящие для представления объектов: профиля пользователя, записи сессии или карты конфигурации, где каждое поле является именованным атрибутом. HSET заменяет устаревшую команду HMSET и теперь принимает несколько пар «поле — значение» в одном вызове. HGETALL key возвращает все поля и значения хэша в виде плоского списка, тогда как HKEYS и HVALS возвращают только имена полей или только значения соответственно. Хэши Redis используют компактное кодирование ziplist для небольших объектов (менее 128 полей, значения не длиннее 64 байт), что делает их значительно более эффективными по памяти по сравнению с хранением каждого поля как отдельного строкового ключа.
Как это работает
HSET и HGET — два фундаментальных типа. Lists (LPUSH/RPUSH/LPOP/RPOP/LRANGE) — связные списки: быстрый push/pop с обоих концов (O(1)), медленный random access (O(N)). Hashes (HSET/HGET/HGETALL/HMSET) — мэп поле→значение внутри одного ключа: идеально для object-like данных (юзер с name, email, plan). Оба отлично подходят для queue-паттернов (BLPOP/BRPOP — блокирующие) и per-entity хранения атрибутов.
Когда применять
Lists — для очередей (LPUSH producer + BRPOP consumer — базовая work queue), таймлайнов недавней активности (LPUSH + LTRIM хранит последние N), упорядоченных логов. Hashes — когда у одной сущности много полей и вы запрашиваете по ID сущности: эффективно по памяти (один ключ на сущность) и атомарные апдейты по полю. Redis Streams (настоящий append-only лог с consumer groups) — предпочитайте list-based очередям на production-масштабе.
Типичные ошибки
Ловушки HSET и HGET: гигантский HGETALL на хеше с 100K полей (блокирующая команда; весь хеш сериализуется); lists как очередь сообщений с at-least-once (нужны ack — используйте Redis Streams); LRANGE 0 -1 на миллион-элементном списке (network buffer старит всех); неограниченный рост списка (max length через LPUSH ... LTRIM 0 N-1).