Drukowana wersja tematu

Napisany przez: kwiateusz 2.08.2008, 18:53:14

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

Napisany przez: LBO 2.08.2008, 19:01:00

Muskający powierzchnię tematu http://talen.jogger.pl/2007/12/23/duze-portale-czesc-3-metody-balansowania-ruchem-dns-i-server/ z serii http://talen.jogger.pl/2007/12/23/duze-portale-czesc-3-metody-balansowania-ruchem-dns-i-server/.

Napisany przez: wrauk 4.08.2008, 20:33:26

dzięki za link do mojego bloga, widzę, że temat ostatnio robi się coraz popularny :-)

kiedy ten temat rusza ? sam mam wkrótce zacząć pracę nad (miejmy nadzieje) dużym portalem - chętnie porównam swoje opinie i nauczę się czegoś nowego...

Napisany przez: Kocurro 5.08.2008, 11:02:55

No to Panowie zaczynajmy - może na początek odnosząc się do tego co kolega (jeśli nie masz nic przeciwko takiemu zwracaniu się) wrauk napisał na swoim blogu. Problem sesji - jak byście proponowali go rozwiązać tak by nie utracić wydajności ani nie musieć rezygnować z funkcjonalności sesji. Oczywiście zakładam tutaj sytuację posiadania x serwerów www i możliwość trafienia requestów do dowolnych z nich w szczególności możliwość trafienia dwóch różnych requestów do dwóch różnych serwerów.

Przyznam się szczerze, że nie mam jeszcze pomysłu jak to rozwiązać.

Może koledzy mają jakiś pomysł ?

Pozdrawiam,
Łukasz

ps: jaki przyjemny temat pokrywający się trochę z tematem mojej magisterki

Napisany przez: wlamywacz 5.08.2008, 12:25:49

A jest możliwość utworzenia dysku sieciowego i na nim trzymania sesji tak że każdy serwer będzie miał do niego dostęp ?

Napisany przez: Kocurro 5.08.2008, 12:37:12

Pomysł dość dobry ale wydaje mi się, że problemem będzie tutaj użycie semaforów by ograniczyć możliwość jednoczesnego dostępu do danych sesyjnych. Tak by dwa skrypty na raz z nimi nie grzebały.

Oczywiście można zrobić tak, że w sesji przechowujemy tylko informacje:
- zalogowany: tak/nie
- identyfikator użytkownika
- jakieś dane użytkownika co się rzadko zmieniają a pokazujemy jest na stronie
- adres ip (chyba, że mechanizm handlera sesji posiada zabezpieczenie przed zmianą ip)

Ja bym to zrobił tak, że robię dedykowaną maszynę sesyjną, która ma coś na wzór bazy danych - przechowuje sesje, łączysz się z nią poprzez socketa i odpytujesz. Tyle, że w tym wypadku:
- trzeba napisać soft do tej maszyny, który będzie bardzo szybki, będzie świetnie cacheował i kolejkował dane, będzie potrafił zadbać o bezpieczeństwo
- napisać moduł do php'a za pomocą którego będzie się do tego odwoływało (można oczywiście ręcznie sockety otwierać ale myślę, że moduł byłby lepszy), w szczególności moduł mógłby być non stop odpalony i mieć stałe połączenie z serwerem sesyjnym by nie tracić na wydajności.

To taki pomysł na szybko ale na ile opłacalny to nie wiem ... na pewno sporo czasu by poszło na oprogramowanie tego i czy zyski wynikające z wydajności zrekompensowałyby straty czasu poświęconego na oprogramowanie tego.

I pytanie czy nie ma prostszego rozwiązania, które także się spisze i może będzie trochę mniej wydajne ale w ostatecznym rachunku wyjdzie lepiej ?

Ten pomysł z dyskiem sieciowym byłby nawet dość dobry - tyle, że dysk musiałby być wpięty w architekturę o dużej przepustowości i sam najpewniej być RAID'em na SAS'ach.

Do tego pozostaje problem rozwiązania konkurencyjności.

pozdr.
Łukasz

Napisany przez: wrauk 5.08.2008, 12:55:10

Soft do obsługiwania takich sesji już istnieje i nazywa się http://www.mohawksoft.org/?q=node/8 - pisałem o nim na blogu.

Co do ilości danych przechowywanych w sesji, to zawsze musi to być kompromis pomiędzy tym ile można zapisać, aby maksymalnie odciążyć bazę i utrzymać sesje na
zadowalającym poziomie. Można się np.: zastanowić nad zapamiętywaniem części danych w sesji, a dopiero garbage collector zapisywał by dane do bazy.

Na szczęście sesjami bardzo dobrze się balansuje i rozwiązanie oparte o bazę danych może być bardzo wydajne. Wystarczy wziąć dwie pierwsze litery z hasha i obliczyć modulo z liczy dostępnych serwerów. Dzięki temu zapytanie o sesję zawsze trafi do konkretnego serwera - zawsze tego samego. Skalowalność takiego rozwiązania rozbije się dopiero o maksymalną liczbę jednoczesnych połączeń, ale to można tylko załatwić przez kierowanie danego użytkownika do tego samego serwera www (lub tej samej grupy serwerów), np.: na podstawie adresu IP.

Napisany przez: Sedziwoj 5.08.2008, 13:41:27

Ten akurat pomysł jest niezbyt dobry moim zdaniem, zapis danych powinien być natychmiastowy, co innego gromadzenie informacji w sesji, zamiast pobierania z bazy. Jak na tym forum jest np. nick i id, tylko kłopot pojawia się jak te dane mogą się zmienić, ale to da się też zrobić. Chyba było o tym coś na blogu technicznym Grona, odnoście buforowania wygenerowanych stron (co prawda przykłady były w Python).

Napisany przez: wlamywacz 5.08.2008, 21:09:04

Przecież jeden user to jedna sesja tym samym jeden user może się znajdować na jednym serwerze i tylko ten jeden serwer może te dane modyfikować czyż nie tak ?

Napisany przez: mike 5.08.2008, 21:18:30

No właśnie nie.
Podczas jednego żądania użytkownik może zostać obsłużony przez jeden serwera a podczas kolejnego przez drugi, przecież pomiędzy żądaniami (w obrębie jednej sesji) obciążenie serwerów może się zmienić.

Napisany przez: wrauk 5.08.2008, 21:22:56

Nie nie nie, nic bardziej błędnego. Żyjemy w czasach w których "praca z ajaxem jest czystym relaxem" i witryna która jego nie wykrozystuje nie jest trendy (trendy jest już passe, teraz edgy jest trendy). W każdym razie nigdy nie można założyć, że tylko jeden skrypt pracuje na sesji. I dla tego też warto robić session_close zaraz po pobraniu danych z sesji (o ile nie ma potrzeby modyfikacji danych sesji), bo standardowo (sesja na plikach) PHP zwalnia sesję dopiero po wykonaniu skryptu, co powoduje, że zapytania ajax'owe wykonywane teoretycznie równolegle tak naprawdę są wykonywane szeregowo (do dodatkowo rzutuje na większe obciążenie serwera przez połączenia które 'wiszą' i czekają w kolejce).

Napisany przez: jarek_bolo 5.08.2008, 22:08:59

Witam, specjalnie doświadczony nie jestem, ale tak myśląc nad tym problemem wyszło mi co nie co, nie wiem, może to głupie, ale może ktoś lepsiejszy i bardziej doświadczony podchwyci myśl, albo spojrzy na problem podobnie do mnie.

Otóż, przy pierwszym wejściu na stronę jest to nie ważne na jaki serwer trafimy, i z reguły trafiamy na najmniej obciążony zgodnie z algorytmem loadbalancingu. Następne wejścia jednak powinny już trafić do tego pierwszego serwera.
Skoro serwery się zmieniają losowo to jedynym sposobem na zachowanie informacji który serwer był pierwszy jest... ciastko na maszynie klienta z jakimś id, po którym aplikacja na każdym z serwerów rozpozna ten pierwszy serwer i na niego przekieruje żądanie?
Mankament to userzy nie akceptujący ciastek, ale wtedy może jakaś zmienna doklejana do url'a ?

Decyzje o przekierowaniu podejmuje najmniej obciążony serwer, więc OK.

