Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Zasady pisania na forum Pro

Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.

3 Stron V  < 1 2 3  
Reply to this topicStart new topic
> Duże aplikacje i load balancing, Czyli co i jak zrobic jak maszyna nie daje rady
erix
post 20.12.2008, 20:06:03
Post #41





Grupa: Moderatorzy
Postów: 15 467
Pomógł: 1451
Dołączył: 25.04.2005
Skąd: Szczebrzeszyn/Rzeszów




Cytat
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?

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.

Cytat
ktore realizuja ladowanie na stale do pamieci skryptow z logika i danych.

APC, eAccelerator, Zend Optimizer, shmop...

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

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


--------------------

ZCE :: Pisząc PW załączaj LINK DO TEMATU i TYLKO w sprawach moderacji :: jakiś błąd - a TREŚĆ BŁĘDU? :: nie ponaglaj z odpowiedzią via PW!
Go to the top of the page
+Quote Post
wlamywacz
post 25.12.2008, 10:52:03
Post #42





Grupa: Zarejestrowani
Postów: 535
Pomógł: 27
Dołączył: 3.05.2005

Ostrzeżenie: (20%)
X----


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 smile.gif
Go to the top of the page
+Quote Post
djhors
post 29.12.2008, 11:07:55
Post #43





Grupa: Zarejestrowani
Postów: 4
Pomógł: 0
Dołączył: 13.03.2008

Ostrzeżenie: (0%)
-----


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

Ten post edytował djhors 29.12.2008, 11:25:44
Go to the top of the page
+Quote Post
luinnar
post 1.01.2009, 10:23:55
Post #44





Grupa: Zarejestrowani
Postów: 155
Pomógł: 0
Dołączył: 15.07.2004
Skąd: Bielsko-Biała

Ostrzeżenie: (0%)
-----


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

Cytat(Kocurro @ 20.12.2008, 19:40:32 ) *
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 biggrin.gif

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


--------------------
notDevBlog - devblog.luinnar.com
Go to the top of the page
+Quote Post
Krolik
post 2.01.2009, 12:18:16
Post #45





Grupa: Zarejestrowani
Postów: 53
Pomógł: 0
Dołączył: 16.11.2004

Ostrzeżenie: (0%)
-----


Cytat(rashid @ 20.12.2008, 18:53:32 ) *
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?


--------------------
Projekty: PLAY, optymalizator baz danych
Go to the top of the page
+Quote Post
rashid
post 2.01.2009, 14:05:11
Post #46





Grupa: Zarejestrowani
Postów: 27
Pomógł: 0
Dołączył: 22.11.2003

Ostrzeżenie: (0%)
-----


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


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.

Cytat(Krolik @ 2.01.2009, 12:18:16 ) *
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


--------------------
Robert Janeczek
G-Forces Web Management Polska
robert.janeczek@gforces.pl
Go to the top of the page
+Quote Post
Krolik
post 5.01.2009, 11:43:18
Post #47





Grupa: Zarejestrowani
Postów: 53
Pomógł: 0
Dołączył: 16.11.2004

Ostrzeżenie: (0%)
-----


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.


Cytat
- przetwarzanie SQL

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.

Cytat
- zarzadzanie indeksami

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

Cytat
- zarzadzanie sesjami i transakcjami

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.


Cytat
- rozbudowane operacje w pamieci

Ogólnik. Konkrety?

Cytat
- posrednia warstwa sieciowa

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

Cytat
- przenoszenie danych pomiedzy przestrzenia adresowa serwera bazy a programem przetwarzajacym dane

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.


--------------------
Projekty: PLAY, optymalizator baz danych
Go to the top of the page
+Quote Post
fragles
post 7.01.2009, 10:33:20
Post #48





Grupa: Zarejestrowani
Postów: 110
Pomógł: 0
Dołączył: 14.12.2008

Ostrzeżenie: (0%)
-----


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
Go to the top of the page
+Quote Post
rashid
post 7.01.2009, 11:12:22
Post #49





Grupa: Zarejestrowani
Postów: 27
Pomógł: 0
Dołączył: 22.11.2003

Ostrzeżenie: (0%)
-----


Cytat(Krolik @ 5.01.2009, 11:43:18 ) *
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.


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 smile.gif Kosztowac moze wzglednie malo w porownaniu z samym przetwarzaniem danych, ale darmowe nie jest.

Cytat(Krolik @ 5.01.2009, 11:43:18 ) *
Utrzymania indeksów nie unikniesz też w BDB jeśli gdziekolwiek masz aktualizacje.
Każdy hash w BDB jest indeksem.


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?

