Cache tabeli użytkowników Opcje

[Inscure]

Witam,

Ostatnio spotkałem się ze stwierdzeniem, że optymalnie jest zrzucać całą tabelę użytkowników do cache i z pliku odczytywać potrzebne dane.
Wydaje mi się to mniej wydajne niż odczyt z bazy gdzie nałożony jest indeks na kolumny, po których uzyskiwane są dane użytkownika.

Załóżmy, że tabela z użytkownikami posiada 50 000 rekordów w około 15 kolumnach.
Cache jest tworzony przez serializację do pliku całej tabeli oraz trzymany aż do zarejestrowania nowego użytkownika lub zmiany danych już istniejącego.
Ponadto z cache nie są odczytywane dane takie jak ostatnia wizyta (bo wiadomo, zmienia się z każdym odświeżeniem (leci zapytanie do DB aktualizujące)), jedynie sprawdzanie czy user taki istnieje w bazie (czyli w cache) oraz wyświetlanie podstawowych jego danych, takich jak nazwa, e-mail itd.

Co myślicie: cache tej tabeli ma jakiś sens?

Ten post edytował Inscure 5.02.2012, 13:10:49

[lobopol]

Nie w takiej formie. Cache całej tabeli jest bezsensowny.

[erix]

Co myślicie: cache tej tabeli ma jakiś sens?

Nie ma. Zmieni się choćby jeden rekord i wszyscy użytkownicy muszą aktualizować.

[ActivePlayer]

po pierwsze - zależy gdzie chcesz trzymać taki cache. jeśli w pamięci ram (np za pomocą memcached) to ma sens.
po drugie - raczej cache dla każdego uzytkownika osobno. ważne tutaj jest dobranie kluczy po których się wyszukuje. gdybyś np dodał cache z loginem jako klucz cache, wtedy praktycznie w zerowym czasie dostępu mógłbyś pobrać dane o użytkowniku (i np zweryfikować czy wpisał poprawne hasło).
po trzecie - takie rozwiązanie wymaga dobrego przemyślenia architektury aplikacji - tak aby system dbał o aktualizację cache w momencie zmiany bazy danych.

z tego co wiem nk.pl używa tego rodzaju cache. tzn jeśli wyszukujesz znajomych, to wysyłają zapytanie do bazy danych "select user_id from friends..." (nawiasem też to cachują) a potem każdego usera odczytują już bezpośrednio z memcache, lub jeśli części danych to doczytują je z bazy i wstawiają potem do cache, dla przyszłych requestów).

[erix]

po pierwsze - zależy gdzie chcesz trzymać taki cache. jeśli w pamięci ram (np za pomocą memcached) to ma sens.

Nie do końca. Bo marnujesz wówczas pamięć - baaaaaaaardzo rzadko zdarzają się sytuacje, w których 100% bazy jest wczytywany. Pomijam już fakt problemów z synchronizacją.

z tego co wiem nk.pl używa tego rodzaju cache. tzn jeśli wyszukujesz znajomych, to wysyłają zapytanie do bazy danych "select user_id from friends..." (nawiasem też to cachują) a potem każdego usera odczytują już bezpośrednio z memcache, lub jeśli części danych to doczytują je z bazy i wstawiają potem do cache, dla przyszłych requestów).

Cache w nk.pl, to w ogóle majstersztyk. Jak mi o tym znajomy opowiadał, to miałem oczy jak pięciozłotówki.

[ActivePlayer]

na 4developers zeszłorocznym był gość, który o tym opowiadał.

generalnie mają sieć serwerów, każdy z nich ma swoją instancję apache + memcache + jeszcze jakaś struktura główna której nie do końca pamiętam. w praktyce wyglądało to tak że wszystko było trzymane w memcache, a tylko w przypadku braku aktualności danych, doczytywane one były z serwerów "wyższego poziomu" - również memcache a na końcu z bazy danych.

odnośnie marnowania pamięci - umówmy się - dla zastosowań o których rozmawiamy (pewnie nie o milionach userów) takie rozwiązanie jest do przyjęcia. oczywiście można później obcinać cache o pewne dane, które nie są zawsze potrzebne (np trzymać tylko nick, imie, id avatara, etc) ale to wymagało by chyba dyskusji na większym poziomie szczegółowości. Dla baz które mają po 5000 użytkowników, nawet 200MB zajęte przez memcache to pryszcz. w sumie rozwiazanie nie głupie bo zazwyczaj wąskim gardłem na małych serwerach jest procesor a nie brak ramu.