Podobne to chyba do rozwiązań z wspólną DB, gdzie była by tabela z polem w którym jest hash z jakichś stałych parametrów klienta (IP, przeglądarka, OS, ?) i znowu aplikacja na samym wstępie zawsze musiała by sprawdzać czy taki hash już istnieje i jeśli tak to odczytać serwer dla niego i tam przekierować.

Pytanie tylko czy takie sprawdzania i przekierowania same w sobie nie są już wystarczająco wolne ?

No i w sumie to nie wiem jak miała by wyglądać implementacja takiego przekierowania w PHP (tutaj się objawia mój brak doświadczenia) :/
Bo tak, jak mamy żądanie, jakiś URL, trafiamy z nim do aplikacji na jakiś serwer. Wykonuje się skrypt PHP i jak z tego skryptu PHP przekierować... pod ten sam URL na inną maszynę tylko (DNSy, IP, wykorzystanie exec()?)
Może na zasadzie, że każdy z tych kilku serwerów ma swoją subdomenę skonfigurowaną tak samo jak jedna główna domena i wtedy aplikacja przekierowywała by za pomocą subdomen, a żądanie jak już by trafiło na serwer to za pomocą mod_rewrite było by przepisywane na główną domenę?

No nic, tak czy siak według mnie najlepszym miejscem na przechowanie informacji co do pierwszego serwera jest klient (bądź jego stałe dane), bo to klient jest stały, a serwery się zmieniają.

Napisany przez: wrauk 6.08.2008, 07:56:52

Zaawansowane load balancery za dużo $$$ mają takie możliwości.


Wydaje mi się, że podstawowe założenie jest błędne, bo zakładasz, że każdy request dotrze do PHP, co nie jest prawdą. Podstawą zmiejszania obciążenia serwerów jest cache i duże wartości dla nagłówków Expires. No i, tak jak wspomniałeś, pojawia się duży problem z ruchem wewnętrznym (bo przekierowanie header-location powoduje, że znowu pakiety przejdą przez load balancer, co może oznaczać, że potrzebujemy 100 requestów, żeby trafić na właściwy serwer :-) ).

Napisany przez: jarek_bolo 6.08.2008, 08:51:23

Tak, wczoraj przed snem wziąłem się za lekturę Twoich wpisów na blogu, dobrnołem do części 3 i zaraz jadę dalej
Żałuję, że udzieliłem się w tym wątku przed przeczytaniem


Innymi requestami jak PHPowe to chyba nie trzeba się tak przejmować ? Wszak request o statyczny zasób, grafikę nie uruchamia całej logiki PHP dającej narzut parsera PHP i z reguły narzut łączenia się z bazą i mielenia przez nią. Nie mniej oczywiście, że skoro są narzędzia to lepiej je wykorzystać i tak chyba w jednym z Twoich wpisów jest link do podstawowej konfiguracji mod_cache Apacha, ciekawe to ciekawe.

A jeśli chodzi o ruch wewnętrzny to napisałem, że header-locatiowanie miało by operować na subdomenach, które były by unikalne dla każdego z serwerów, a mod_rewrite docelowego serwera spowrotem przepisywał by na główną domenę. A więc load balancer musiał by reagować tylko przy requeście z główną domeną, a requesty subdomenowe wymuszone przez przekierowanie header-location powinny już trafiać zgodnie z adresem, bez load balancowania.
Ale z racji swojego małego doświadczenia nie wiem czy tak się da i może głupoty piszę

Napisany przez: Kocurro 6.08.2008, 09:18:14

jarek_bolo: niestety Twój pomysł byłby o wiele mniej wydajny niż chociażby składowanie sesji w bazie danych z ręcznym mechanizmem blokowania.

Problemem jest to, że jeśli dasz header location to on wraca do przeglądarki i ona robi ponowny request - więc idzie przez load balancer.
Jeśli nawet dasz request wewnętrznie za pomocą na przykład curla to odpowiedź na zapytanie spowodowuje przynajmniej dwukrotnie większy ruch.

pozdr.
Łukasz

Napisany przez: wrauk 6.08.2008, 09:45:00

Hmm... raz to oczywiście podwójny ruch, dwa to... widziałeś kiedyś, w swoim pasku adresu, takie domeny: s123.google.pl, s345.nasza-klasa.pl, albo s333.youtube.com ?
:-)

Napisany przez: wlamywacz 6.08.2008, 10:13:25

A co z adresami typu www2.cos.pl ?

Napisany przez: Kocurro 6.08.2008, 10:18:46

Widziałem ale jeśli mam być szczery to to jest rozwiązanie słabe.

Załóżmy, że na każdy serwer (a mamy ich powiedzmy 10 sztuk) trafi po 50 użytkowników. Może się zdarzyć, że na jeden serwer trafią użytkownicy co będą odświeżać stronę raz na 5 minut (bo czytają w tym czasie regulamim, forum, cokolwiek) ale może się też tak zdarzyć, że na jeden serwer trafią użytkownicy co będą mieli odświeżenie co 10 sekund (bo na przykład wysyłają ataki w grze).

I właśnie w grach widziałem to rozwiązanie i ono było za słabe. Prizee.com z tego korzystało (i chyba jeszcze korzysta) ale już pracują nad przebudową infrastruktury.

Statyczne (przy pierwszym żądaniu w ramach sesji) przypisanie użytkownika do serwera jest najprostszym i na mój gust najgorszym rozwiązaniem.

pozdr.
Łukasz

Napisany przez: wlamywacz 6.08.2008, 11:38:17

Ale jak działa to
www2.cos.pl itd. bo nawet nie wiem jak o to google zapytać.

Napisany przez: Kocurro 6.08.2008, 11:41:48

Normalnie Serwer ma taką nazwę, dns wskazuje na jego IP. Tak jak każdy inny serwer

Nie rozumiem pytania

pozdr.
Łukasz

Napisany przez: mike 6.08.2008, 11:47:12

Tak samo jak www.cos.pl
Ty tylko nazwa :-)

Napisany przez: normanos 6.08.2008, 13:48:56

a mnie ciekawiły by rady w jakim kierunku iść kiedy osobny dedyk z MySqlem to już za mało? Jedna maszyna jest z serwisem, 2 są "kontentowe", trzecia jest z mysqlem. Oczywiście dalej zakładając rozwiązania niskobudżetowe na poziomie małej firmy, a nie korporacji.

Napisany przez: grzegory 7.08.2008, 21:36:06

Przyłączam się do tematu.

Mój problem wygląda następująco.
Serwis stoi na koncie hostingowym Active w nazwa.pl
Na nazwa.pl stoi serwis, czyli wszystkie pliki php.
Aby odciążyć serwer glowny, grafika została przerzucona na inny.
W tej chwili główny serwis generuje 2GB transferu dziennie, ten dodatkowy chyba 4GB.

Nazwa ma ograniczenie - 40 osób jednoczesnie na stronie. U mnie licznik liczący wg id sesji - wskazuje w tej chwili 200 osób online.
Strona robi 1,5mln odsłon miesięcznie.

Oczywiście cache jest - smartowski.
Jestem w trakcie przygotowania nowej wersji serwisu - bardziej zoptymalizowanej, mniej wycięczonej zmianami które zaszły w niej w ciagu ostatnich 4 lat. Jednak wiem, że to nie pomoże.

Pytanie - co z tym zrobić.
Grafika i zdjęcia są już ciągnięte z innego serwera (superhost.pl). Baze mógłbym dać również na innym, jednak ona nie robi problemów.
Jest jakiś sposób na rozłożenie ruchu na kilka kont hostingowych?
Rozwiązanie musi być bardzo niskobudzetowe.

Napisany przez: wlamywacz 7.08.2008, 21:50:20

Kup serwer dedykowany, da radę bez problemu. Patrz ovh

Napisany przez: Sedziwoj 7.08.2008, 21:56:20

@grzegory
Zacznę od tego że to raczej nie jest temat (całe pod forum) jak sobie poradzić z problemem, a dyskusją nad pewnymi.
Co do Twojego problemu, "niskobudzetowe" to dla mnie coś jest nie tak, bo jak masz taką odwiedzialność, to powinny iść za tym odpowiednie środki.

Napisany przez: wrauk 8.08.2008, 09:47:21

Kiedy osobny dedyk z bazą to za mało kupujesz drugi dedyk i możesz zrobić trzy rzeczy:
- rozdzielić logicznie bazę, tak, aby serwis działał na dwóch niezaleznych bazach,
- master-slave
- cluster

