Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Czesc,

chcialbym zaciagnac troche wiedzy madrzejszych ode mnie, odnosnie projektu architektonicznego systemu, ktorego budowa zostala mi powiezona.

Jest w trakcie projektowania (a w zasadzie przeprojektowywania) systemu sluzacego do oceniania. Stary system napisany byl w PHP/Mysql, co raczej bylo spowodowane potrzeba szybkiego posiadania prototypu, niz czyjas zlowrogoscia. O ile nie bylo to zbyt dobra decyzja, kod wyglada jak Perlowa miazga, bez slowa komentarza, pozwolilo to na spostrzezenie wielu potencjalnych problemow.

System sluzy do oceniania prac, w zasadzie jest jednym duzym silnikiem statystycznym, z niestety niepodzielnym (w wiekszej czesci) algorytmem obliczeniowym. Czesc akgorytmu wymaga pewnego sposobu dodawania danych do systemu, w ktorym aplikacja, uzywana przez Sedziow (osoby oceniajace) wysyla kazdorazowo zapytanie do systemu poprzez API, jaka to prace ma nastepnie oceniac, Efekt tejze oceny jest zwracany rowniez przez API. Wszystko byloby fajnie, oprocz tego, ze ma byc to przygotowane na pokazne ilosci:

- 100k+ prac ocenianych
- API potrzebne do komunikacji (dodawanie prac, sedziow, ocenianie, okreslanie co oceniac, raportowanie), zapewne prosty JSON, moze tez XML (ale preferowalbym to pierwsze)
- 10-20k sedziow, przy jednym ocenianiu, czyli duzo requestow do API
- algorytm jest dosc wolny pod wzgledem tego, ze ma zlozonosc obliczeniowa O(x*(n^n)), wiec widzlalem juz szybsze... aczkolwiek podczas takiej pelnej oceny 100 tys prac, wystarczy zeby byl obliczony z 10-20 razy, tyle, ze w odstepach godzin/dni.

Kolejnym problemem sa dane, ladowanie kilkuset tys elementow (prace, oceny itd) nawet z pliku do pamieci, budowanie struktury i obliczanie na zawolanie nie wchodzi w gre, bo trwalo by to zbyt dlugo. Jedna z problematycznych elementow odnosnie algorytmu, to to, ze jak juz bedzie musial byc obliczony to raz na pare dni, ale w ciagu paru (nastu) sekund max (poniewaz blokuje to wszystko inne, jak ocenianie). Tak wiec dane musza byc wszystkie w pamieci caly czas. Calosc musi tez wisiec w pamieci dosc dlugo (tydzien-miesiac).

Doswiadczenie podpowiada mi aby zabrac sie za to bardzo szczegolowo i uwaznie, ze wzgledu na dosc zroznicowane problemy na poszczegolnych etapach architektury, jakie mozna sobie stworzyc.

Z punktu widzenia samej budowy architektury aplikacji, Event Sourcing wydaje mi sie odpowiednia opcja, jako, ze posiadajac wszelkie eventy oraz stan podstawowy, bede mogl bez problemu "doliczyc sie" do kazdego dowolnego stanu oraz latwo rozeslac informacje w postaci zdarzen na dowlona ilosc maszyn. Wszystkie eventy beda musialby byc tez gdzies zserializowane sekwencyjnie per jakis klucz (moze column data store).

1 Pomysl
- szereg maszyn API, ktore jednoczesnie komunikuja sie z jakims storagem danych (pewnie uzyje Amazon DynamoDB) oraz wysylaja eventy do maszyn obliczeniowych oraz bioracych z nich pewne informacje
- szereg maszyn obliczeniowych, na ktorych "wisi" sobie cala informacja w pamieci i jest obczliana jednoczesnie
- load balancer nie-proxy, ktory bedzie mogl instruowac serwery o wzajemnym polozeniu i stanie
- do dzielenia eventow API przychodzacego (nie wymagajacego odpowiedzi zwiazanej ze stanem systemu) mozna uzyc RabbitMQ albo ZeroMQ

