rotator bannerow przy duzej ogladalnosci, ~200 tys dziennie, ~2 mln miesiecznie Opcje

[phpion]

Hej!
Bede pisal rotator bannerow dedykowany pod duza ogladalnosc serwisu. Miesiecznie jest to ok. 2 mln odslon, czyli wychodzi ok. 4 odslon na sekunde (liczac ze strona jest przegladana od 8:00 do 22:00).
Chcialbym sie was poradzic czy dobry system wymyslilem jak to wszystko zrobic aby sprawnie dzialalo.
Otoz widze to tak, ze mam w bazie tabele glowna oraz dzienna. Tabela glowna jest zbiorem zrzutow tabeli dzienna. User wchodzacy na strone otrzymuje banner; identyfikator bannera + data wyswietlenia i inne duperele sa wpisywane do tabeli dziennej. I tak za kazdym razem - mniejsza tabela -> szybsze operacje. Wpisywanie widze poprzez uzycie DELAYED INSERT zeby szybciej zwolnic skrypt. No i tak przez caly dzien tabela dzienna bedzie uzupelniana o dane. W nocy (mysle ok. 3 lub 4 w nocy) cron bedzie zrzucal dane z tabeli dziennej, wrzucal je do tabeli glownej i robil TRUNCATE tabeli dziennej. Na czas tej operacji moznaby wylaczac serwis.
Nie wiem czy jako tabele glowna nie zrobic zbioru tabel np. styczen-2007, luty-2007 zeby nie przepelnic tabeli glownej danymi. W sumie bedzie ona obslugiwana tylko przez administratora no ale wiadomo: co za duzo to niezdrowo. Takie rzeczy jak statystyki bedzie wtedy mozna robic tylko dla danego miesiaca, nie w przekroju rocznym - szkoda obciazac baze robiac SELECTa dla ~ 24 mln rekordow...
Prosilbym was o porady, uwagi. Na co zwrocic uwage projektujac baze danych. Ogolnie prosilbym o wszystkie informacje, ktore pozwola przyspieszyc caly proces pobierania danych o wyswietlanych bannerach oraz o kliknieciach w nie.
Pozdrawiam: pion

[Strzałek]

Ja bym się długo nie zastanawiał i użył phpAdsNew

[nrm]

strzałek: aby...? aby zmulić serwis jeszcze bardziej? PAN jest na bakier z wydajnością niestety. sprawdzone osobiście

[Strzałek]

No cóż. Używałem przy małych projektach tego skryptu, dawno to było. Wybaczcie moją niewiedzę Nie było to zamierzone. Dzięki normalnos

[nrm]

nie ma sprawy pastrzałek.

ja też jak autor tego tematui będę coś za jakiś czas kombinował, pewnie duzo mniej konfiguracji ale za to pod kątek wydajności.

[phpion]

No ja mam 2 kolejne mysli. Pierwsza to uzycie PostgreSQL zamiast MySQL. Druga natomiast to zrzut bazy do pliku *.php. Otoz chyba duzo szybsze od laczenia z baza i robieniem SELECTa przy kazdym losowaniu bannera bedzie taki myk, ze podczas dodawania/usuwania/edycji bazy bannerow bedzie wykonywana funkcja, ktora bedzie pobierala dane z bazy listy bannerow i zapisywala je w pliku z rozszerzeniem *.php ale w formie gotowej tablicy tj.

[PHP] pobierz, plaintext 
<?php
$array = array('banner1', 'banner2');
?>
[PHP] pobierz, plaintext 

Oczywiscie w mega uproszczeniu. Plik ten bedzie po prostu includowany i z tej tablicy bedzie wybierany jakis banner. Pozostaje kwestia update'owania tegoz pliku. Bede musial wykonac testy co bedzie szybsze:
- otwarcie pliku w trybie w+ i wpisanie nowej zawartosci
- utworzenie rownolegle drugiego pliku np. baza_new.php, usuniecie starego (np. baza.php) i zmiana nazwy baza_new.php na baza.php
Do tej pory sporo czytalem o optymalizacji samych skryptow php, musze jeszcze przeczytac o optymalizacji baz.

Przy okazji mialbym pytanie bo w sumie nigdy z tego nie korzystalem: w jaki sposob dziala stale polaczenie z baza danych? Teorie znam - ze nie nawiazuje polaczenia dla takich samych parametrow tylko uzywa juz otwartego. Jak to wyglada w praktyce? Majac skrypt.php i w nim otwarte stale polaczenie kazy internauta wchodzacy na skrypt.php uzywa tego samego polaczenia? Czy w moim przypadku nie byloby to dobre roziwazanie? Kwestia tylko taka, ze w takim wypadku polaczenie to byloby otwarte 24h/dobe...

[NuLL]

No ja mam 2 kolejne mysli. Pierwsza to uzycie PostgreSQL zamiast MySQL

LOL - przeciez PostreSQL jest wolniejszy niz MySQL - masz pojecie co piszesz ?

[nrm]

1. mysql
2. ew. statsy rozlozone na tabele-miesiące aby łatwo je było kasować (archiwizować)
3. zależy jak dużo informacji chcesz pobierać zanim wyswietlic wlasciwy banner. imho do 2 szybkich sqli to nie jest zle. zaleznie od schematu bazy / wyciągania danych częśc możesz keszować (serializacja tablic do plikow).

[phpion]

LOL - przeciez PostreSQL jest wolniejszy niz MySQL - masz pojecie co piszesz ?

No z tego co wiem to przy tak duzej liczbie danych Postgres bedzie wydajniejszy - ale moge sie mylic, tak czytalem.