Forum internetowe heavy-duty, temat pracy inzynierskiej - zalozenia Opcje

[ergo]

eh generalnie temat pracy brzmi tak jak w pierwszym poscie "forum dyskusyjne zoptymalizowane pod duza ilosc wpisow", i ma dzialac nie tylko pod jednym rodzajem baz danych... nie moj wymysl tylko promotora, daltego wlasnie kombinuje z takimi sprawami jak kazde forum w oddzielnej tabeli itp...

Nie do konca sie chyba zrozumielismy. Optymalizacja wykorzystujaca ficzery
danej platformy to programowanie w najgorszym ze znanych mi stylow. Mam
nadzieje ze nie musze Panu tlumaczyc dlaczego.

Ma Pan opracowac mechanizmy forum heavy-duty, ktore pozwola mu dzialac bez
wzgledu na platforme. Co najwyzej potem przedstawi Pan testy wydajnosci i
reaktywnosci w zaleznosci od platformy implementacji.

totez sam sie zastanawiam co wlasciwie ja mam zrobic
chciaz do smiechu mi nie jest bo czasu coraz mniej a ja nie mgoe zaczac nawet :/

Ten post edytował ergo 18.12.2005, 11:50:43

[halfik]

z ta przesada ze mysql umiera przy 3 milionach rekordow to bym nie byl taki pewien.
Rozumiem ze tablica nie bedzie wygladac jak pas startowy szeroka, w pojedynczym rekodzie bedziesz mial okolo 30 kolumn.
Dobra konstrukcja potrafi naprawde wiele, ja aktualnie w mysqlu mam ponad 8 milionow rekordow z czego jedna tablica ma ich wlasnie okolo 3 milionow i nie moge powiedziec zeby stronka nam chodzila kiepsko, a wejsc mamy srednio okolo 80tys unikalnych.

Sh4dow a jaka wersje mysqla macie ze daje rade z 3 mln na pojedynczej tabeli?
jak mozesz wez walnij tam proste zapytanie z wherem, a pozniej ze 2 bardziej zlozone i podaj mi czasy odpowiedzi.

a wracajac do tematu. cachowanie moze sie przydac, ale trzeba cachowac pierdly. nie ma sensu cachowac tematow itd. - bo po 1) watpie zebysmy odciazyli baze - i tak co chwile bedziemy wysyac zapytania zebyc cachowac wyniki. 2) jak bedziemy caly czas zachowac zasisniemy dysk, bo zakladam ze to zwykly dysk 7200 a nie jakies monstrum typowo serwerowe - chociaz oczywiscie wszystko zalezy co oznacza termin "duza ilosc uzytkownikow".

mozna sie tez pobawiac w cache po stronie phpa i roznego rodzaju accelatory.

w sumie rownie glupimy pomyslem byloby umieszczenie kazdego forum na osbnym serwie BD. no ale tutaj trzeba by napisac jakis w miare inteligenty algorytm, ktory by z poziomu www pozwalal dodawac kolejne serwer i przenosilby tabele na tak dodany serwer. generalnie mozna rozproszyc baze. tylko beda jaja jak padnie 1 z serwerow. dlatego nie jestem specjalnym zwolennikiem czystego rozproszenia BD.

mimo wszystko ja bym kombinowal nad jakis progsem do inteligentnego i latwego zarzadzania srodowiskiem serwerow BD. polaczylm rozproszenie z replikacjami. fakt ze w sporo serwow by trzeba bylo ale trudno no ale to by rozwiazywalo problem. bo jesli cos za wolno chodzi - to wina bazy. dodajemy 2 serwery -> 1 przejmuje czesc tabel a drugi jest jego kopia bezpieczenstwa. i tak w kolko.

p.s
powiedz promotorowi zeby Ci dal caly kluster

[ergo]

p.s
powiedz promotorowi zeby Ci dal caly kluster

buahahah ... albo 2 od razu

rozmawialem dzisiaj z promotorem , i rozmowa byla bardziej konstruktywna, przede wszystkim forum ma miec ogromniasta liste postow ( czytaj nie wiem ile to jest ale duzo ;P )

i czesc rzeczy mozna trzymac w cache-u, ale dobrym pomyslem jest trzymanie oddzielnych for w oddzielnych tabelach ( ma to swoje wady oczywiscie i nie jest jakies super eleganckie, ale... ) , baza tworzy oddzielny plik dla kazdej tabeli wiec czasu wyszukania oddzielnych rekordow beda mniejsze niz by mialo skanowac jeden ogromny plik ( nie zaglebiamy sie w takie problemy jak wyszukiwarka itp ... ) na 100% przyspieszy to dzialanie .

Kolejny pomysl to rotowanie forow do jakichs tabel archiwizacyjnych zeby user na zadanie mogl uzyskac dostep do tych danych a reszta normalnie , ale nie wiem jeszcze w jaki sposob to by mialo byc rozwiazane jeszcze.