Ma to plus bycia przejrzystym, mozna tez ocenic szybko stan poszczegolnych maszyn, wiadomo gdzie to jest. Czesc z maszynami API, oczywiscie dosc latwo sie skaluje, Komunikacja jedyni API<->obliczeniowe. Rozwiazany jest tez problem z redundancja, - prawdopodobnie nigdy nie bedzie trzeba odnawiac calosci obliczen, przy 3+ maszynach chodzacych. Ma tez jednak minusy:
- wszystkie maszyny obliczeniowe musialyby przeprowadzac obliczenia (czasem to jest zbedne, szczegolnie, gdy mamy do czynienia z malymi sesjami oceniania) - potencjalnie sporo mocy sie marnuje, wystarczyloby zeby 2-3 razy przeprwadzac to samo
- ciezko skalowac maszyny obliczeniowe
- MQ maja bardzo duze wydajnosci (przynajmneij jak na moje potrzeby), latwo sie je klastruje oraz potrafia zrzucac wszystko na dysk dla bezpieczenstwa

Mam tez pomysl inny, troche bardziej "cudowny", chodz chcialbym uslyszec Wasze zdanie odnosnie obu.

2 Pomysl

System z "bladzacym" systemem obliczeniowym:

- Maszyny jednoczenie obsluguja API oraz potencjalnie czesc obliczeniowa
- kazdy event w systemie trzymany jest w jakims wspoldzielonym gridzie pamieci, aczkolwiek tez gdzies serializowany (grupowo jakos raczej, niz pojedynczo)
- w kazdej chwili na podstawie polecenia, system moze "postawic" aktualny stan systemu obliczeniowego na ktorejs z maszyn oraz wspoldzielic go innym maszynom
- load balancer middle tier (za tym internet facing ktory uznalem za oczywisty) wewnetrzny non-proxy - informacje cos sie dzieje na jakiej maszynie i gdzie kierowac zapytania

Plusy:
- latwiejsze do skalowania, maszyny obliczeniowe mozna "stawiac" automatycznie pod obciazeniem na kazdej dowolnej maszynie
- redundancja opcjonalnie wysoka
Minusy:
- trudniej wydzielic maszyne do konkretnej roboty (jak np serializacja, albo poprostu okreslic, ktora maszyna ma dostac obliczenia) i trzeba sie poslugiwac jakims losowaniem zewnetrznym, zapewne
- troche bardziej pogmatwany dezajn, bardziej skomplikowany kod komunikacji i interakcji z load balancerem i maszynami

Pomysl 3 - cos pomiedzy, czyli maszyny api oddzielnie, trzymajace eventy w gridzie, oddzielni maszyny obliczeniowe, mozliwosc okreslanie ile maszyn ma miec jednoczesnie stan na sobie.

Dajcie znac, co na ten temat myslicie. Moze jakies propozycje implementacji/frameworka (sam myslalem Spring, Vertx+Guice, Scala, gridow zadnych jeszcze nie uzywalem, ale mysle terracotta, vertx uzywa hazelcasta)

Z gory dziekuje :-)
Piotr

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Jakies konstruktywne podpowiedzi?

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Sorry za szczerość, ale podpowiedź mam tylko jedną: nie pisz tego w Javie. Jeszcze jak dodasz Springa, to będzie w ogóle śmigało. Pisz w C, ew C++. Przetwarzanie trzeba zrobić w czymś, co działa szybko. Ew. gui zrób w JSP.

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Czesc Darek,

dzieki za odpowiedz.

Nie wiem, czemu w javie mialoby nie smigac, to obliczenia statystyczne, int zajmuje podobna (nie tyle samo?) miejsca w pamieci Javy co C. Spring ma problem robiania duzo poza elementami potrzebnymi do samego wykonania (pare watkow tam wisi i zjada troche ramu), do samych obliczen nie robi roznicy. Nie chcialbym zaczynac tez dyskusji pod tytulem "moja technologia jest lepsza... bla bla" bo zleca sie zaraz malo merytoryczni obywatele spolecznosci i kazdy bedzie musial swoje 5 nieistotnych groszy dodac ;-)

Z praktycznego POV, nawet jesli C/C++ mialoby byc szybsze tu do czegos (to chyba procesor wykonuje dzialania matematyczne, a nie jezyk) to aby osiagnac taki wysoki poziom abstrakcji jak klastrowanie, routing i obsluga API trzeba przejsc przez duzo "C problems" jak segfaulty itd, a na koniec dostajemy narzedzie, ktore jest problematyczne i nie ma komu utrzymac. Do pisania w C/C++ (i nauczenia sie go) nie mam niestety 2-3 lat, zeby taki projekt ogarnac. BTW szybkosc algorytmu to najczesciej funkcja programisty, a nie platformy...

