Wieksze pole w db lub rozbicie ogromnego stringa na dwa Opcje

[Qspy]

Witam,
Zapisuje do zmiennej liste uzytkownikow online, jednak jest ona tak duza ze w bazie danych nawet rekord LONGTEXT niewystarcza. Zatem pytanie, czy da sie stworzyc wiekszy rekord w bazie danych niz LONGTEXT? Bo jezeli nie, to trzeba bedzie rozbic ta zmienna z lista online na dwie, i zapisac polowe do jednego rekordu LONGTEXT a druga polowe do drugiego. Dopiero przed wyslaniem userom pobrac oba i zlepic w jeden sprintf'em. Wady? Dodatkowe zapytanie (pobieranie z oby rekordow zamiast z jednego) wiec wolabym ten pierwszy sposob, tylko czy sie da.

Pozdro

[cicik]

Mógłbym wiedzieć po jakiego czorta zapisujesz listę userów on line do bazy danych?

Ten post edytował cicik 8.06.2007, 10:32:43

[Qspy]

to niema nic do tematu, ale zdradze ze dla 5 krotnego zysku wydajnosci

[cicik]

Jeżeli dla wzrostu wydajności to Ci powiem, że jeżeli zserializujesz tablicę z userami do pliku to zyskasz jeszcze drugie 5 razy.

Edit:
Z tego co wyczytałem pole LONGTEXT mieści max. 4GB danych.
Jeżeli Twoja lista userów nie mieści się na 4GB to uważam, że jeżeli chcesz się nią ostro bawić to zabijesz serwer. Domyślam się, że chcesz ją wyświetlać na stronie... Naprawdę chcesz wysyłać do internauty 4GB danych?

Ten post edytował cicik 8.06.2007, 10:32:58

[Darti]

Dopiero przed wyslaniem userom pobrac oba i zlepic w jeden sprintf'em. Wady? Dodatkowe zapytanie (pobieranie z oby rekordow zamiast z jednego) wiec wolabym ten pierwszy sposob, tylko czy sie da.

To nie trzymaj userów w jednym rekordzie bo to chyba nie ma sensu, lepiej kazdemu nowemu userowi dopisywać nowy rekord i wykonać zapytanie w stylu:

[SQL] pobierz, plaintext 
SELECT GROUP_CONCAT(`user_name` SEPARATOR '') FROM `users`
[SQL] pobierz, plaintext 

co zwróci wynik taki, jak by było wszystko w jednym rekordzie.

No i te 4 GB ....

[Qspy]

Hmm, czyli to niechodzi o dlugosc bo lista ma okolo 800 pozycji ale do kazdego jest dolaczony link do profilu co ja rozdluza do paru MB ale to nie GB ;].

Niewiem czemu w takim razie tak sie dzieje, ze gdy jest mala lista to ja zapisze do bazy, a jak przychodzi wiecej osob i lista sie robi dluga to juz sie niezapisuje do bazy.

[PHP] pobierz, plaintext 
<?php
$sql = "UPDATE phpbb_statystyki SET wartosc = '$online_userlist' WHERE nazwa = 'lista_online'";
 $db->sql_query($sql);
?>
[PHP] pobierz, plaintext 

Proste ale raz dziala a raz nie. ( w $online_userlist jest ta cala lista )
PS
Z tym kolejnym 5 razy szybciej, zeby to cache'owac na dysku to glupota, bo to by tylko bylo szybciej gdyby baza danych byla bardzo obciazona. Gdy jest nieobciazona, to z bazy danych pobrac dane jest znacznie szybciej niz z dysku.

PS2
Teraz zaczelo dzialac... nic niezmienialem... ciekawe kiedy przestanie

Ten post edytował Qspy 8.06.2007, 15:10:51

[cicik]

Z tym kolejnym 5 razy szybciej, zeby to cache'owac na dysku to glupota, bo to by tylko bylo szybciej gdyby baza danych byla bardzo obciazona. Gdy jest nieobciazona, to z bazy danych pobrac dane jest znacznie szybciej niz z dysku.

Taa?
A silnik systemu bazy danych to niby wszystko w RAMie ma? Albo na pendrivie?
Pomyśl logicznie... która sekwencja operacji będzie szybsza:

1) otworz plik -> wczytaj zawartosc -> zamknij plik
2) wyslij zapytanie -> interpretuj zapytanie -> przygotuj plan wykonania zapytania -> przeszukaj indeks -> sciagnij odpowiednie strony z dysku -> przefiltruj dane ze wczytanych stron -> przygotuj wynik -> fetchuj wynik -> prześlij fetchowane dane

Jak myślisz co będzie szybsze?

[Qspy]

Ta tylko dodaj do tego brak SCSI i ogromna liczbe i tak juz cache'owanych rzeczy. Usmieszki, bbcode, kategorie, styl forum... dysk tez ma ograniczona predkosc zapisu i odczytu wiec pozostala czesc rzeczy niech pozostanie w RAM'ie.

[Darti]

Nie to żebym się kłócił (nie wiem jaki dysk macie na serwerze...) ale cicik ma rację. Twoje zapytanie do bazy w porównaniu z metodą plikową wypadnie gorzej z tego powodu że nie korzystasz w zasadzie z żadnych udogodnień jakie baza danych oferuje (korzystasz z jednej tabeli i jednego pola, równie dobrze można korzystać w tym przypadku z jednego pliku).

[cicik]

(nie wiem jaki dysk macie na serwerze...)

Dysk tu naprawdę NIE MA nic do rzeczy. Baza danych swoje dane też trzyma na DYSKU.
Można by próbować robić testy gdyby baza danych była na najnowszym super szybkim dysku, a scachowany plik na jakimś złomie sprzed 10 lat.

[Darti]

Co się tak tych dysków uczepiliście ? To jak ten SĘK z kabaretu Dudek ... faktycznie nie ma znaczenia ten dysk, ale to nie istotne. Grunt że zapytanie do bazy wykona się wolniej niż odczyt z pliku (mówię konkretnie o TYM przypadku).
pzdr