Duże aplikacje i load balancing, Czyli co i jak zrobic jak maszyna nie daje rady Opcje

[kwiateusz]

Temat założony na prośbę SHIPa oraz normanosa traktujący o rozkładaniu obciążenia na wiele maszyn

[rashid]

Zalozenie, ze operujac na wlasnym formacie plikow bedzie sie operowalo danymi lepiej niz BDB jest zludne. Duza zaleta BDB jest to, ze swietnie wykorzystuje mozliwosc przechowywania danych w RAM. Nie trzeba ladowac danych do pamieci i wtedy na nich operowac - wystarczy wczytywac dane poprzez BDB. Mala uwaga na sam poczatek - jesli zaczniesz testowac wydajnosc BDB, to nie bierz pod uwage pierwszego przebiegu po danych, bo jest kilkadziesiat/kilkaset razy wolniejszy niz kolejne.

BDB jest dostepne za darmo ze strony Oracle.

Przy okazji musze odradzic uzywanie PHP przy przetwarzaniu takich ilosci danych - slabe zarzadzanie pamiecia wyjdzie ci bokiem. Moze lepiej Ruby - my mamy bardzo dobre doswiadczenia z mixem Ruby + BDB?

[Krolik]

Przy okazji musze odradzic uzywanie PHP przy przetwarzaniu takich ilosci danych - slabe zarzadzanie pamiecia wyjdzie ci bokiem. Moze lepiej Ruby - my mamy bardzo dobre doswiadczenia z mixem Ruby + BDB?

Sorry, ale do przetwarzania bardzo dużych ilości danych to wszelkie języki interpretowane, w tym SZCZEGÓLNIE Ruby, są o kant d***y potłuc.
Ruby ma chyba najwolniejszy interpreter na świecie, do PHP + APC mu bardzo daleko. Wg Great Language Shootout w przetwarzaniu danych Ruby jest gdzieś ze 100-500 razy powolniejszy niż języki kompilowane (C, C++, C#, Java, Scala). No chyba że miałeś na myśli Ruby na JVM, ale też wydajnościowo żadna rewelacja.

Inna sprawa, że to nie ma aż takiego znaczenia, jak się tylko te dane wyjmuje z bazy danych i wysyła do klienta, bez żadnej wielkiej obróbki. Wtedy pisz sobie w czym Ci wygodnie. Wtedy i tak baza danych ma najwięcej roboty. Wrzuć to na serwer z dużą ilością RAMu, szybkimi dyskami i powinno śmigać.

A z tym 50 tys. użytkowników równocześnie, to ktoś tu robi błąd w założeniu, że wszyscy będą klikać równocześnie w serwis. Średnia liczba równoległych żądań, które musi być w stanie obsłużyć system wynosi w przybliżeniu:
liczba_aktywnych_sesji * częstotliwość_żądań_gen_przez_jednego_usera * czas_przetwarzania_żądania_w_s.
Czyli jeśli Twój system potrafi obsłużyć żądanie w maks. 1 s, a użytkownicy klikają średnio co 10 sekund, to przy 50 tys. użytkowników będziesz obsługiwał tylko 5000 równoległych żądań.

Tak z ciekawości chciałbym się dowiedzieć na czym polega ta "szybszość" BDB w porównaniu z RDBMSami, w sensie konkretnych argumentów.
Nie ma żadnego teoretycznego powodu, aby RDBMS był wolniejszy, a jest bardzo wiele za tym, aby był szybszy. Rashid, mógłbyś wyjaśnić, co miałeś na myśli?

[rashid]

Sorry, ale do przetwarzania bardzo dużych ilości danych to wszelkie języki interpretowane, w tym SZCZEGÓLNIE Ruby, są o kant d***y potłuc.
Ruby ma chyba najwolniejszy interpreter na świecie, do PHP + APC mu bardzo daleko. Wg Great Language Shootout w przetwarzaniu danych Ruby jest gdzieś ze 100-500 razy powolniejszy niż języki kompilowane (C, C++, C#, Java, Scala). No chyba że miałeś na myśli Ruby na JVM, ale też wydajnościowo żadna rewelacja.

Poruszony problem dotyczyl przetwarzania duzej ilosci danych, w sposob bardziej wsadowy niz przetwarzanie na potrzeby WWW. Przy duzych ilosciach danych szybkosc wykonywalna jezyka przestaje miec znaczenie (pomijam tutaj ekstremalne przypadki, kiedy liczenie trwa miesiacami) - znacznie wazniejsza jest skalowalnosc architektury przetwarzania. Latwo jest powiedziec, ze np. Hadoop jest rozwiazaniem bez sensu, bo dodaje niepotrzebna warstwe zwalniajaca przetwarzanie danych, ale jest to koszt mozliwosci przetwarzania na wielu maszynach rownoczesnie. PHP odradzam w takich zadaniach ze wzgledu na to, ze potrafi np. zaalokowac kilkaset MB RAM do przetwarzania dwunastomegowego pliku CSV, a co gorsza - nie zwalnia tej pamieci. Uzywalem PHP w dlugotrwalych zadaniach i odradzam, co oczywiscie nie znaczy, ze jest to zly jezyk.

Tak z ciekawości chciałbym się dowiedzieć na czym polega ta "szybszość" BDB w porównaniu z RDBMSami, w sensie konkretnych argumentów.
Nie ma żadnego teoretycznego powodu, aby RDBMS był wolniejszy, a jest bardzo wiele za tym, aby był szybszy. Rashid, mógłbyś wyjaśnić, co miałeś na myśli?

BDB jest szybsze, bo bazie odpada mnostwo dodatkow:
- przetwarzanie SQL
- zarzadzanie indeksami
- zarzadzanie sesjami i transakcjami
- rozbudowane operacje w pamieci
- posrednia warstwa sieciowa
- przenoszenie danych pomiedzy przestrzenia adresowa serwera bazy a programem przetwarzajacym dane

BDB bylo we wczesniejszych wersjach MySQL dostepne jako format binarny bazy (analogicznie do MyISAM czy InnoDB), co samo w sobie oznacza, ze BDB + narzut MySQL jest wolniejsze od samego BDB.

Kazdy, kto samodzielnie pisal prosta baze danych operujaca na duzej ilosci danych przechowywanej w lokalnych plikach wlasnego formatu zauwazyl, ze wydajnosc MySQL nie jest jakos specjalnie wybitna. O przydatnosci MySQL decyduje to, ze ma ona rozsadna wydajnosc i rozsadny zestaw przydatnych narzedzi (wymienionych powyzej, jako wady). Kiedy jednak zalezy nam na wydajnosci i duzej ilosci zapisow i odczytow (kosztem transakcyjnosci i wielu uzytkownikow), to istnieja znacznie bardziej atrakcyjne rozwiazania.

Oczywiscie rozmawiamy o rozwiazaniach do przetwarzania danych, a nie webowych.

Ten post edytował rashid 2.01.2009, 14:06:05