intermediate
Hashes
Используйте hashes для small field maps, когда partial updates и grouped cache values fit memory behavior.
Hashes хранят карты полей под одним ключом — эффективно для небольших объектов, где обновляют отдельные поля без перезаписи всего сериализованного blob. Типично: атрибуты сессии, поля кэша товара, feature toggles по tenant.
HSET user:42 name "Ada" plan "pro" lastSeen 1718448000
HGET user:42 plan
HMGET user:42 name plan
HINCRBY cart:42 qty 1
HGETALL user:42 # только для маленьких map
| Предпочитать hashes | Предпочитать strings | |---------------------|----------------------| | Частичные обновления полей | Замена значения целиком | | Небольшие стабильные наборы полей | Большие JSON-документы | | Сгруппированная cache entity | Простой счётчик или token | | `HINCRBY` для числовых полей | Достаточно atomic string ops |
Redis кодирует маленькие hashes компактно; очень большие hashes ведут себя как множество мелких ключей. Держите число полей умеренным и избегайте `HGETALL` на горячих путях с сотнями полей.
На интервью: сравните обновление одного поля hash с десериализацией JSON string для той же сущности.
Типовые ошибки: гигантские hashes вместо документов в БД; `HGETALL` на больших map; hashes как relational table с неограниченными колонками; нет TTL на родительском ключе.
Компромисс — память и частичные updates vs гибкость запросов: hashes оптимизируют field-level churn в кэше; strings или внешнее хранилище выигрывают для больших или сложно запрашиваемых объектов.
Чеклист:
- Ограничьте число полей и именуйте ключи единообразно.
- Используйте `HMGET` только для нужных полей.
- Задавайте TTL на ключ hash при необходимости.
- Сравните hash и JSON string по паттерну обновлений.