Cytat(Krolik @ 5.01.2009, 11:43:18 ) *
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.


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.

Cytat(Krolik @ 5.01.2009, 11:43:18 ) *
Ogólnik. Konkrety?


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

Cytat(Krolik @ 5.01.2009, 11:43:18 ) *
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.


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? smile.gif

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.


--------------------
Robert Janeczek
G-Forces Web Management Polska
robert.janeczek@gforces.pl
Go to the top of the page
+Quote Post
Krolik
post 7.01.2009, 13:06:25
Post #50





Grupa: Zarejestrowani
Postów: 53
Pomógł: 0
Dołączył: 16.11.2004

Ostrzeżenie: (0%)
-----


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.


--------------------
Projekty: PLAY, optymalizator baz danych
Go to the top of the page
+Quote Post
enigma
post 13.01.2009, 21:24:38
Post #51





Grupa: Zarejestrowani
Postów: 163
Pomógł: 0
Dołączył: 10.09.2006

Ostrzeżenie: (0%)
-----


Cytat(rashid @ 27.11.2008, 13:27:56 ) *
Pozwole sie wtracic, bo Panowie proboja rozwiazac problemy, ktore stosunkowo dobrze sa opisane w literaturze zagranicznej, ktora chyba nie wszystkim jest znana.

@rashid czy mógłbyś polecić coś naprawdę dobrego?
Go to the top of the page
+Quote Post
rashid
post 13.01.2009, 21:41:01
Post #52





Grupa: Zarejestrowani
Postów: 27
Pomógł: 0
Dołączył: 22.11.2003

Ostrzeżenie: (0%)
-----


Cytat(enigma @ 13.01.2009, 21:24:38 ) *
@rashid czy mógłbyś polecić coś naprawdę dobrego?


Scalable Internet Architectures 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 lista artykulow opublikowanych przez Google'owcow, ale trzeba wylapac interesujace zagadnienia.


--------------------
Robert Janeczek
G-Forces Web Management Polska
robert.janeczek@gforces.pl
Go to the top of the page
+Quote Post
enigma
post 13.01.2009, 21:58:21
Post #53





Grupa: Zarejestrowani
Postów: 163
Pomógł: 0
Dołączył: 10.09.2006

Ostrzeżenie: (0%)
-----


dziękuje smile.gif wygląda ciekawie - na pewno przeczytam.
Niestety po polsku jest dostępna tylko Skalowalne witryny internetowe Budowa skalowanie i optymalizacja aplikacji internetowych nowej generacji - w której jest zaledwie kilkadziesiąt stron o temacie tutaj poruszanym
Go to the top of the page
+Quote Post
rashid
post 19.01.2009, 22:53:16
Post #54





Grupa: Zarejestrowani
Postów: 27
Pomógł: 0
Dołączył: 22.11.2003

Ostrzeżenie: (0%)
-----


Cytat(enigma @ 13.01.2009, 21:58:21 ) *
dziękuje smile.gif wygląda ciekawie - na pewno przeczytam.
Niestety po polsku jest dostępna tylko Skalowalne witryny internetowe Budowa skalowanie i optymalizacja aplikacji internetowych nowej generacji - w której jest zaledwie kilkadziesiąt stron o temacie tutaj poruszanym


Jest jeszcze Wydajne witryny internetowe. Przyspieszanie działania serwisów WWW. 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 ciekawy post przegladowy


--------------------
Robert Janeczek
G-Forces Web Management Polska
robert.janeczek@gforces.pl
Go to the top of the page
+Quote Post
jmail
post 10.08.2009, 22:32:15
Post #55





Grupa: Zarejestrowani
Postów: 352
Pomógł: 53
Dołączył: 10.08.2009

Ostrzeżenie: (0%)
-----


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 winksmiley.jpg 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 biggrin.gif 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! smile.gif 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 winksmiley.jpg 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 biggrin.gif
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 winksmiley.jpg


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 smile.gif 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ć...
Go to the top of the page
+Quote Post
Ormin
post 16.05.2010, 22:19:23
Post #56





Grupa: Zarejestrowani
Postów: 64
Pomógł: 0
Dołączył: 3.02.2009

Ostrzeżenie: (0%)
-----


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? ).
Go to the top of the page
+Quote Post
BugsBunny
post 15.09.2012, 22:20:20
Post #57





Grupa: Zarejestrowani
Postów: 206
Pomógł: 4
Dołączył: 2.04.2005

Ostrzeżenie: (0%)
-----


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.
Go to the top of the page
+Quote Post

3 Stron V  < 1 2 3
Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 11.12.2019 - 10:34