Fablo: lubimy Redis!
2010-06-18
Zrobiło się cicho, bo pracujemy nad Fablo. A konkretniej, nad w pełni rozproszoną i skalowalną architekturą indeksowania.
Pierwsi klienci szybko uświadomili nam, że sama wyszukiwarka nie wystarczy: ściąganie i indeksowanie danych jest bardzo ważne. Jak się okazało po kilku spotkaniach, nasi klienci spodziewają się znacznie szybszej aktualizacji niż sądziliśmy: są firmy, gdzie lista produktów zmienia się co kilka minut!
Zabraliśmy się więc ostro do roboty. A ponieważ w startupie nie ma czasu na robienie rzeczy po kilka razy, postanowiliśmy zrobić raz a dobrze. Zaprojektowaliśmy w pełni rozproszoną architekturę, gdzie wydzielona została część indeksująca. Możemy teraz mieć wiele serwerów ściągających i przetwarzających wstępnie dane, oraz wiele tzw. indexerów, które faktycznie przeliczają wszystko, co potem jest potrzebne do wyszukiwania. A ponieważ nasza wyszukiwarka jest dość zaawansowana, owego przeliczania jest całkiem sporo.
Wszystko działa na serwerach Amazon EC2, a synchronizowane jest za pomocą Redisa. Z bazy tej jesteśmy bardzo zadowoleni. W zasadzie nie wiadomo czy można Redisa nazwać „bazą danych”, bo jest to połączenie rozproszonej synchronizacji z bazą danych i systemem kolejkowym. Ważne, że świetnie działa i pozwala szybko budować całkiem skomplikowane architektury.
Efekt? Nowa architektura jest w stanie ściągnąć i przeliczyć dane klienta w czasie poniżej minuty. Co więcej, przełączanie na nowy indeks odbywa się płynnie, bez jakiejkolwiek przerwy w obsłudze zapytań.
"Advanced key-value storage" to chyba całkiem celna nazwa.
BTW, macie / udostępniacie jakieś statystyki użycia (load, liczba zapytań)?
Filip: dotyczące samego Redisa? Bo jeśli chodzi o klientów to nie udostępniamy i nie zamierzamy, to są dane klientów.
Pierwsi klienci uświadomili wam, że... A jak ma się to harmonogramu rozliczeń z PARP ?
Pankracy: nie rozumiem pytania?
Jan: Chodzi mi oczywiście o samego Redisa - jak technicznie, to technicznie. ;-)
Filip: a — rozumiem — nie, nie mamy nic specjalnego, poza własnymi pomiarami. Z tych wynika, że Redis nie jest i raczej nigdy nie będzie wąskim gardłem, bo a) obsługuje od dziesiątek do niskich setek tysięcy zapytań na sekundę, b) znaczną część obciążenia możemy z niego zdjąć stawiając więcej serwerów Redis (nasza architektura na to pozwoli).
Na razie jednak jest to komponent o 2-3 rzędy wielkości wydajniejszy niż inne w architekturze, rozmyślania o skalowalności redisa zostawiamy więc na znacznie później.