GUI jest tu zupelnie niepotrzebne (po to jest API, zebym GUI mogl potem zrobic w czyms prostym jak PHP). Niestety nie mam do dyspozycji zastepu programistow C, wiec dla mnie w Javie "od zero do wykonanie" bedzie najkrotszy czas i najlepszy efekt.

Dzieki za rade i doceniam, ale zostane przy Javie.Ten post został edytowany przez Autora dnia 25.11.13 o godzinie 12:12

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Piotr J.:
Czesc,

chcialbym zaciagnac troche wiedzy madrzejszych ode mnie, odnosnie projektu architektonicznego systemu, ktorego budowa zostala mi powiezona.

Jest w trakcie projektowania (a w zasadzie przeprojektowywania) systemu sluzacego do oceniania. Stary system napisany byl w PHP/Mysql, co raczej bylo spowodowane potrzeba szybkiego posiadania prototypu, niz czyjas zlowrogoscia. O ile nie bylo to zbyt dobra decyzja, kod wyglada jak Perlowa miazga, bez slowa komentarza, pozwolilo to na spostrzezenie wielu potencjalnych problemow.

Nie rozumiem ... Próbujesz rozwiązać problem "miazgi w kodzie" czy "braku wydajności" ?

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Jako, ze projekt nie istnienie (bo jestem w fazie researchu) anii jedno ani drugie, chce opracowac cos co bedzie mozliwie future-proof, jako, ze znam sporo przyszlych problemow. Chodzi o wybor sposobu i bibliotek, ktore po najmniejszym oporze do tego doprowadza, a przynajmniej do pierwszej iteracji ;)

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Nie potrzebne Ci sa biblioteki a architektura...

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

OK, racja, potrzebna mi odpowiedz na pytania jakie zadalem ;-) Moze ktos ma inne sugestie/koncepcje?

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Czy można to zadanie uprościć do:
- zleć robotę do obliczenia i zwróć do klienta potwierdzenia odbioru zlecenia do obliczenia
- co jakiś czas zwracanie statusu obliczenia
- gdy zadanie jest "skonczone" zwrócenie do klienta jakiegoś rezultatu?
- czy poszczególne "zlecenia" w jakiś sposób zależa od siebie? czy też są zupełnie niezależne?

czyli że głównym przewidywanym problemem do rozwiązania jest skalowalność?Ten post został edytowany przez Autora dnia 26.11.13 o godzinie 17:46

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

dodatkowo:
- czy preferowana jest wysoka przepustowość systemu jako całości a "latencja" systemu jest na drugim miejscu?

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Piotr J.:
OK, racja, potrzebna mi odpowiedz na pytania jakie zadalem ;-) Moze ktos ma inne sugestie/koncepcje?

Jedyne pytanie jakie zadałeś brzmiało "Jakies konstruktywne podpowiedzi ?"; system opisałeś tak jakbyś chciał a nie mógł; chodzi o jakieś coś w rodzaju stumbleupon / digg'a ?

Bez "problem statement" nie dostaniesz _dobrej_ odpowiedzi.

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Jarosław S.:
Czy można to zadanie uprościć do:
- zleć robotę do obliczenia i zwróć do klienta potwierdzenia odbioru zlecenia do obliczenia
- co jakiś czas zwracanie statusu obliczenia
- gdy zadanie jest "skonczone" zwrócenie do klienta jakiegoś rezultatu?
- czy poszczególne "zlecenia" w jakiś sposób zależa od siebie? czy też są zupełnie niezależne?

czyli że głównym przewidywanym problemem do rozwiązania jest skalowalność?

@Jaroslaw
Dzieki za odp.

Nie wiem czy Cie dobrze zrozumialem dokladnie czy mowisz o calosc bo jesli tak, to niestety nie mozna. W zasadzie same obliczenie, jak pisalem bedzie w "turach" wiec co jakis czas wszystkie wartosci poprostu sie zmieniaja, jest to jednak zalezne od stanu ilosci eventow w systemie, a nie usera.

Taka ture mozna predstawic nastepujaco:

a) stan systemu poczatkowy, mamy duzo prac do oceni i zadnych zdarzen/parametrow z nimi zwiazanych (co przy kolejnej turze sie zmieni)
b) nanosimy wszystkie eventy oceniania na stan systemu - ta czesc bedzie trwala najdluzej (tydzien miesiac), tutaj zainteresowani jestesmy osiagnieciem niskiego opoznienia, jako, ze wybor sedziowanych prac dla zapytania bedzie wykonywany poprzez API, tak wiec niskie opoznienia = wiecej w tym samym czasie osob to moze zrobic. To kto i jaka prace dostanie do oceniania jest zalezne od siebie sekwencyjnie.
c) przeprowadzamy obliczenia - to moze trwac nawet minute (pomimo, ze raczej nie bedzie) wiec jestesmy tu dosc malo zainteresowani opoznieniem, przynajmniej przy tej fazie.