No i oczywiście możesz się pobawić w optymalizację, czyli:
- cache zapytań do bazy,
- tuning konfiguracji mysql'a (my.cnf),
- tuning struktury bazy (przejżeć slow query log).


Poczytaj sobie: http://prawo.vagla.pl/node/8027

Napisany przez: normanos 8.08.2008, 09:57:13

Znam te hasła ale literatury ciągle za mało. Niestety nie mam z Mysql aż tak dużego doświadczenia. Googlam dalej


to chyba oczywiste i tu nie ma o czym rozmawiać. co było do zrobienia to zostało już zrobione na poprzednich serwerach (optymalizacja, cache, memcached, lighttpd/nginx etc.)

Napisany przez: wrauk 8.08.2008, 10:35:20

Sorki za kryproreklamę, ale może tutaj znajdziesz linki których szukasz :-)

http://talen.jogger.pl/2008/03/16/duze-portale-czesc-6b-bazy-danych-topologia-serwerow/

Napisany przez: Ace 12.08.2008, 11:03:43

Od kilku miesięcy interesuje się tematyką wysokich obciążeń, dużej dostępności...

Polecam jedne link http://highscalability.com/

np:
http://highscalability.com/linkedin-architecture-0
http://highscalability.com/ebay-architecture
http://highscalability.com/37signals-architecture

Napisany przez: rashid 27.11.2008, 12:27:56

Pozwole sie wtracic, bo Panowie proboja rozwiazac problemy, ktore stosunkowo dobrze sa opisane w literaturze zagranicznej, ktora chyba nie wszystkim jest znana.

Po pierwsze zalozenie, ze ruch jest wysylany jest do najmniej obciazonego serwera jest niezbyt wydajne, bo do load balancingu dochodzi wtedy potrzeba monitorowania wydajnosci. Znacznie prosciej jest zastosowac load balancing metoda round-robin (czyli po kolei kazdy serwer) lub przyklejac uzytkownikow do poszczegolnych maszyn i zakladac, ze statystycznie rozlozy sie to ladnie.

Pomysly oparte o wspoldzielone dyski sprawdzaja sie tylko w ograniczonym zakresie. Ze szczegolna rezerwa nalezy podchodzic do propozycji oferujacych liniowa skalowalnosc na architekturach SAN - wg. naszej opinii nie nadaja one sie operacji charakterystycznych dla srodowiska webowego - czyli malych plikow o duzej liczbie dostepow. Skalowalnosc odczytu mozesz miec liniowa tylko przy zalozeniu, ze tworzysz za kazdym razem kopie obiektu na nowym dysku.

Sesje najprosciej jest przechowywac lokalnie, na pojedynczej maszynie. Wszelkie pomysly z trzymaniem sesji w bazie, czy wykorzystaniem memcached, beda juz powodowac komplikacje. Wiekszosc serwerow proxy dzialajacych jako akceleratory WWW pozwala "przykleic" sesje uzytkownika do pojedynczej maszyny.

Powaznym problemem jest synchronizacja plikow miedzy serwerami, szczegolnie takich, ktore uploaduja uzytkownicy systemu.

Zanim zacznie sie analizowac mozliwosci load balancingu powinno sie wykonac pewna prace u podstaw - skonfigurowanie aplikacji i serwerow WWW w taki sposob, by pliki statyczne wykorzystywaly efektywnie cache przegladarek internetowych. Robi to gigantyczna roznice i przydaje sie bardzo przy nastepnym kroku - dodaniu akceleratora WWW przed pozostalym srodowiskiem webowych do przezroczystego serwowania plikow statycznych. Taka konstrukcja ma ta zalete, ze kolejne akceleratory mozna dodawac rownolegle i skorzystac z DNS round-robin do load balancingu ruchu statycznego.

Zastanowcie sie w jakim stopniu mozecie wyjac statyczny kontent poza wasza infrastrukture. Z pomoca Amazon S3 i Cloud Front mozna osiagnac niskim kosztem swietne rezultaty. Czasami tez latwo osiagnac znaczaca poprawe wykonujac zwykle profilowanie aplikacji i wylapujac waskie gardla.

Nie skaluj, dopoki to nie jest potrzebne. Jesli masz mozliwosc, to sprawdz czy nie oplaca sie bardziej zwiekszyc mocy maszyny.

@normanos - jesli wydajnosc pojedynczej maszyny bazodanowej nie jest wystarczajaca do uciagniecia ruchu, to nalezy przyjrzec sie strukturze bazy danych i rozwazyc wydobycie czesci tabel do osobnej bazy. Oczywiscie jest to znacznie utrudnione w przypadku gestej sieci powiazan miedzy tabelami i wlasnie przez to mozna zaryzykowac twierdzenie, ze JOINy sie nie skaluja. Czesciowo mozna tez zaryzykowac wybranie jednej maszyny na zapisy (master) i kilku wylacznie do odczytow (slave). Zwroc tez uwage, ze istnieja alternatywy do relacyjnych baz danych, ktore znacznie lepiej sie skaluja. Byc moze trzeba przyjrzec sie modelowi w aplikacji i go przebudowac pod katem skalowalnosci.

Napisany przez: Krolik 2.12.2008, 10:37:42

Jeśli baza danych się nie wyrabia i używamy MySQL/PostgreSQL, to mamy przerąbane. IMHO, jeśli proste rozwiązania takie jak dołożenie brakujących indeksów, poprawa zapytań i sensowne buforowanie nie poskutkują, rozważałbym najpierw zmiane silnika na coś komercyjnego, co ma solidne możliwości partycjonowania, replikacji no i ma porządny optymalizator zapytań. Opensourcowe bazy danych nie spełniają tych wymagań.

Co do przyklejania sesji do jednej maszyny, to może wydajnościowo dobry pomysł, ale nie można tego nazwać HA. Bo jak serwer się rypnie, to użytkownicy stracą sesje - b. nieładnie. Hmm, nie wiem, jakie komplikacje mogą być z replikacją sesji, my nie mieliśmy żadnych (fakt, jedziemy na J2EE, a nie PHP, ale to chyba nie robi różnicy?).

BTW: Jakie inne możliwości się lepiej skaluja niż relacyjne bazy danych? XMLowe? Obiektowe? Płaskie pliki? Relacyjne bazy danych się bardzo dobrze skalują. To że FOSS "nie umią" to nie znaczy, że to wina modelu relacyjnego.

Napisany przez: rashid 11.12.2008, 11:10:50

Nie zgadzam sie. To, ze Oracle przychodzi w paczce z narzedziami nie znaczy, ze jest lepszy. Podobne narzedzia sa do baz open source, tylko trzeba ich poszukac. Jednoczesnie przyznaje, ze narzedzia takie zwykle pojawiaja sie najpierw w rozwiazaniach komercyjnych, a dopiero potem migruja do open source.



Z kazda replikacja sa problemy, byc moze po prostu nie dotarliscie jeszcze do limitow, w ktorych sie one pojawiaja. HA i Load Balancing to dwie zupelnie odrebne rzeczy - ten watek mial byc o LB



http://en.wikipedia.org/wiki/SimpleDB
http://labs.google.com/papers/bigtable.html

Znormalizowana relacyjna baza danych sie skaluje slabo, niezaleznie od rodzaju oprogramowania. Przykladem niech bedzie eBay, ktory dziala na MSSQL i jednak skalowalnosc z relacjami im nie wyszla. Dlatego poszli w sharding, czyli w praktyce tworzenie plaskich nieznormalizowanych tabel i rozdzielanie ich na wiele serwerow.

Napisany przez: klakson 20.12.2008, 13:05:29

Witam serdecznie,

chcialbym wykonac aplikacje w php, z dosc duza iloscia uniklanych userow w tym samym czasie, np 50 tys, ktorzy pobieraliby i wysylali z/do serwera mala porcje danych, czyli bylaby duza dynamika zmiany danych w tym samym czasie. Calosc danych max do 150 tys rekordow, 10 kolumn - w kazdym polu np 500 bajtow.
I teraz mam pytania:

- gdzie moge poczytac o takich rozwiazaniach w php, co zastosowac (moduly, biblioteki), jak to sie je?, aby raz (zalozmy na 5 minut) zaladowac do pamieci biezace dane ok 700MB, a logike przy kazdym (re)starcie. Dane na dysku bede gromadzil w kilkudziesieciu plikach txt,
a nie w bazie danych.
Oczywiscie wszystkie inne porady i wskazowki od doswiadczonych programistow chetnie przyjme. Jesli chodzi o optymalizacje dostepu do wszystkich danych, pociecie na tablice, sprawdzanie zlozonosci obliczeniowej, wydajnosci... to juz sam bede sobie radzil.

