Czy warto użyć Redisa

Cześć,

Tworzę system rezerwacji, w którym jest kalendarz i 2 role (użytkownik, admin). Wiele osób może rezerwować usługę na daną godzinę, po czym administrator musi zaakceptować jedną. Myślałem o użyciu redisa do przechowywania danych użytkowników rezerwujących, np.

  1. 2 użytkowników rezerwuje usługę na godzinę 12:00-13:00,
  2. w redisie chce przechowywać w tablicy dane o rezerwacji, np.
    ["{:time_from=>“12:00”, :time_to=>“13:00”, :date=>“20-03-2018”, :user_id=>1}",
    “{:time_from=>“12:00”, :time_to=>“13:00”, :date=>“20-03-2018”, :user_id=>2}”]
  3. Administrator akceptuje jedną z rezerwacji => w bazie danych tworzona jest zaakceptowana rezerwacja, a z redisa wyrzucam wszystkie rezerwacje aplikujące na tą godzinę.

Czy uważacie, że to jest dobre użycie redisa?

Z góry dzięki za pomoc.

Czy w swojej aplikacji używasz już jakiejś bazy danych? Typowa aplikacja Rails jako podstawową bazę używa relacyjną bazę danych SQL, najczęściej PostgreSQL lub MySQL. Jeśli używasz już jednej z nich to nie widzę powodu by dane o których wspomniałeś zapisywać w Redisie.

Jako osoba kochająca Redisa miłością głęboką i na ogół odzwajemnioną poradziłbym głównie to, żeby jednak w Redisie żadnych danych wymagających persystencji nie zapisywać.

Hej,
przyjrzyj się postgresowi, ma coś takiego jak time range:
https://www.postgresql.org/docs/9.3/static/rangetypes.html

Jest to o tyle fajne, że pozwala Ci wykonywać różne fajne operacje: https://www.postgresql.org/docs/9.3/static/functions-range.html oraz tworzyć indexy na danych kolumnach. Szczególnie interesujące są operacje jak union, intersection etc w kontekście zapytań. Przy skomplikowanej logice applikacji może to oszczędzić tygodnie jeśli nie miesiące pracy :slight_smile:

PS. Miło widzieć topic w którym wypowiadają się osoby które były jeszcze na starym forum, może to forum jeszcze odżyje :slight_smile:

Dzięki za odpowiedzi.
Używam MySQL ale zastanawiałem się nad użyciem Redisa, ponieważ nie chcę zaśmiecać tabeli rekordami z danymi, których nie będę używał. Nie jestem pewien czy dobrze się zrozumieliśmy, np.
5 osób rezerwuję usługę na tą samą datę/godzinę => musiałbym stworzyć 5 rekordów, z których zaakceptowany przez administratora byłby jeden.
Mój pomysł był taki, aby nie wrzucać tego odrazu do MySQL tylko do Redisa. Do redisa wrzucam “oczekujące rezerwację” po zaakceptowaniu tworze tylko jeden rekord z rezerwacją w MySQL a z Redisa wyrzucam wartości dla tej godziny.

Uważacie, że lepiej nie bawić się z Redisem i wrzucać wszystko do MySQL i w tabeli mieć kolumnę accepted: true/false?

Czy może macie jakieś jeszcze lepsze rozwiązanie :slight_smile: ?

@slawosz dzięki za radę ale zacząłem tworzyć projekt już na MySQL :slight_smile: .

Jeśli nie masz danych na produkcji to przerzucenie się na Postgresa to 5 minut.
Ile będzie tych rekordów? Jeśli mniej niż 10 mln :wink: to spokojnie możesz użyć sql i w workerze usunąć niepotrzebne rezerwacje. Robiąc w redisie, będziesz musiał sam napisać kod do obsłużenia logiki - a po to są railsy, plus, jak Filip powyżej stwierdził, Redisowi lepiej w tym przypadku nie ufać.

Oj tam, w workerze od razu, ma ładnie określoną akcję która powoduje zinwalidowanie niektórych rekordów, zakładając, że rekordów do usunięcia będzie bardziej 5 niż milion ;>

Dzięki wszystkim za pomoc. Postanowiłem tak jak piszecie nie używać Redisa do tego :slight_smile: .
@slawosz danych jeszcze nie mam na produkcji więc zmienię bazę na PostgreSQL. Zawsze używałem MySQL to dobrze będzie poznać również PostgreSQL :slight_smile: .

1 Like

Nie robiłbym tego przez redisa. W praktyce,

  1. gdy padnie Ci instancja(bo nie masz clustra lub padnie cału cluster) to tracisz dane czyli admin nie zobaczy tych rezerwacji.
  2. Admin, nie zdąży zaakceptować rezerwacji a odpali się ttl to dane zginą.

Lepiej napisać to na mysqlu i logiką omachać to, żeby nie trzymane były dane pozostałych oczekujących, lub jakimś background jobem sobie czyścić bazę z rezerwacji oczekujących.
Poza tym kolejny klocek do maintenancu, lepiej upraszczać infra jeżeli rozbudowa nie jest konieczna:P.

2 Likes