Помогите определиться, как лучше спроектировать БД в redis?

Рейтинг: 0Ответов: 1Опубликовано: 02.08.2023

Делаю ТГ бота. БД юзеров бота хранится редисе в виде хеша

hset users:<tg_user_id> field_one key_one field_two key_two

В этом хеше хранится инфа об id юзера в тг, юзернейм в тг, статус оплаты, статус подписки.

Далее надо сделать, чтобы бот отправлял сообщения юзеру по расписанию на основе интересов юзера которые юзер указал боту.

Тут вопрос, как лучше сделать:

  1. создавать отдельно список интересов для юзера в редисе, затем перебирать его и отправлять контент из бд если интерес есть в списке.
  2. или просто добавить новые поля и значения хешу который уже создан когда юзера добавили в БД после нажатия команды /start. И уже проверять хеш на наличие полей с названием интереса и с ключом yes в нем и после отправлять сообщение.

Как думаете? Какое решение будет лучше\хуже и почему? Только учусь... много вопросов...

python aiogram redis
Источник: Stack Overflow на русском

Ответы

▲ 0

Оба подхода имеют свои преимущества и недостатки, и в конечном итоге зависят от ваших конкретных потребностей и предпочтений. Основные различия между этими подходами можно рассмотреть следующим образом:

  1. Создание отдельного списка интересов для каждого пользователя в Redis:

    • Преимущества:
      • Удобство: Вы можете легко получить список интересов для каждого пользователя и перебирать их для отправки соответствующего контента.
      • Гибкость: Пользователь может иметь различные интересы в разное время, и вы можете легко изменять и обновлять список интересов.
    • Недостатки:
      • Дополнительная сложность кода: Вам нужно будет обрабатывать отдельный список интересов для каждого пользователя и проверять его на наличие совпадений с контентом, который вы хотите отправить.
      • Увеличение размера базы данных: Если у вас есть большое количество пользователей и каждый имеет свой собственный список интересов, это может привести к увеличению размера базы данных Redis.

  2. Добавление новых полей и значений в существующий хеш пользователя:

    • Преимущества:
      • Простота кода: Вам не нужно обращаться к отдельному списку интересов для каждого пользователя, так как информация об интересах уже содержится в существующем хеше пользователя.
      • Более эффективное использование памяти: Поскольку информация об интересах хранится в том же хеше, что и другая информация о пользователе, это может уменьшить занимаемое место в базе данных.
    • Недостатки:
      • Ограничение на количество интересов: Если у вас есть ограниченное количество полей в хеше пользователя и вы хотите хранить большое количество интересов для каждого пользователя, это может стать проблемой. В этом случае вам может потребоваться пересматривать структуру вашей базы данных.

В конечном итоге, выбор между этими подходами зависит от ваших предпочтений и требований проекта. В целом, рекомендуется - проанализировать ожидаемый объем данных, количество пользователей и структуру вашей базы данных, чтобы принять более информированное решение.

А ещё, присмотритесь к другим системам кэша, например Dragonfly. Как показала практика на моей работе - весьма неплохая система. И полностью совместима с редис клиентами)