- i jeszcze jedno - praktyka, czy w przypadku niezawodnego, optymalnego oprogramowania, taki RPS: http://www.ovh.pl/prywatne/produkty/rps3.xml bedzie w stanie mi to ucjagnac? A jesli nie, czy rozwiazanie zrownoleglic (np na 2 RPSy), czy innego, silniejszego dedyka wziac na początek? Nie mam pojecia jak to w praktyce wyglada, wiec prosze o opinie osob doswiadczonych w boju. Chce aby mi to wyszlo jak najtaniej, przy dobrym np 100MB łączu..... a szczegolnie musze to najtaniej przetestowac przy realnym obciazeniu.

Bede wdzieczny za wszelkie odpowiedzi, namiary na materialy... musze jakos wystartowac, poczytac...., bo na teraz nie mam bogatego doswiadczenia w praktycznym programowaniu, znam jednie teorie algorytmow i szacowanie zlozonosci obliczeniowej.

Napisany przez: normanos 20.12.2008, 13:47:49

piszesz, że będziesz mielił dane z dysku a potem wybierasz RPS, to jakby się wyklucza.

Napisany przez: rashid 20.12.2008, 14:11:47

50tys. jednoczesnych uzytkownikow i kilkadziesiat plikow txt? Wychodzi na to, ze mozesz miec tysiac uzytkownikow korzystajacych z kazdego z tych plikow jednoczesnie - to jest nierealizowalne w praktyce. Wlasnie po to korzysta sie z baz danych, ktore kolejkuja polecenia.

Zwroc jednak uwage, ze bazy danych SQL zwykle kiepsko radza sobie z duza liczba modyfikacji/nowych wierszy/usuniec, wiec warto rozwazyc alternatywy. Jesli jestes w stanie okreslic maksymalna liczbe rekordow i liczbe danych w kazdym rekordzie, to najszybszym rozwiazaniem bedzie chyba skorzystanie z BerkeleyDB (BDB). Jest to bardzo szybka baza danych oparta na plikach. Predkosc takiego rozwiazania bywa o rzedy wielkosci wyzsza od tradycyjnych baz SQL w niektorych zastosowaniach.

Napisany przez: klakson 20.12.2008, 16:37:27

Dzieki za pierwsze odpowiedzi, i juz uscislam, bo zbyt malo wyjasnilem......
W ogole na poczatku powiem, ze (wstępnie tylko) rozwiazanie dopasowalem do ceny.

Sytuacja bedzie taka, ze bedzie np 50 katalogow, w kazdym katalogu po 1k plikow - 1 plik na uzytkownika. Nie przemyslalem tego jeszcze dokladnie, bo moze bede wykorzystywal jeden plik na kilku lub wiecej uzytkownikow, to bede chcial optymalizowac, ale chyba to nie mam teraz znaczenia.
Dalej.... w danej chwili np 15% (i raczej wiecej nigdy nie bedzie) wszystkich uzytkownikow wysle porcje danych, kazdy do swojego pliku, czyli bedzie to dodanie, modyfikacja lub usunicie rekordu w pliku uzytkownika. I teraz, np co 5 minut bedzie wykonywana procedura scalania wszystkich plikow do jednego pliku, pobranie ich i przetorzenie przez logike na podstawie konkretnych filtrow/kryteriow oraz cięcie danych na kilkadziesiat plikow xml, ktore trzeba zaladowac do pamieci na 5 minut, bo na nich beda wykonywan czeste i rozne operacje prawie przez wszystkich uzytkownikow, wiec musi to mi siedziec w pamieci przez te np 5 minut i dzialac bardzo szybko (wiec baza danych tu odpada). Dlaczego kilkadziesiat plikow? bo beda to juz wtedy niezalezne od siebie dane, czyli np 70 tablic po 10MB, z czaem moga jednak dojsc do tego relacje miedzy tymi tablicami (jeszcze tego nie wiem, ale to juz nie jest tu istotne). Aha, ilosc danych wiadomo ze bedzie sie zmieniac co te 5 minut, np raz 70 plikow po 3MB, pozniej 70 plikow po 5MB itd, łącznie jednak nie wiecej niz około 700MB. Mozna wiec chyba przyjac jakis jeden bufor pamieci ram i zallokowac na te 70 tablic max 700MB.

A teraz jesli chodzi o RPSa, on jest punktem kluczowym, bo po pierwsze cena, po drugie cena, ktora implikuje rownie: 1)łącze, 2)wydajnosc procesora oraz 3)ramu. Po przegladnieciu ofert..... wybralem wlasnie RPSa III OVH, wiedzac dobrze ze ISCSI/NFS ma slaba wydajnosc, wiec baza mi tego nie uciagnie, tak wiec w tej cenie, z tym procesorem i ramem i przy braku limitu transferu na łaczu 100MB (co bardzo wazne) wlasnie ten RPS mi najbardziej pasuje do mojej koncepcji z ładowniem danych i logiki do pamieci. Dodam, ze do realizacji chce wykorzystac albo modlu apacha xslt albo php'owy procesor xslt.
A wazne jest tez, ze mysle o serwerze zapasowym, takim samym RPSie, gotowym od razu przejąć pracę, gdy pierwszy RPS sie wysypie.

Jesli w czyms sie bardzo myle, albo cos waznego pomijam, to prosze mi o tym powiedziec.
Dodam tylko, ze jesli mi to wszystko zagra i cos zaczne zarabiac, to jasne jest ze zaczne myslec o inwestycji, aby zrobic to lepiej, bezpieczniej, wydajniej. Na razie moge wydawac miesiecznie jedynie okolo 100 PLN.

Poczytam o BerkeleyDB, bo musze widziec w ogole czy to jest za free.

Dzieki za uwagi i prosze o wiecej
Przy okazji zycze wszelkiego dobra z okazji Swiat Bozego Narodzenia i Nowego 2009 Roku!

Napisany przez: Kocurro 20.12.2008, 16:59:28

Wybaczcie offtopic ale nie mogę.

Kolega się z choinki urwał na bardzo niewydajnym serwerze chce zrobić coś co wytrzyma duży ruch. Chce płacić prawie 100 pln za bardzo wolny dysk 10 GB ... a szkoda mu już zainwestować prawie 200 pln za szybki dysk 500 GB w wersji bezpiecznej bądź też 1 TB w wersji szybkiej. Do tego pamięci tyle samo ale w tej droższej ofercie szybszy procesor.

Ale najlepszy ubaw jest taki, że ten kolega chce wolny dysk po to by udostępnić serwis, który ... uwaga ... będzie odczytywał dużo z dysku

Aha - nie doczytał kolega jak należy ... te 100 Mbps ma najniższy priorytet ... co za tym idzie - jeśli będzie wolno to wykorzysta tyle ... chociaż nie nie wykorzysta ... bo z moich testów RPS III wytrzymywał nie więcej niż 20 Mbps ... za to ten co ja mówię testowałem i wytrzymał spokojnie 60 Mbps.

Ale to nie koniec - kolega ten planuje na dysku sieciowym robić od groma operacji zapisu Ci co się znają na architekturze a tym bardziej korzystali z opcji RPS wiedzą jak to będzie chodzić (dla ułatwienia dodam, że jak dawna wersja pewnego serwisu pozwalającego odnaleźć znajomych ze szkolnych lat).

Drogi kolego - wybacz, że tak po Tobie jeżdżę ... ale tylko w ten sposób mam możliwość zmusić Cię do przemyślenia swojego pomysłu. A gdy już go przemyślisz i zauważysz, że Twoje rozwiązanie naciągnie Cię na koszty to przelicz na jakie i tą sumę co byś stracił wpłać proszę na dowolne konto charytatywne.

Napisany przez: klakson 20.12.2008, 18:52:22

No ok Kocurro,

