Witam, nie wiem co prawda, na jaką ilość użytkowników planowana jest aplikacja i jaka będzie charakterystyka przetwarzanych danych, jaka będzie dynamika przyrostu liczby użytkowników (właściwie bardzo mało wiem ;), chciałbym jednak wskazać kilka rzeczy, które, moim zdaniem, nie służą skalowaniu proponowanego rozwiązania.

1. Logika biznesowa

Rozwiązanie polegające na połączeniu logiki biznesowej z warstwą prezentacji uważam za niedobre, a wręcz złe. Dlaczego?

Co z deploymentem nowej wersji warstwy biznesowej? Sesje HTTP w proponowanym rozwiązaniu nie są replikowane, więc każdy upgrade farmy (np. załatanie buga) będzie powodował wylogowanie wszystkich użytkowników. Proponowane rozwiązanie jest po prostu niepraktyczne. Restart warstwy usług nie powinien w żaden sposób wpływać na widok.

Architektura kolokowana jest, moim zdaniem, dobra do wieloetapowego przetwarzania wsadowego, jeśli obiekty przesyłane między kolejnymi etapami są na tyle duże, że koszt ich transportu jest nieuzasadniony.

W przypadku serwisów internetowych, nazwijmy je Web 2.0, dużo lepiej sprawdza się stworzenie warstwy biznesowej w duchu SOA, czyli dedykowanych maszyn świadczących usługi na rzecz serwerów webowych w formie bezstanowej, a więc łatwej do skalowania.

2. Warstwa danych

Problem z jednym masterem jest taki, że zawsze uderza się w sufit (a to z I/O, a to z CPU, a to z wielkością bazy). Kolejkowanie zapisów rozwiązuje jeden problem, ale powoduje co najmniej 4 następne:

- nie masz gwarancji, kiedy slave, z którego czytasz, zobaczy dane (w przypadku serwisu społecznościowego problem dość poważny, bo w momencie wzmożonej intensywności pracy użytkowników właściwie nikt nie zobaczy danych w rozsądnym czasie - znowu, jeśli projekt okaże się sukcesem),
- kolejka taka to dodatkowy komponent do administracji, z własną bazą, replikacją, klastrami (bo żaden zapis nie może zginąć!), a więc dodatkowy operacyjny koszmar,
- części operacji nie można (nie powinno się) robić wsadowo: np. zmiana hasła, uprawnień, blokowanie użytkownika,
- nie wiadomo od razu, czy wkładane do bazy dane są dobre - jeśli nie są to użytkownik nie ma jak zareagować, bo nie dostaje natychmiastowej informacji, że coś jest nie tak.

Przykład dużych, działających od lat serwisów społecznościowych uczy, że jest tylko jedyna słuszna droga na skalowanie takiej bazy danych i jest to sharding. Sharding ma tą przewagę nad 1:master-N:slaves, że daje wiele jednoczesnych punktów zapisu i tym samym umożliwia niemal nieograniczone skalowanie. Oczywiście zapanowanie nad danymi w shardach, gdzie nie ma zawsze mamy klucze obce, czy transakcje itp., to już inna historia.

To moje 2 grosze. Dużo inspiracji w tej materii można znaleźć pod adresem: http://highscalability.com/ - polecam ten serwis, jest to niesamowite źródło praktycznej wiedzy w zakresie skalowania aplikacji.

pozdrawiam
piotr

Moje 3 grosze, z wieczora:

1)
“Restart warstwy usług nie powinien w żaden sposób wpływać na widok.” - to brzmi bardzo poważnie, ale, moim skromnym zdaniem, jest argument czysto akademicki. Jak często będziesz miał w aplikacji typu portal społecznościowy modyfikacje logiki biznesowej bez modyfikacji warstwy prezentacji? Ok, pewna część przypadków załatania błędu tak; ale tylko _niewielka_ część.
Poza tym, w portalach społecznościowych, w sesji http raczej nie przechowujemy więcej niż dane autoryzacyjne - musimy wiedzieć z kim rozmawiamy, i tyle. W tej sytuacji nietrudno sobie wyobrazić mechanizm replikacji tak uszczuplonej sesji między klientami - choćby przy pomocy starego dobrego cookie i synchronizacji id sesji na poziomie bd.
Oczywiście zwiększamy narzut na bazę - ale i tak [zazwyczaj] w tego typu serwisach prezentujemy informację o innych użytkownikach zalogowanych/niezalogowanych; więc i tak musimy przenieść to przez bazę danych.

2)
Sharding, czy jak inni wolą horizontal partitioning jest fajny w zastosowaniach typu flickr czy nasza-klasa, gdzie większość obrabianych danych jest w sposób oczywisty związana z klientem/użytkownikiem i nie ma złożonych zapytań wyszukujących dane od potencjalnie wszystkich użytkowników. W przypadku aplikacji Wojtka niestety krytyczne są bardzo wyszukiwania nietrywialnie przeszukujące dane z profili wszystkich użytkowników; sharding by je zabił.

3) “- części operacji nie można (nie powinno się) robić wsadowo: np. zmiana hasła, uprawnień, blokowanie użytkownika,
- nie wiadomo od razu, czy wkładane do bazy dane są dobre - jeśli nie są to użytkownik nie ma jak zareagować, bo nie dostaje natychmiastowej informacji, że coś jest nie tak.”

Kolejki to nie tylko komunikacja asynchroniczna, wybrane zapisy można wysyłać synchronicznie, regulować kolejność ich realizacji priorytetami. To ofc nie rozwiązuje wszystkich potencjalnych problemów (sufit jest zawsze), ale pozwala ten sufit podnieść.