Calosc powtarza sie przez taka sesje kilkunastokrotnie.

Odnosnie tego, co ma byc oceniane - kazdy event zmienia stan systemu - takze zwykle nadanie do oceniania, a nie juz fakt wystawienia oceny.

Jarosław S.:
dodatkowo:
- czy preferowana jest wysoka przepustowość systemu jako całości a "latencja" systemu jest na drugim miejscu?

Opoznienie jest wazna tylko przy elementach zwaizanych z API i to tylko tych "reraktywnych", w zasadzie jedynym takim elementem bedzie pobieranie pracy do oceny.

Glownym problemem bedzie skalowalnosc systemu - nie obliczenia, ktore jest w zasadzie niepodzielne i musze je wykonac w 1 watku, ale jest za to stosunkowo nieskomplikowane.

Czesc drogi da sam event sourcing, wszystkie eventy moge serializowac, a w razie potrzeby przywrocic dowolny stan systemu, czyli potencjalnie mozna osiagnac pewna redundancje trzymajac, jak pisalem, eventy w gridzie/cachu, a w razie potrzeby odgrywanie na kolejnych maszynach tworzac klaster.

Jakbys pydania dawal numerowane, latwiej byloby sie odnosic niz wypunktowane. Dzieki.

@Jakub

Ciezko przestawic to na zasadzie typowej dla problemow GL: "nie dziala mi... " Widze, ze jest wiele podejsc do rozwiazania - nie wiem, ktore wybrac, a moze sa lepsze, niz te, ktore wymienilem?

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Piotr J.:

Szczegółów implementacyjnych nie podpowiem choćby z braku kompetencji ale przy podobnych problemach powinny Ci pomóc następujące technologie: MongoDB z wykorzystaniem MapReduce, Apache Haadop, Apache Camel rozważyłbym też wykorzystanie np. Heroku/Opeshift do szybkiego skalowania systemu tylko na moment obliczeń

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Czesc,

niestety rzucanie (dosc losowymi) haslami nie pomaga :-/

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Napisz więcej, dokładniej o algorytmie oceny prac. Jakie są dane wejściowe, wyjściowe ?
Dlaczego złożoność obliczniowa to aż O(n^2) ? Czy probowałeś używać profilera w celu zdiagnozowania co zajmuje nawięcej czasu ?
Myślałeś o zastosowaniu map&reduce ?

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Czesc,

algorytm oblicza takie rzeczy jak bledy statystyczne, jest bardzo sekwencyjny w naturze - nie jest tez problemem, ktory opisuje. Musi doprowadzic system do pewnego stanu co jakis czas - dzieki eventom, raczej nie problem, kwestia gdzie je trzymac jest drugorzedna, ale zapewnoe bedzie jakis nie-sqlowy data storage.

Zupelnie na luzie i bez hejta - nie rozumiem, czemu 2 osoga probuje tu wcisnac map/reduce. MR to rozproszony GROUP BY, a nie rozwiazanie na problemy skalowalnosci kazdego algorytmu ;-)Ten post został edytowany przez Autora dnia 26.11.13 o godzinie 22:22

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Piotr J.:
- 100k+ prac ocenianych
- API potrzebne do komunikacji (dodawanie prac, sedziow, ocenianie, okreslanie co oceniac, raportowanie), zapewne prosty JSON, moze tez XML (ale preferowalbym to pierwsze)

ile prac na minute ocenia jeden sędzia?

- 10-20k sedziow, przy jednym ocenianiu, czyli duzo requestow do API