takze bardziej to beda tricki zwiazane z serwerem baz danych niz z php i optymalizacja aplikacji samej w sobie , najbardziej waskim gardlem bedzie chyba baza i na tym sie trzeba skupic.

( temat i tak jest teoretyczny scisle i nie bedzie tam testu na 10000 uzytkownikow i obciazenia 300 osob online - liczy sie ilosc wpisow w bazie )

[mike]

Tabela dla każdego forum to poroniony pomysł, sprzeczny z zasadami optymalnego tworzenia baz danych.

Mówisz że ma wady. Oczywiści że ma wady. A jakie ma wg. Ciebie zalety?

[Vengeance]

"czytaj nie wiem ile to jest ale duzo ;P"

Patrząc na tak popularne fora jak phpBB.com i wiele innych tego typu z ogromną ilością postów, chyba nie istnieje takie które mogło by zagrozić stabilności MySQL.

Tak więc dowiedz się dokładniej co on uwarza za "dużo", bo wg mnie to "dużo" jest nierealnie duże i niedoosiągnięcia ;p

[NuLL]

3 miliony rekordow w tabeli MySQL to zadne wyzwanie w mojej opinii.

Jw. tworzenie osobnych tabel dla postwo czy poszczegolnych for to poroniony pomysl.

[ergo]

3 miliony rekordow w tabeli MySQL to zadne wyzwanie w mojej opinii.

Jw. tworzenie osobnych tabel dla postwo czy poszczegolnych for to poroniony pomysl.

dlaczego poroniony pomysl ? wiem ze wyszukiwanie bedzie mocno ograniczone w dzialaniu itp... ale ten poroniony pomysl ma podstawy w funkcjonowaniu dyskow twardych:

- seek time danych na dysku z tego co mi sie wydaje powinien byc mniejszy w momencie kiedy mamy do czyniena z mniejszymi plikami niz z wiekszymi ( a kazda tabela to przeciez osobny plik ) wiec bedzie wiecej mniejszych plikow z poszczegolnymi tabelami dla kazdego forum niz jedna ogromna tabela posts dla przykladu - ale to moja teoria.

moze wy macie jakies pomysly w sposobie optymalizacji tego ? nie martwcie sie tym ze wyszukiwanie nie bedzie dzialac tak jak na popularnych forach itp. to nie jest akurat tutaj najwazniejsze.

Forum jako takie ma byc jak najlzejsze dla serwera... takie jest zalozenie - to wszystko prawdopodobnie wyjdzie dopiero w benchmarkach dlatego kazda duperele musze wziasc pod uwage

Ten post edytował ergo 19.12.2005, 00:18:00

[dr_bonzo]

Zasada XP: nie zgaduj -- zmierz.
Zrob wg. jednej z koncepcji -- potem dodaj tabele dla kazdego z forum i poprzenos tematy i sprawdz wydajnosc.

[NuLL]

http://www.webhostingtalk.com/

Zwykly nietuningowany vBulletin

Total Threads: 460,437
Total Posts: 3,540,723

Proponuje nie kombinowac tylko porzadnie przemyslec strukture baze, ustawic odpowiednie indeksy a takze zadbac o mechanizm cache.

Z tego co wiem jesli baza spelnia te warunku to skrypt bedzie zasuwal nawet jak bedzie 10 mln postow. Sa odnotowane wyniki kiedy MySQL mial w tabeli 5 MILIARDOW rekordow.

[ergo]

Zasada XP: nie zgaduj -- zmierz.
Zrob wg. jednej z koncepcji -- potem dodaj tabele dla kazdego z forum i poprzenos tematy i sprawdz wydajnosc.

w sumie zgadzam sie w 100% tylko ze 1 : na domowym kompie moge miec problemy z odczuwalna roznica - ale to sie zmierzy
2: ( co mnie bardziej martwi ) za pozno sie za to wziaem i boje sie ze jak popelnie zbyt duzo pomylek albo zabrne w slepe uliczki to po prostu nie zdaze sie obronic ... a to by nie bylo przyjemne...


NuLL
spojrzyj na to:

http://www.gaiaonline.com/forum/index.php

Who is Online - In total there are 28899 users online :: 23757 Registered, 3185 Hidden and 1957 Guests

Gaia has 476,385,579 articles posted with 3,010,945 registered users.
Most users ever online was 41,319 on Tue Nov 01, 2005 5:08 pm

webhostingtalk ( ktory zreszta czesto przegladam ) to nic w porownaniu z tym - tam jest masa optymalizacji podobno zeby to dzialalo... chociaz nie wiem do konca co lanzer tam po wprowadzal

Ten post edytował ergo 19.12.2005, 00:30:19

[ghostrider]

do zmierzenia wydajnosci uzywam:
http://www.microsoft.com/downloads/details...&displaylang=en
i polecam jesli masz jakis wolnostojacy komputer w sieci.

[halfik]

