standardowa sesje vs sesja w bazie Opcje

[nospor]

Prowadzil ktos z was jakies porownania wydajnosciowe w sprawie trzymania sesji w bazie vs sesja standardowa? Sa to jakies duzo roznice na niekorzysc sesji w bazie?

A jak teraz dodac do tego fakt, ze chcemy na biezaca znac aktywnych userow, to na standardowej sesji musimy dodawac dodatkowe rzeczy do bazy odnosnie zalogowanych userow i tak czy siak robic za kazdym razem odwolania do bazy. Zas przy sesji w bazie juz to wszystko nam odpada bo mamy sesje i tak w bazie i statad mozemy sobie wszystko pobrac. W tym przypadku juz tak duzej roznicy byc nie powinno.

Ktos cos?

[kayman]

jeżeli sesja w bazie to takiej działającej na zasadzie klucz->wartość np redis, w jakiejkolwiek sql'owej to imo bardzo zły pomysł

no chyba że apka jest dla kilku/kilkudziesięciu userów to można się bawić w takie cuda

ogólnie zwykła na pikach > sql'owa

[by_ikar]

Sesja w plikach - każdy zapis/odczyt to dodatkowe i/o dla dysku;
Sesja w bazie - jeżeli ustawisz sobie tabelę/kolekcje jako "in memory", to wciąż możesz odwoływać się do tych danych ale unikasz operacji bezpośrednio na dysku.

[redeemer]

Dodatkowo w środowiskach rozproszonych, gdzie aplikacja jest "zreplikowana" na n węzłow jest to "must-have".

[Pyton_000]

Sesja powinna być trzymana w takim miejscu żeby przy skalowalnej aplikacji Round Robin móc odczytać sesję. Może to być BD, może to być Redis (preferowany) albo shared storage.

[nospor]

Ok, dzieki za opinie

[daro0]

Niektóre frameworki, analizując FileStore zapisują pliki sesyjne np. w taki oto sposób

1)

app/storage/sessions/39/39ebd687d09eee8ded5e0a068ff6f8ff1376da15.sess
app/storage/sessions/3a/3af89014f96216b57a47fb7c5f316cb74b3b9162.sess
app/storage/sessions/7b/7bf3bb4a4cc5a24e1af3ad642d48f06d77158671.sess

a w nich serializowane dane.

Natomiast w domyślnej natywnej sesji jest jakiś katalog tmp a w nim pliki

2)
sess_ivg4t5j1k5f86ftu3mv89l1f65
sess_05md2phru9d1vihl99ic7kae55
sess_6lp60ho8lvvv9psou17h3o4pe2

i też to samo, serializacja

Czyli w 1) jest to porozrzucane a właściwie to uporządkowane w tych 2 znakowych podkatalogach, tutaj nazwy plików to sha1 na bazie jakiegoś unique id sesji, może być to też md5 ale też nie tak że wszystkie pliki w jednym katalogu ale w sumie w 256 2-znakowych podkatalogach.

Ktoś brał pod uwagę:

1) jeśli tych plików jest i z kilka milionów
2) ustawienia odśmiecania (np. 1%, 2% itd...)


Co do bazy danych to weźmy taką tabelę:

[SQL] pobierz, plaintext 
CREATE TABLE  `sessions` (
    `session_id` VARCHAR( 24 ) NOT NULL,
    `last_active` INT UNSIGNED NOT NULL,
    `contents` TEXT NOT NULL,
    PRIMARY KEY ( `session_id` ),
    INDEX ( `last_active` )
) ENGINE = MYISAM ;
[SQL] pobierz, plaintext 

I zapis do contents danych przy użyciu jeszcze dodatkowo base64encode

I teraz tak:

Jak to się wszystko ma do

a) szybkości
niezawodności (bo ja mając stronę na jakimś bezpłatnym hostingu obserwowałem swego czasu wywalanie się sesji natywnej z p. 2), były często, czego już nie było jak tylko zmieniłem sposób składowania, nie wiem dlaczego

No i jeszcze weźmy pod uwagę składowanie:

1. MongoDB
2. SSDB

Czy 1. jest też często stosowane? SSDB jest chyba jakąś alternatywą dla Redisa, przynajmniej tak mi się wydaje. Jakie macie tutaj doświadczenia?

[by_ikar]

@daro wrzucanie zserializowanych danych do bazy to czysta głupota. Już takie kwiatki jak JSON jako string w mysql widziałem i odradzam to każdemu.

Postawienie mongo do sessji też jest średnim pomysłem, bo lepszy jest już redis, a przy tym sporo lżejszy. Ewentualnie memcache.

[Pyton_000]

nie próbowałbym SSDB to jakaś dziwna chińska maszynka Skoro to jest alternatywa dla Redisa to nie widzę potrzeby stawiania kolejnego storage.
Mongo tak samo, jeśli da się użyc czegoś innego co już mamy i spełnia to wymagania to nie ma co mnożyć usług.

No chyba że mamy mega duży ruch i potrzebujemy wydajnego rozwiązania które zastąpi obecne kulejące.

[viking]

@daro wrzucanie zserializowanych danych do bazy to czysta głupota. Już takie kwiatki jak JSON jako string w mysql widziałem i odradzam to każdemu.

Ale zdajesz sobie sprawę że goła sesja w PHP serializuje/deserializuje automatycznie wszystkie dane zawarte w $_SESSION?

[Pyton_000]

Goła tak, customowa nie musi ale i tak nie widzę powodu żeby tego nie robić

[daro0]

Dla ścisłości chodzi o takie coś

[PHP] pobierz, plaintext 
$contents = base64_encode(serialize($data));
[PHP] pobierz, plaintext 

I to jest wysyłane do odpowiedniego pola w bazie. I proces odwrotny przy odczycie.

[Boshi]

@daro wrzucanie zserializowanych danych do bazy to czysta głupota. Już takie kwiatki jak JSON jako string w mysql widziałem i odradzam to każdemu.

Postawienie mongo do sessji też jest średnim pomysłem, bo lepszy jest już redis, a przy tym sporo lżejszy. Ewentualnie memcache.

No właśnie mam pytanie odnośnie pierwszego. Czemu to jest złe? kiedyś się zastanawiałem czy warto zapisać do mysql zserializowaną tablicę (mniej rekordów) a potem deserializować.. ale w sumie doszedłem jakoś do wniosku, że lepiej walnąć 100 rekordów niż jeden z tablicą, choć nie pamiętam co mnie przekonało do tego.