pomijam API, jak wygląda proces oceny pracy przez jednego sędziego (w tym ile trwa) i ile takich procesów ocen odbywa się jednocześnie, na czym pracują sędziowie (czy prawda jest, że 1-20-K sędziów siedzi jednocześnie i ocenia?

Dajcie znac, co na ten temat myslicie. Moze jakies propozycje implementacji/frameworka (sam myslalem Spring, Vertx+Guice, Scala, gridow zadnych jeszcze nie uzywalem, ale mysle terracotta, vertx uzywa hazelcasta)

tyle na początek musiał bym wiedzieć...
jz

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

@Jarosław Ż.

Czesc, dzieki za odpowiedz.

a) sedzia nie ma ograniczenia/wymagan co do ilosci/min, ma tyle prac ile zdarzy ocenic (zalezy od jej dlugosci rzecz jasna), moze tez siedziec i robic to w dowolnej porze i czasie. Wchodzi tu kwestia planowania pod pesymistyczny scenariusz, czyli moze byc, ze w pewnym momencie (jakis mailing pod tytulem "zaczynamu oceniac!" moze byc bardzo duzo sedziow na raz) moze byc raptem duzo. Sam proces oceny jest dla nas arbitralny, bo intesuje nas jego efekt, czyli wywolanie metody z ocena i ID pracy

c) zawsze bedzie mniej sedziow niz ocen (nie mam pojecia ile, ale typujemy, ze ok 3-4 razy mniej)

d) wiele sesji moze byc wykonywanych niezaleznie od siebie (rozne prace, sedziowie, ilosci itd) na jednym systemie, tak wiec to, ze jedna sesja "spi" nie znaczy, ze inna nie bedzie wlasnie dawac "czadu"

Wszystko zrozumiale, moge wyjasnic dokladniej.

Co do kwesti architektury:

Myslalem o tym, zeby przeprowadzac sesje jednoczenie na X maszynach, tak jak w twierzeniu CAP, na pewnej podgrupie Y maszyn (bo na wszystkich to marnotrawstwo zasobow) w celu osiagniecia redundancji:
a) tworzymy sesje na Y maszyanach
b) eventy przez wspolny event bus routowane sa tylko do tych maszyn (+ do serializacji)
c) kazda maszyna ma ten sam stan sesji
d) do wyboru prac do oceniania (czyli sedzia pyta, co ma oceniac) mozna uzyc informacji z dowolnej maszyny z podgrupy Y zawierajacej sesje - tu widze problem rozproszonej synchronizacji, czyli jak spowodowac, ze kazda z sesji bedzie mial dokladnie ten sam stan, aby zapytanie moblo przyjsc i zostac wypelnione w dowolnej z nich
e) w razie odapdniecia maszyny z podgruby Y, przebudowujemy sesje do stanu aktualnego z zapisanych eventow na innej maszynie i otwieramy ja w routingu do obslugi ruchu

Co myslicie?

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Jak dla mnie cały czas ukrywasz kontekst (być może jakaś klauzula poufności) bez czego bujamy w obłokach, nie da się rozwiązać problemu ruchu drogowego ukrywając trasę i przekierowując rozmowę na konstrukcje silnika samochodu.

Nie wiem czy to sprawy w sądzie, klasówki w szkole podstawowej czy ogólnopolski cotygodniowy konkurs piękności na bazie zdjęcia modelki....

To co teraz napisałem to nie pretensja :), to tylko sugestia by może podpisać z kimś klauzulę poufności i zlecić ekspertyzę, na razie wygląda to jak zabawa w ciuciubabkę...

nie gniewaj się :)

Temat: Prosba o podpowiedz w sprawie projektu systemu rozproszonego

Nie gniewam, rozumiem. Rozumiem, ze chcesz doprowadzic do komercjalizacji pomocy, lecz to jest tylko moja inicjatywa i szukam rozwiazania technicznego, a nie biznesowego.

System jest przystosowany do oceny kazdej mozliwej pracy typowo ciezko kwantyfikowalnej (jak np testy wyboru), jak prace humanistyczne. Algorytm bazuje na http://en.wikipedia.org/wiki/Law_of_comparative_judgment ale jest oczywiscie poufny, aczkolwiek caly czas nie on jest problemem. Algorytm to seria obliczen "petla w petli" co daje nam O(n^2).

Zakladajac ze uzyje http://martinfowler.com/eaaDev/EventSourcing.html i bede mogl w dowolnej chwili doprowadzic do dowolnego punktu w systemie (oczywiscie zapisujac gdzies te eventy), problemem jest architektura systemu, chodzi mi raczej o to, aby ktos przedstawil mi "best practice" wzgledem moich pomyslow. Moze jakies biblioteki, ktore pomoga (oczywiscie nie rzucanie randomowymi hype'ami) z konkretnymi problemami jak rozproszony event bus, serializacja i zapus eventow, routing eventow itd, moze ktos ma zupelnie inna koncepcje?