ale moze po pierwsze, to przeczytaj moj pierwszy post, w ktorym prosilem o pomoc, bo jak napisalem, nie mam duzgo doswiadczenia z programowaniem webowym i hostingiem,
ledwo co postawilem kilka malych serwisow, na shared hostingu typu dreamhost, lypha, servage... raczej jako forme nauki i doraznego zarobku, wiec trudno jest (instalujac gotowe forum, sklep, cms, podpinajac templatki itp), zanc tez i sie dobrze orietnowac w faktycznych paramtrach oferowanych w hostingu dedykowanym. Z wypowiedzi przeczytanych na roznych forach, dowiedzialem sie ze parametry rps'ow ovh (a szczegolnie transfer) nie sa wcale tak kiepskie jak Ty przedstawiasz.

A przechodzac do sedna, w czym niby jest problem, aby to, co pisalem o zapisie i odczycie danych dla uzytkownikow, wykonywac tak samo w ramie?, a co 10 minut zrzucac na dysk w kilku duzych plikach? Wtedy wszystko bedzie mozna zrobic dynamicznie, a co jakis sensowny czas odkladac w duzych porcjach na dysk jako xml'e (backup na shared sobie zrobie). Wtedy tylko jest pytanie, czy na system i aplikacje ze wszystkimi danymi starczy mi 2gb ramu (na poczatek na pewno). Wtedy spokojnie dysk 10 GB mi wystarczy, oraz nie musi byc on bardzo szybki.

A teraz kwestia kasy, ja mam wydac conajmniej 200, 300 PLN plus kolejna kasa za serwer zapasowy (a nie wiadomo czy niedlugo nie bedzie limitow na transfer, jak na forach piszą)? Czy Ty to policzyles? Jak sie to ma do 100 PLN x 2? Moge tak zrobic jak piszesz, chyba ze Ty mi za to zaplacisz i zaplacisz mi tez za stancje i za studia ktore ledwo podjalem.... albo jak mi dasz lepsza prace, za wieksza kase.

Moge powiedziec, ze to nie bedzie serwis dostepny dla kazdego z sieci, typu nasza klasa, czy fotka, aby na reklamach zarabiac..., to bedzie baza ofert pewnej branzy, ktora łączy max do 50 tys firm w Polsce (w jednej z nich pracuje), wiec ruch generowany bedzie (tylko w godz 8-16 przez autoryzoanych urzytkownikow) i bedzie to czysty tekst (dane i troche tagow html).

A wracajac do pytania z pierwszego mojego postu, prosze o pomoc, czego mam sie uchwycic, co poczytac, aby sie dowiedziec na temat rozwiazan, funkcji, bibliotek modlulow php, ktore realizuja ladowanie na stale do pamieci skryptow z logika i danych.

Napisany przez: rashid 20.12.2008, 18:53:32

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?

Napisany przez: Kocurro 20.12.2008, 19:40:32

Szanowny kolego klakson - proponuje najpierw zapoznać się z prawdę na temat rozliczania transferu. A dopiero potem chcieć sponsoringu. Na forach piszą dużo i nie zawsze prawdę.

Odnośnie rozliczenia transferu masz cztery możliwe opcje i zależnie od tego co wybierzesz masz limity. Limity te dotyczą tak samo zwykłych serwerów dedykowanych jak i serwerów RPS. Przy tych drugich o tym nie piszą ponieważ uzyskanie w ciągu miesiąca transferu danych na poziomie 5 TB jest bardzo trudne.

Pozdrawiam

ps: jeśli chcesz przechowywać dane w pamięci to no cóż rispect - czeka Cię sporo roboty, która przy PHP będzie bardzo trudna

Napisany przez: erix 20.12.2008, 20:06:03

A wierzysz, że Ci wystarczy pamięci? A jak w międzyczasie serwer się zresetuje z pewnych powodów (soft/sprzęt/skrypt) i stracisz ciągłość danych? Pamięć może być tylko DODATKOWO, jako cache, ale nie jako miejsce do zapisu. Skoro porywasz się na większe obciążenie, nie oszczędzaj - dostaniesz bardzo mocno po głowie i będziesz miał problemy, jakich ongiś doświadczała NK.


APC, eAccelerator, Zend Optimizer, shmop...


No wybacz, ale skoro podejmujesz się takiego zadania, to chyba wiesz, co Cię czeka... A uwierz - jak teraz będziesz oszczędzał na serwerze i strona będzie tak obciążona, jak przewidujesz, to czekają Cię naprawdę duże problemy - od resetów po różnego rodzaju wycieki pamięci/przeciążenia...

Nie da się zrobić ze złotówki pięć...

Napisany przez: wlamywacz 25.12.2008, 10:52:03

Założenia projektu sobie niezbyt realne. Kolega nawet nie ma podstawowe wiedzy na temat aplikacji sieciowych. Proszę liczyć się z kosztami których suma ma 4 liczby a nie 3

Napisany przez: djhors 29.12.2008, 11:07:55

Witam Wszystkich.

Z braku czasu niezagladam tu za wiele bo nie mam nawet na to czasu ale trafiłem na ten temat. Pozwolcie że napisze wam jak wygląda sprawa teoretycznie ze strony 'korporacyjnej' tegoz problemu. - teoria

Powiedzmy że mamy swoja strone php/mysql i pliki. Podzielimy to oczywiście na:

1. Baza danych MySQL
2. Baza plików aplikacji (Core Aplication)
3. Pliki storage (Multimedia itp.)

Sytuacje jakie tu piszecie maja zastosowanie przy tzw. uzytkowaniu lokalnemu. Oczywiście sprawdza się tutaj Load Balancing. Prawda praktyczna jest taka że jesli liczymy uzytkowników w milionach SLB mozna wyrzucić do kosza ze względu że sam serwer SLB by tego nie wytrzymał. Analiza ruchu i obiażenia tez potrzebuje zasobów i czasu. Serwery Google, YouTube itp. stosuja własne techniki rozdziału swoich aplikacji mniej lub bardziej skuteczne. Napomkne jednak że cały czas mówimy o użytkowaniu lokalnym. Inny motyw jest gdy mamy kilka milionów uzytkowników w Europie i nastepne kilka w Azji Wschodniej. Choćbyśmy posiadali łącza kilku Giga bitowe to i tak wartośc transferowa spada i to powaznie do 20-10%. Po ostatnim zerwaniu lini na dnie morza śródziemnego miało swoje przykre konsekwencje dla wielu wznoszących się portali ogólnoświatowych lub kontynentalnych. A i interes w tym mają pewne korporacje... mniejsza z tym.

Przy uzytkowaniu lokalnym, sprawdza się dobrze SLB jednak jak już wspomniałem (np. w przypadku naszej-klasy) miało to później nie miłe konsekwencje dla użytkowników o czym rozpisywały się nawet gazety.

Na pierwszy rzut oka roziwazaniem staja się osobne serwer na bazę MYSQL - osobny na Core Aplication i osobny na Storage. Do parunastu tysięcy użytkowników lokalnych jest oki. Póxniej zaczynają się schody poniewaz jest to mało opłacalne przy próbie tworzenia mirrorów na każdy punkt z osobna. Dlatego tez najpraktyczniejszym rozwiązaniem jest tworznie całego mirrory jednego serwera ze wszystkimi punktami 1,2,3. WIelu twierdzi że ta metoda jest przestarzała zapoczatkowana przez mirrory serwerów użytkowanych przez dystrybutorów Linuxów itp. ale ma to pewne zalety. Otóz w ten sposób serwer bedzie sie najszybciej komunikował z własnymi punktami PHP <-> SQL. No to chyba zrozumiałe.

Prawda jest tak że nie poto sa od niedawna takie zawody jak 'Network Analist' żeby koles liczyl sobie bajty na ekranie. Wiąże się to z analizą np. rozkładu uzytkowników na pewne grupy. A najprostrza grupą podziałową jest obszar geograficzny.

W sytuacji gdy nasz serwer nie radzi sobie z ilościa uzytkowników wpada taki Analityk i tworzy nam raport gdzie mozna by umiejscowić nowy serwer lustrzany tak aby odciążyć ten co mamy a jednoczesnie objąć taka ilośc użytkowników żeby sam nie stał bezczynnie.

Dla początkujących tworzenie serwera lustrzanego może polegac na zasadzie Copy-Paste - napisania odpowiednich skryptów które będą automatytcznie monitorowały stan plików 'wzorcowych' i samej bazy i aktualizowały automatycznie serwery lustrane. Ze strony bazy danych i Storage dział to te·z wdruga stronę. Dobrze jest też aby taki wzorcowy serwer dobrze jakby był osobna jednostką serwerową (ale nie developerską - tzn nie miejscem gdzie piszemy nasza aplikacje). Dobrze by było aby nasz serwer lustrzany znajdował się w obrębie danego obszaru geograficznego aby połączenia były jak najkrótsze.

