On Wednesday, July 29, 2015 at 3:47:28 PM UTC+2, Pit wrote:
> Dnia 29.07.2015 M.M. napisał/a:
> > On Wednesday, July 29, 2015 at 9:54:06 AM UTC+2, Piotr Chamera wrote:
> >> W dniu 2015-07-29 o 09:42, M.M. pisze:
> >> > On Wednesday, July 29, 2015 at 7:37:32 AM UTC+2, Tomasz Kaczanowski wrote:
> >> >> Jeśli źle zaprojektowano bazę, to właśnie nie wytrzymała obciążenia i
> >> >> dodatkowo nie potrafiła sobie poradzić z sytuacją ekstremalną i dane
> >> >> były niespójne.
> >> > Ale po kiego tutaj jakoś szczególnie projektować? Nie było żadnej
> >> > ekstremalnej sytuacji.
> >>
> >> Tak "pomyśleli", nie zaprojektowali i mieliśmy "ekstremalną sytuację"...
> > Przez 1s można trochę danych i siecią przesłać, i na dysku zapisać, nie
> > wspomniawszy o zapisach w buforach RAM. Zapytań było 2500. Czas ktoś
> > oszacował na 1h. Średnio wychodzi jedno zapytanie na 1s. Gdzie widzisz
> > ekstremalną sytuację?
> >
> > Zaczęli projektować i skopali, jakby po prostu zrobili
> > 1) połączenie
> > 2) transfer
> > 3) zapis
> > 4) rozłączenie
> > To pewnie by wytrzymało, zwłaszcza na kilku komputerach.
>
> Niestety to tak banalnie nie działa, bo jest do tego jeszcze ustawa o
> ordynacji wyborczej. W skrócie protokół wędruje mniej więcej tak:
> 1) Obwód robi swoje podsumowanie głosów i wysyła do "centrali" protokół
> roboczy.
> 2) Centrala weryfikuje dane i wysyła do obwodu swój protokół jakie dane
> odebrała od obwodu i ewentualne poprawki.
> 3) Jeśli były jakieś błędy/poprawki lub dane odebrane nie są zgodne z
> danymi wysłanymi przez komisję, to powrót do punktu 1)
> 4) Komisja obwodowa zatwierdza protokół otrzymany "z centrali" że jest
> wszystko ok, robi wydruk protokołu i składa na nim swoje podpisy (koniec
> drogi elektronicznej).
>
> To nie jest zwyczajna akumulacja danych (typu wyślij i zapomnij), bo do
> takich rzeczy w ogóle nie trzeba by było bazy "live",
Wszystkie etapy które Ty przytoczyłeś, można rozwiązać tak jak ja
zaproponowałem. Na każdym etapie zadania można wrzucać do kolejki.
Na każdym etapie jakiś demon może kolejne zadania z kolejki wyciągać.
Na każdym etapie można system zapytać, czy jest już gotowa odpowiedź.
Oczywiście takie rozwiązanie nie zadziała live. Ktoś wyśle dokument i
będzie musiał kilka razy zapytać serwer czy jest odpowiedź. Może
otrzymać odpowiedź, że przed jego zadaniem stoi w kolejce 300 innych
zadań, więc pójdzie na kawę. Lepsze takie rozwiązanie, niż całkowity
pad serwera, no chyba że ten pad nazywasz systemem live ;-)




> wystarczyłby system
> podobny do e-maili (gdzie serwer sobie ustawia kolejeczkę i w swoim tempie
> wszystko przetwarza). To nie jest tak, że jak teraz wcisnę "SEND" to mogę
> czekać godzinkę aż serwer przemieli,
No ale zdaje się, że czekali dłużej niż godzinę i w końcu jakoś dali radę.
Gdyby jeden demon odbierał i kolejkował, drugi wykonywał obliczenia, trzeci
odpowiadał, to przynajmniej by nie doszło do rozwalenia danych i przynajmniej
swoje dane by się udało wysłać. Jeśli jakiś algorytm obliczający się nie
wyrabia, to w każde rozwiązanie będzie się muliło. Więc chociaż niech
transfery przebiegają sprawnie.

> bo taką ma kolejkę, wynik powinien być
> zwrcony w rozsądnym czasie (maksymalnie kilka sekund). No i tych zapytań do
> bazy jest znacznie więcej niż jednorazowe INSERT INTO a i obwodów jest
> więcej niż ktoś tam wyżej podał.
Ja też uważam że lepiej w ciągu kilku sekund niż w ciągu godziny. Ale
zapewne i Ty się zgodzisz ze mną, że lepiej w ciągu godziny niż w ciągu 20 godzin
plus pad serwera w punkcie krytycznym dla spójności danych.


Pozdrawiam