no ale po co mierzyc? ten pomysl jest poroniony :] zeby na cos takiego wpasc i jeszcze wierzyc ze to moze byc dobry pomysl trzeba byc nie tylko doktorem, ale od razy profesorem

no bo i co z tego ze to troszke skroci czasy wyszukiwan, jak nam udu... (za przeproszeniem) mozliwosc skladania zlozonych zapytan. cala teoria i praktyka o modelowaniu baz danych ida w tym momencie w piz...

to chory pomysl :]
ten czas jaki sie w ten sposob zyska mozna zyskac w innych miejcach nie ponoszac az tak duzych strat w mozliwosiach.

p.s
zapytaj sie tego promotora czy on by chcial miec taka chate - tj. poko na 1 ulicy, kuchnie na innej, lazienke na kolejnej itd.

[ergo]

no bo i co z tego ze to troszke skroci czasy wyszukiwan, jak nam udu... (za przeproszeniem) mozliwosc skladania zlozonych zapytan. cala teoria i praktyka o modelowaniu baz danych ida w tym momencie w piz...

ten czas jaki sie w ten sposob zyska mozna zyskac w innych miejcach nie ponoszac az tak duzych strat w mozliwosiach.

masz jakies pomysly na tym zyskiwaniu w innych miejscach ? wlasnie po to jest ten temat zeby ludzie wpisywali swoje pomysly na optymalizacje.

(co do tych mozliwosci to podejrzewam ze to forum nie bedzie mialo zbyt duzych ;-) bo nie taki jest jego cel.)

[mike]

Dobry projekt bazy danych. Czyli ładne relacje, indeksy, ...

Jednym słowem na bazie optymalnie zaprojektowanej, która zachowuje zasady normalizacji baz łatwiej się pracuje i można osiągnąć "małe czasy jej wykożystywania".

Zapytania nie będą trwały długo a odpowiednio napisane zdejmą ciężar pewnych rzeczy z php.

Jeszcze raz powiem:
Pomysł z dzieleniem tabel pod fora to pomysł poroniony i chory.

No weś na przykład wyszukaj wszystkie posty autorstwa mike_mech i przeanalizuj jak to zrobisz na "normalnej bazie" i na ... "innej"

Gwarantuje Ci że nawet najprostsze żeczy bedą u Ciebie wtedy bardzo spomplikowane.

Rozbijając bazę na tyle tabel nie zyskasz NIC a stracisz bardzo wiele.

[NuLL]

Czesc osob piszacych w temacie zachowuje sie jak generatory problemow ktorych tak naprawde nie ma. Wymyslacie rozwiazania absurdalne ktore tak naprawde nie sa nikomu potrzebne.

Zrozumcie ze dla MySQL-a 3 czy 5 milionow rekordow to nie tak duzo.

[sobstel]

No weś na przykład wyszukaj wszystkie posty autorstwa mike_mech i przeanalizuj jak to zrobisz na "normalnej bazie" i na ... "innej"

problem ten mozna rozwiazac korzystajac z MERGE storage engine (w przypadku MySQL) - http://dev.mysql.com/doc/refman/5.0/en/mer...age-engine.html , ale to tylko informacja, a nie dyskusja nad tym ktore rozwiazanie lepsze ;-)

[hawk]

A nie prościej stworzyć jedną dużą tabelę i podzielić na partycje?

[ergo]

no ok, to problem dzielenia for na poszczegolne tabele mozna odrzucic ( cociaz wyszukiwanie postow to sprawa dziecinna - nie music byc pelnej funkcjonalnosci jak np. posty z wszystkich for - musicie to zrozumiec ze ten projekt nie zaklada pelnej funkcjonalnosci forum "komercyjnego" )

prosilbym o pomoc a wlasciwie o linki do materialow odnosnie optymalnego planowania baz danych ( nie mySQL - to ma dzialac na innych bazach tez ) - ew. sugestie wlasnie rozplanowania bo na sql malo sie znam

HAWK

a jak podzielisz tabele (bo rozumiem ze chodzi ci o plik ) na partycje, na windowsie ?

Ten post edytował ergo 20.12.2005, 13:23:16

[NuLL]

ew. sugestie wlasnie rozplanowania bo na sql malo sie znam

To proponowalbym poznac sie, bierzesz sie za cos o czym nie masz pojecia. Forum heavy-duty bez za dobrej znajomosci sql - swietny pomysl.

[ergo]

To proponowalbym poznac sie, bierzesz sie za cos o czym nie masz pojecia. Forum heavy-duty bez za dobrej znajomosci sql - swietny pomysl.

bez przesady ;P sredio skomplikowane forum , bez bajerow typu templaty itp. samo w sobie bym napisal bez problemu, tylko ta kwestia " dobrego rozplanowania " bazy , mnie martwi wlasnie - jak to zrobic najoptymalniej.
Ale wracajmy do tematu :]

Ten post edytował ergo 20.12.2005, 13:37:30