Przy zasięgu globalnym to jednak nie wypali. Powiedzmy że użytkownik X z Ameryki zarejestrował się na serwerze który tam się znajduje i użytkownik Y z Polski który będzie minutę póżniej szukał swojego przyjaciela z Ameryki zapewne się rozczaruje bo system aktualizacji będzie potrzebował trochę czasu aby zauktalizowac wszystkie serwery lustrzane (a konkretnie ten Polski). Wiele firm praktycznie olewa ta sprawe bo nie chca wydawać pieniędzy na nowych lub douczanie aktualnych programistów o wiedże z zakresu modelowania rozproszonego baz danyn a czesto początkujące firmy internetowe nie inwestuja w dobrych Senior Programmers - co jest zrozumiałe.

Więc cała sprawa zmierza tak na prawde do tego jak piszemy nasza aplikację. Poczatkujacy programisci a i nawet Ci z duzym stażem nie biora pod uwagę czegoś takiego jak zasięg aplikacji. To pozwala nam w pewien sposób zobaczyć pewna subtelna różnice między 10 letnim programistą freelance i w małej firmie. A programistą z tym samym stażem w większej firmie czy korporacji - nie bez powodu w CV czytaja informacje o poprzednich pracach i wypytuja o nie. Dzisiaj dobre referencje z 'Dobrej' firmy to prawdziwy skarb. Dlatego tez taka rada poza tematem - nie ma zadnego sensu obsypywaniem potencjalnego pracodawcy workiem portfolio z tysiaca i jednej strony dla sklepó, gier i innych temu podobnych - no chyba że startujecie na Designera.

Ale wracając do tematu, do naszego przypadku zastosowanie baz rosproszonych jest naszym roziazaniem. Taki moze ciągły przykład. Kiedy uzytkownik X z Ameryki się u nas zarejestruje - informacje na jego temat zostana zapisane na naszym serwerze lokalnym i wyśle prosty index do innych serwerów na całym świecie (często przez serwery posredniczace np. na dany kontynent). Metoda ta pozwala w 'dość' szybki sposób zaktualizować dane na całym świecie. A 'index. jest poprosty prosta tabelą w której wpisujemy id usera i adres serwera na którym sa przechowywane pełne dane na temat uzytkownika X. Więc kiedy nasz Uzytkownik Y z Polski będzie szukał swojego przyjaciela powinien go w bardzo szybkiem czasie tam odnaleść poniewaz jego lokalny serwer lustrzany (no nie dokońca juz lustrany) połaczy się i pobierze dane z zserwera w Ameryce. Myśle że jest to dość zrozumiałe. Oczywiście w praktyce te serwery nie sa teraz juz takie 'lustrzane'. Obok Core Aplication dodawane jest Local Aplication czy cos w tym stylu powodujace że nasza strona dla Polski będzie nieco inaczej wygladał niz dla Ameryki. Zapewne to wam tłumaczy dlaczego chiny moga sobie sprawnie blokowa tresci dla swoich 'podwładnych' - poprostu filtruja tylko serwry lokalne np YouTube.

A teraz taka praktyka w praktyce.

Powiedzmy że mamy super portal i serwery poroztsawiane na całym świecie. SLB jest stosowane w obszarze powiedzmy jednego kraju lub stany/województwa. SPecjalne serwery krajowe/wojewodzkie/stanowe posredniczą w statycznym rozdysponowaniu obciążenia. Natomiast między krajami nie ma żadnego rozdysponowywania poprostu w ramach potrzeby stawia się serwery w danym regionie poniewaz nie ma to sensu jesli na dany kraj założymy sobie domenę z krajowa końcówką (pl, de, my).

Z pingujcie sobie serwer google.pl i google.my dla prównania.

Kazdy serwer jest jednocześnie takim 'lustrzanym' z dodatkami (s001.mojastrona.pl, s002.mojastrona.pl s001.mojastrona.de s002.mojastrona.de etc.)

Zapewne gdyby nagle cały świat się rzucił i w przegladarkach wpisali google.pl to pewnie mieliby niezły zator. - choć mozliwe ze się przed tym zabezpieczyli - powinni.

Oczywiście żaden wielki portal nie bawi się robienie typowych luster serwerów. Pliki Storage tak jak dane sa poprostu indexowane w bazie danych. Dlatego tez w iększej firmie programista stosujacy metode listowania folderu dla plików dostał by po uszach.

Oczywiście jest to tylko takie liźnięcie tematu bo rozbija się to jeszcze o wiele kwesti lokalnych i samego transferowania danych poprzez dns'y, routowanie połączeń globalnych etc.
Trochę sie rozpisałem ale mam nadzieję że jakoś wam przedstawiłem zagadnienie z nieco innej strony.


Pozdrawiam

Napisany przez: luinnar 1.01.2009, 10:23:55

Tak sobie czytam ten wątek i zastanawiam się nad kilkoma rzeczami:
1. Dlaczego ktokolwiek mówi o "rozwiązaniach niskobudżetowych" przy bardzo wysokim ruchu? Masz duży serwis = masz na niego sporą kasę. Wg. mnie nie ma czegoś takiego jak rozwiązanie niskobudżetowe w takich przypadkach
2. Czy nie mylicie czasem stanowisk? Dlaczego programiści PHP myślą o strukturze serwerów? To raczej powinno być zadanie sysadmina, z którym pracujecie. Prawdopodobnie to on lepiej zna się na rozkładaniu ruchu, wydajności poszczególnego softu serwerowego czy optymalnego rozłożenia transmisji danych wewnątrz Waszej sieci. Mówicie: "nie mamy takiego kogoś", odpowiadam: "patrz punkt 1".

Nie zgadzam się, jest bardzo prosta. Memcache, pamięć dzielona serwera. Nie ma tu nic trudnego.

Napisany przez: Krolik 2.01.2009, 12:18:16

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?

Napisany przez: rashid 2.01.2009, 14:05:11

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.



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.

Napisany przez: Krolik 5.01.2009, 11:43:18

Rashid, porównujesz z MySQLem i słusznie zauważyłeś, że MySQL w wielu przypadkach najszybszy nie jest.
Jeśli masz wybór jedynie BDB vs MySQL, to faktycznie BDB może w wielu sytuacjach byc lepzym rozwiązaniem i tu się calkowicie zgadzam.

Natomiast w poprzednich postach pisałem bardziej ogólnie, chodziło mi po prostu o RDBMS, jako taki, nie jakąś konkretną implementację, jak MySQL,
który jest jedną z gorszych implementacji systemu relacyjnego na rynku. No, a skoro mówimy o load-balancingu, to rozumiem, że wchodzą w grę nie tlylko rozwiązania niskobudżetowe.

Realnie kosztuje 0, plany wykonania zapytań w dobrych RDBMSach są buforowane.
A nawet jeśli nie są domyślnie, to są, gdy się użyje prepared statement.


Utrzymania indeksów nie unikniesz też w BDB jeśli gdziekolwiek masz aktualizacje.
Każdy hash w BDB jest indeksem.


Nie ma żadnego powodu, aby transakcje w BDB kosztowały mniej niż w RDBMS.
Można ręcznie określić poziom izolacyjności transakcji. Nie potrzebujesz, ustawiasz
na "NONE" lub 0, narzut znika.



Ogólnik. Konkrety?


Jaka warstwa sieciowa? Oracle Embedded, H2, JavaDB, SQLite nie potrzebują warstwy sieciowej.
A nawet jeśli - od czego jest GigaBit Ethernet?


W RDBMSach wbudowanych, podobnie jak punkt poprzedni - problem nie występuje.
W rozwiązaniach klient-serwer, też rzadko jest to problemem. Tu są szybkości rzędu kilku, kilkunastu GB/s.
No i jeszcze stosuje się buforowanie wyników zapytań po stronie klienta.

Napisany przez: fragles 7.01.2009, 10:33:20

a ja mam pytanie podstawowe
- jak się to liczy to rozkładanie obciążenia? czyli ile będzie potrzeba wszystkiego na jeden serwis

