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

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

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

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

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.

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...

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

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).

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