Podsumowując, wydaje mi się że rozwiązanie Wojtka się broni, nie jest idealne ale takiego nie ma.
Oczywiście, jest mi łatwiej komentować, bo lepiej znam wymagania aplikacji.

pozdrawiam
Marcin

Moje kolejne 4 grosze:

1) Restart samej warstwy usług może i jest rozważaniem akademickim (choć z mojego doświadczenia wynika, że występuje dość często w fazie skalowania systemu i optymalizacji).

Dużo większą wadą tego połączenia jest to, że od razu zabieracie sobie możliwość skalowania tych dwóch warstw oddzielnie. Takie combo będzie się skalować wprost proporcjonalnie do najcięższego komponentu. Jeśli warstwa usług biznesowych przestanie się wyrabiać, to trzeba będzie dołożyć do farmy
dodatkowy serwer, który będzie tylko w części wykorzystany przez owe usługi, bo część maszyny będzie zajęta przez “fronty” (których np. wcale więcej nie potrzeba).

2) Ciężkie wyszukiwanie wg różnych kryteriów czasem lepiej jest zrobić w oparciu o dedydowaną usługę, np. Lucene z indexem zoptymalizowanym do tego typu przeszukiwań.

Oczywiście wszystko jest kwestią skali, do jakiegoś momentu zadawanie ciężkich zapytań do bazy w zupełności wystarczy i w sumie jest to bardzo dobre rozwiązanie na start. Optymalizację można zostawić na później.

Tak w ogóle to cieszę się bardzo, że podjęliście temat skalowalności - niewiele się w Polsce pisze na ten temat. Mam nadzieję, że podzielicie się również swoimi doświadczeniami z implementacji tegoż rozwiazania.

–
pozdrawiam
piotr maj

Teraz ja:)

AD 1) Zależy, co jest kluczowe: pamięć czy procesor.

Jeśli procesor to nie ma znaczenia czy mam 10 maszyn na web i 90 na serwisy, czy 100 maszyn które równo dzielą między siebie 10% obciążenia web, 90% obciążenia serwisów.

Jeśli pamięć, to znowu zależy jaka jest charakterystyka zużycia pamięci naszego serwisu. Załóżmy, że jest liniowo zależna od ilości żądań (oczywiście, niektóre żądania mogą być lekkie, inne ciężkie, przyjmujemy tu żądanie uśrednione). Wprowadźmy sobie wzór:

mem = ż * (aw + au) + bw + bu

mem - ilość użytej pamięci
ż = ilość żądań
aw = wielkość pamięci używana przez warstwę web na obsługę jednego żądania uśrednionego
au = analogiczne dla aw, dla warstwy usług
bw = wielkość stała pamięci zużywana przez warstwę web
bu = jak wyżej, dla warstwy usług
= symbol wskazujący, że powyższy wzór nie powinien być traktowany zbyt serio

I teraz tak: jeśli bu i bw są względnie małe (tzn. pamięć zajęta przez classloader itp. jest względnie mała): to nadal nie ma znaczenia, czy możemy rozdzielić usługi od web, czy nie: w obu przypadkach obsługa jednego requestu zajmuje pewną stałą ilość zasobów (aw + au) i podobnie jak w przypadku procesora - rozdzielenie tego na różne grupy komputerów nic nie zmienia.

Jeśli bw i/lub bu są względnie duże to oczywiście Twoje rozwiązanie zaczyna mieć przewagę. Kiedy bw i bu będą względnie duże? Kiedy będziemy chcieli stosować jakieś kesze itp. Czy w tym wypadku Wojtek planował ich stosowanie? Nie wiem:)

AD 2)
Tu nie chodzi o wyszukiwania pełnotekstowe czy temu podobne. To coś jak znalezienie wspólnych znajomych 4-tego stopnia (czyli ja znam X, X zna Y, Y zna Z, Z zna Ciebie) tyle że dużo bardziej skomplikowane i niestety bardzo dynamiczne - tak że odpadają rozwiązania preindeksujące dane. Nie chce mi sie wchodzić w szczegóły, w każdym razie to, o ile znam lucene, compas itp to nie jest ta bajka.

pozdrawiam
Marcin

zyraweg…

Ashley Leggat Nude Pictures …

xyzyluzo…

donnie baker pics …

< blockquote >< a href=”http://medicamentspot.com/”>Medicamentspot.com. Canadian Health&Care.No prescription online pharmacy.Best quality drugs.Special Internet Prices. No prescription drugs. Buy pills online< /a >…

Buy:Retin-A.Human Growth Hormone.Petcam (Metacam) Oral Suspension.Mega Hoodia.Prednisolone.Prevacid.Arimidex.Lumigan.Zyban.100% Pure Okinawan Coral Calcium.Nexium.Actos.Zovirax.Accutane.Valtrex.Synthroid….

friendly http://jfriendly259.AUTOPARTSTHAI.INFO/tag/Wonderflex+Plastic+plastic+friendly/ : Plastic…

Wonderflex…

Kitchen http://agrillz-lyqd.ANTIQUEFURNINISHING.INFO/tag/Kitchen+electric+Cooking/ : electric…

Kitchen…

Furniture http://oteatjvnbey.05KIAPARTS.US/tag/Starting+an+Business+sale+Furniture/ : Furniture…

an…

downtown http://hpatioojamu.AWESOMEBABYCLOTHES.INFO/tag/shops+cruz+downtown/ : shops…

cruz…

Cartridges http://xlights9nzlr0l.03GMCPARTS.US/tag/hp+Cartridges+Epson/ : hp…

Epson…