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 по паттерну обновлений.