przykładowe dane:
- max wydajność bazy w zapytanie na sek = 50
- max wydajność PHP w przesłaniu zapytania na przeglądarkę na sekundę = 25
- max spodziewanych zapytań do bazy danych na sekundę (dla uproszczenia 1 zapytanie to jedno żądanie wysłane przez przeglądarkę) = 100


czyli to się tak prosto liczy
100/25 = cztery PHP-y
100/50 = dwie bazy
teraz wystarczy to ładnie połączyć i wszystko działa jak trzeba, każdy jest zadowolony

czy to raczej bardziej skomplikowane obliczenia są potrzebne

Napisany przez: rashid 7.01.2009, 11:12:22

Nic w przetwarzaniu danych nie kosztuje 0. Zawsze bedzie odwolanie do managera zapytan, sprawdzenie czy prepared statement jest gotowy, wczytanie wewnetrznych instrukcji bazy dla danego zapytania, zaalokowanie pamieci na wynik itd. Google projektuje swoje bazy danych w taki sposob, zeby kolumny wczytywaly sie w pelni do pojedynczych rejestrow procesora albo w obrebie stron pamieci, a ty mowisz, ze przetwarzanie SQL nic nie kosztuje Kosztowac moze wzglednie malo w porownaniu z samym przetwarzaniem danych, ale darmowe nie jest.



Tutaj trafiasz w sedno - hash (chyba najpopularniejsza struktura danych dla BDB) jest indeksem sam w sobie. Zlozonosc dostepu O(1). W RDBMS indeks moze byc przechowywany w BDB. Indeks - element, ktory ma przyspieszac wczytywanie danych z tabeli, moze byc przechowywany w BDB! Jesli BDB byloby wolniejsze od RDBMS to jaki sens mialoby uzywanie go do przyspieszania?



Zakladajac, ze mozna tez wlaczyc tryb jednouzytkownikowy, z pojedyncza sesja i bez sprawdzania uprawnien do tabel, to pewnie RDBMS zacznie sie zblizac wydajnosciowo do BDB.



(zarzadzanie pamiecia) Indeksy, uprawnienia, prepared statements. Sa tony rzeczy, ktore musisz powylaczac w RDBMS, zeby wyciagnac z niej maksimum wydajnosci. Zgadzam sie, ze to ogolnik, bo nie czuje sie na silach dyskutowac szczegolowo o technicznych aspektach Oracle. Opieram sie na pobieznym zapozaniu sie z architektura.



Jasne, ze mozna RDBMS osadzic i powylaczac mu wszystkie funkcje, zeby wycisnac maksimum. Tylko po co, skoro BDB ma to od razu?

Ciekawostka jest, ze jednym z elementow Oracle Embedded jest Oracle Berkeley DB - dlaczego skoro zwykly Oracle Embeddable powinien byc szybszy?

Mozemy sie spierac, ale najlepiej byloby to oczywiscie przetestowac. Ja ze swojej strony moge powiedziec, ze w jednym projekcie, ktory polozyl na lopatki MySQL ze wzgledu na duza ilosc insert'ow i delete'ow po przejsciu na BDB praktycznie nie odczuwamy istnienia bazy. Oczywiscie musze tu podkreslic, ze baza jest z gruntu nierelacyjna - taki urok przetwarzanych w niej danych.

Chcialbym zauwazyc, ze troche mozemy miec rozne spojrzenie na ten watek. Wydaje mi sie, ze ty odnosisz sie do skalowalnosci ogolnie (co w zasadzie wynika z tematu watku), a ja do konkretnego problemu, ktory zostal w tym watku opisany.

Napisany przez: Krolik 7.01.2009, 13:06:25

Nie będę wchodził w szczególy, bo odeszliśmy od tematu.
Faktycznie BDB służy do przyspieszania i może być wykorzystywane w niższych warstwach RDBMSa. Jednak nie wynika z tego wcale, że RDBMS w praktyce nie może być szybszy. Głównym powodem jest to, że b. dużą częścią dobrych RDBMSów jest optymalizator zapytań. Czyli takie coś, co na podstawie zapytania SQL pisze jakby program wykorzystujący niskopoziomowe polecenia BDB (lub coś innego), aby wykonać zapytanie. Jeśli używasz BDB, program musisz napisać sam. Fajnie, jak musisz wybrać dane z jednej tabeli z jakimś prostym filrem - do tego BDB jest idealne.

Gorzej, jeśli masz złączenia, grupowanie. Wtedy po pierwsze - liczba możliwych sposobów wykonania takiego zapytania bardzo szybko rośnie (wykładniczo z liczbą warunków, złączeń, liczbą dostępnych indeksów). Optymalny plan zależy również od rozkładu danych w bazie, liczby rekordów w tabelach itp. A wiadomo, że w trakcie działania te rzeczy mogą się zmieniać. Czyli nie dość, że musisz być naprawdę niezłym specem, żeby ręcznie zoptymalizować każde zapytanie, to jeszcze na dodatek po pewnym czasie może się okazać, że będziesz musiał przepisywać niektóre części programu, bo zaczną działać za wolno itp. Wystarczy, że gdzieś się pojawi więcej danych i przestanie obowiązywać jakieś założenie, że np. dane zmieszczą się w pamięci. RDBMS jest sobie w stanie poradzić z takimi sytuacjami często niemal bez udziału użytkownika albo z bardzo niewielkim nakładem pracy - typu wydanie jednego czy dwóch poleceń (np. ANALYZe w PostgreSQL, albo RUNSTAT w DB/2). I tu jest właśnie siła - teoretycznie jesteś w stanie w BDB uzyskać szybszy system, ale w praktyce przy złożonym systemie jest to b. trudne, a przy złożonych zapytaniach (np. hurtownianych ala TPC-H) jesteś praktycznie bez szans.

Napisany przez: enigma 13.01.2009, 21:24:38

@rashid czy mógłbyś polecić coś naprawdę dobrego?

Napisany przez: rashid 13.01.2009, 21:41:01

http://www.amazon.com/Scalable-Internet-Architectures-Developers-Library/dp/067232699X to bardzo fajna pozycja przegladowa z zagadnien webowych. Daje do myslenia niektorymi rozwiazaniami i jest solidna podstawa do szukania dalszej wiedzy w necie.

Kopalnia ciekawych przemyslen i pomyslow jest publicznie dostepna http://research.google.com/pubs/papers.html, ale trzeba wylapac interesujace zagadnienia.

Napisany przez: enigma 13.01.2009, 21:58:21

dziękuje wygląda ciekawie - na pewno przeczytam.
Niestety po polsku jest dostępna tylko http://www.komputeks.pl/product_info.php/products_id/2842 - w której jest zaledwie kilkadziesiąt stron o temacie tutaj poruszanym

Napisany przez: rashid 19.01.2009, 22:53:16

Jest jeszcze http://helion.pl/view/3405Y/oprzep.htm. Nie jest to moze ksiazka bezposrednio o tworzeniu skalowalnej architektury, ale opisuje sporo technik, ktore powinno sie zastosowac zanim sie wpakuje w probe skalowania rozwiazania.


Jesli ktos chcialby sprawdzic mozliwosci baz danych nie opierajacych sie na relacjach, to akurat pojawil sie http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/

Napisany przez: jmail 10.08.2009, 22:32:15

Przepraszam, ze tego trupa odgrzebuję, ale miałbym coś do powiedzenia w tym temacie. Delikatnie.

Pierwsze i zasadnicze jestem przede wszystkim programistą takich technologii jak ColdFusion czy ASP.NET i tam loadbalancing nie jest problemem. Pythona nie dotykałem więc nie wiem. Ale wracając do brzegu Opiszę jak to wygląda na serwerze ColdFusion i jakie rozwiązanie zastosowalem.

ColdFusion:

1. Tworzony jest plik application.cfm i jeżeli taki istnieje jest dołaczany do każdego wywołania - dzięki temu zmienne aplikacyjne mogą być trzymane w jednym miejscu i mogą być WSPÓLNE dla wszystkich wywołań skryptu, przez dowolnego użytkownika, a to oznacza, że mamy ponad użytkownikowe rozwiązanie.
2. Istnieje coś takiego jak Client Scope - takie zmienne sesyjne dla klienta, dla przeglądarki. Jak to jest rozwiązane nie mam bladego pojęcia. Ważne że przeglądarka - ta sama instancja jest rozpoznawalna. Wewnątrz jest utrzymywany stan sesji i na wywołaniu z tego samego klienta stan jest odwtarzany.
3. Trzeba dodać, że jak się skorzysta ze zmiennych sesyjnych serwera Java (który jest pod spodem ColdFusion) to można clustrować dowoli serwery, a one sobie ze sobą poradzą

