Pełna wersja: Duże aplikacje i load balancing
Temat założony na prośbę SHIPa oraz normanosa traktujący o rozkładaniu obciążenia na wiele maszyn
Muskający powierzchnię tematu wpis na blogu Talena z serii "Duże portale".
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...
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...
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
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
A jest możliwość utworzenia dysku sieciowego i na nim trzymania sesji tak że każdy serwer będzie miał do niego dostęp ?
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
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
Soft do obsługiwania takich sesji już istnieje i nazywa się mcache - 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.
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.
Cytat(wrauk @ 5.08.2008, 13:55:10 ) 
Można się np.: zastanowić nad zapamiętywaniem części danych w sesji, a dopiero garbage collector zapisywał by dane do bazy.
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).
Cytat
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.
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 ?
Cytat(wlamywacz @ 5.08.2008, 22: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 ?
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ć.
Cytat(wlamywacz @ 5.08.2008, 22: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 ?
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).
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ą.
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ą.
Cytat(jarek_bolo @ 5.08.2008, 23:08:59 )
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.
Zaawansowane load balancery za dużo $$$ mają takie możliwości.
Cytat(jarek_bolo @ 5.08.2008, 23:08:59 )
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 ?
....
Mankament to userzy nie akceptujący ciastek, ale wtedy może jakaś zmienna doklejana do url'a ?
....
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 :-) ).
Cytat(wrauk @ 6.08.2008, 08:56:52 )
Zaawansowane load balancery za dużo $ mają takie możliwości.
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
Cytat(wrauk @ 6.08.2008, 08:56:52 )
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 :-) ).
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ę
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
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
Cytat(jarek_bolo @ 6.08.2008, 09:51:23 )
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ę
Ale z racji swojego małego doświadczenia nie wiem czy tak się da i może głupoty piszę
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 ?
:-)
A co z adresami typu www2.cos.pl ?
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
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
Ale jak działa to
www2.cos.pl itd. bo nawet nie wiem jak o to google zapytać.
www2.cos.pl itd. bo nawet nie wiem jak o to google zapytać.
Normalnie Serwer ma taką nazwę, dns wskazuje na jego IP. Tak jak każdy inny serwer
Nie rozumiem pytania
pozdr.
Łukasz
Serwer ma taką nazwę, dns wskazuje na jego IP. Tak jak każdy inny serwer Nie rozumiem pytania
pozdr.
Łukasz
Cytat(wlamywacz @ 6.08.2008, 12:38:17 )
Ale jak działa to
www2.cos.pl
Tak samo jak www.cos.plwww2.cos.pl
Ty tylko nazwa :-)
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.
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.
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.
Kup serwer dedykowany, da radę bez problemu. Patrz ovh
@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.
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.
Cytat(normanos @ 6.08.2008, 14: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.
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).
Cytat(wlamywacz @ 7.08.2008, 22:50:20 )
Kup serwer dedykowany, da radę bez problemu. Patrz ovh
Poczytaj sobie: http://prawo.vagla.pl/node/8027
Cytat(wrauk @ 8.08.2008, 08:47:21 )
Kiedy osobny dedyk z bazą to za mało kupujesz drugi dedyk i możesz zrobić trzy rzeczy:
- master-slave
- cluster
- master-slave
- cluster
Znam te hasła ale literatury ciągle za mało. Niestety nie mam z Mysql aż tak dużego doświadczenia. Googlam dalej
Cytat(wrauk @ 8.08.2008, 08:47:21 )
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).
- cache zapytań do bazy,
- tuning konfiguracji mysql'a (my.cnf),
- tuning struktury bazy (przejżeć slow query log).
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.)
Cytat(normanos @ 8.08.2008, 10: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
Sorki za kryproreklamę, ale może tutaj znajdziesz linki których szukasz :-)
http://talen.jogger.pl/2008/03/16/duze-por...logia-serwerow/
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
Polecam jedne link http://highscalability.com/
np:
http://highscalability.com/linkedin-architecture-0
http://highscalability.com/ebay-architecture
http://highscalability.com/37signals-architecture
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.
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.
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.
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.
Cytat(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ń.
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.
Cytat(Krolik @ 2.12.2008, 10:37:42 )
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?).
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
Cytat(Krolik @ 2.12.2008, 10:37:42 )
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.
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.
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.
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.
piszesz, że będziesz mielił dane z dysku a potem wybierasz RPS, to jakby się wyklucza.
Cytat(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.
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.
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.
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!
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!
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.
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.
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.
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.
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?
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?
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
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
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ęć...
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
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
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
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.
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
Nie zgadzam się, jest bardzo prosta. Memcache, pamięć dzielona serwera. Nie ma tu nic trudnego.
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?
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.
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?
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.
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.
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.
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
- 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
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
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.
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.
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.
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?
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.
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.
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.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.