Napotkałem ten problem w jednym grubym projekcie intranetowym na serwerze PHP. Ponieważ za specjalnie nie potrafiłem sobie poradzić, więc podszedłem do tematu z innej strony. Pierwsze opisałem sobie czego mi w PHP brakuje z lepsiejszych (no cóż wygoda programowania CF czy .NET nie do porównania z PHP ^^) rozwiązań. Wypisalem sobie i się okazało, że wcale nie jest tak źle ^^. Cold Fusion daje możliwość składowania ciastek dla klienta po stronie serwera, a u klienta leży jedna zmienna z id ciastka i CF jakoś to robi, ze rozpoznaje że to ten user (klient) był.

Zakasałem rękawy i przeryłem stado dokumentacji do PHP i .NET i do tworzenia modułów do PHP. Po miesiącu prób i błędów udało mi się wyprodukować dll'kę która zwracała hello world! Ale to już był gotowy przepis na rozwiązanie moich problemów. Jak się udało wypluć hello world to da się cokolwiek zrobić. Wykonałem więc dll'kę, która odczytywała zmienne sesji z bazy danych i wrzucała je do skryptu PHP. Voile'a - między serwerowe rozwiązanie Co prawda potrzebna była taka maszyna, która to w bazie utrzyma, wysokiej dostępności i na pewno nie MyShitQL (sorry jeżeli kogoś urażam, ale to moja opinia). I znalazła się. Jakiś tam Echange stał, który tylko pocztę serwował z 16 procesorów oO. SQL Server Workgroup się znalazł i zaczeło gadać.

Pozostała jeszcze kwestia rozpoznawania klienta. W tym wypadku było to o tyle prostsze, że to był intranet, więc ciastko zapodałem i dowidienia.

Zapytacie na pewno jak z wydajnością. No cóż. Okazało się, że początek nie był radosny. Opóźnienie skryptu z jednej maszyny o jakieś 200%. Niestety, ale to mnie na chwilę znowu zatrzymało. Okazało się, że problemem stało się dochodzenie do zmiennych sesji $_SESSION przez dll. Znowu drobna przebudowa dll i extend replace na skrypty php ze zamianą $_SESSION na $_SESS (i przestawinie się w głowie na takie używanie zmiennych).

Kolejna sprawa, że stało się dla mnie niezbędne korzystanie ze zmiannych aplikacyjnych globalnych dla wszystkich użytkowników. TO akurat było prosto rozwiązać.

Napisałem skrypcik ładujący dane do tabeli $_APP (znowu naleciałości z coldka) i dodalem .htaccess z wpisem:

php_value auto_prepend_file "/sciezka/do/application.php"

oczywiscie, że próbowało dopisywać do każdego pliku. Proste rozwiązanie:

if(!$_APP)

i już. Mam zmienne aplikacyjne, mam załatwiony load balancing i mam sprawny intranet - kodu dll nie zapodam - kupę kapuchy za to położyli.

Na zakończenie tego wtrącenia trzeba dodać parę uwag:

1. Jak chcesz tak zrobić wybierz DOBRY serwer bazodanowy. Najlepiej nadają się do tego SQL Server w wersji Workgroup lub wyższej, ORACLE lub PostgreSQL.
2. NIGDY nie próbuj zmuszać serwery do komunikacji między sobą. Postaw maszynę, dającą sesje ale niech maszyny ze sobą nie współpracują w jakiś "zacieśniony" sposób - niepotrzebnie zużyjesz zasoby. PHP jest nieclustrowalny w sposób prosty i trzeba się z tym pogodzić dopóki programiści czegoś nie wysmażą.
3. Przy tworzeniu dll'ki dałem jej parę parametrów konfiguracyjnych ładowanych przez php.ini:
- nazwa clustra
- id serwera
- dane dostępowe do bazy danych z sesjami - dzięki nazwie clustre'a taka maszyna może obsługiwać ileś clustrów i ją samą też można clustrować - to już naprawdę na poziomie very high lodaed applications - ale wtedy weźmiecie coś lepszego nie PHP
4. Regularnie usuwaj sesje, które wygasły. Najlepiej jakiś sprytny trigerek on insert. ALbo Scheduled Task w Windows lub cron w UX

To porada dla naprawdę bardzo potrzebujących i muszących łączyć DUŻĄ ilość serwerów. Jest jednak sprytniejsze rozwiązanie. Może mniej wydajne, ale zawsze. Ustaw jedną maszynę z serwerem obsługującym dane aplikacyjne sesyjne i inne cuda. Jak nie chcecie IIS z .NET może być zwykły Debian z JBoss'em. Zmienne Javy bardzo dobrze się sprawdzają.

Przy odpaleniu dowolnego skryptu wywołujesz jeden jedyny plik z tamtego serwera (zmienne aplikacji nie będą się zmieniać zbyt często), który PRZEPISUJE Ci zmienne do php. eval i dowidienia


Tak teraz mi dwie aplikacje na po trzy serwery chodzą. Z tyłu stoi .NET, który stoi na windzinie XP i się sprawdza. A to najważniejsze. Sprawdza się na tyle, ze nie zamierzam znowu jakichś karkołomnych skoków robić - dodam, że aplikacje obciążane są średnio dziennie na jakieś 45k wywołań przez ok 3k użytkownków. Raporty finansowe, cuda wianki, wnisoki i inne duperele. Żeby jeden workflow przejść trzeba zrobić jakieś 10 wywołań.

To tak tytułem odgrzewania trupów trafiłem tu bo znowu robie high loaded i myślałem, że może coś się zmieniło w tym temacie. A że klient chce PHP na Linuxie.... .NET odpada, Javy nie wystawię, zostaje lip w C++. Trzeba się przeprosić...

Napisany przez: Ormin 16.05.2010, 22:19:23

Myślę, że wypadałoby odświeżyć temat. Przy okazji - czy zna ktoś dobre pozycje nt. pisania skalowalnych aplikacji? ( To dobry temat do tego? ).

Napisany przez: BugsBunny 15.09.2012, 22:20:20

Odgrzebie temat, bo mam trochę praktyki w tym temacie. W firmie tworzymy duża aplikację, którą około 8 mieszący temu przeszła na środowiska HA (High availabilty). Wynikało to z ruchu oraz podpisanego SLA z klientem. W tej chwili architektura wygląda tak, że mamy x serwerów apikacyjnych i y serwerów bazodanowych. Architektura jest rozwiązaniem autorskim zrobionym przez naszego administratora.

Opiszę może proces przejścia aplikacji ze zwykłej na środowisko rozproszone. Liczba zmian w kodzie równa się 0, aczkolwiek opiszę problemy z jakimi można się spotkać. Być może ktoś dopowie coś ciekawego i dołoży swoje przemyślenia. Na starcie powiem, że pominałęm ze 2 strony z wątku więc mogłem wszystkiego nie doczytać .

Co z cache:
- wszystkie foldery, współne np. cache widoku jest współdzielony między wszystkie nody applikacyjne. Zapis w cache do node-4 powoduje pojawienie się w node-1.

Co z uploads
- jak wyżej, współdzielone.

Sesja:
- sesja utrzymywana jest na poszczególnym węźle. Load balancer dba o to, aby żądanie od klienta kierować zawsze na ten sam węzeł. Jeżeli ten węzeł padnie, to cóż mamy fail dla tej sesji, ale aplikacja dalej jest dostępna. Efekt -> wylogowanie.

baza danych i replikacja:
- tutaj są największe problemy dla replikacji asynchronicznej dla wielu węzłów bazodanowych. Może być taka sytuacja w aplikacji, że dokonujemy zapisu do db-1 (węzeł 1 db), robimy przekierowanie, a następnie robimy odczyt z bazy wcześniej zapisanej wartości. W przypadku gdy aplikacja podłączy się do db-2 może replikacja nie zdążyć i dostaniemy error 500, lub błąd z brakiem danych w bazie.


Jestem ciekaw jak u Was następowały przenosiny aplikacji w PHP na środowiska HA i na jakie problemy natrafiliście. Jak wyglądało u Was dostosowanie oprogramowania i architektury do potrzeb działania systemu.