Dnia 29.07.2015 M.M. <m...@g...com> napisał/a:
> 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 ;-)

Oczywiście zgadzam się, że dało się to zrobić lepiej, no i ostatecznym
sędzią jest rzeczywistość - system nie był dobrze zrobiony bo nie spełnił
zadania i trzeba było wrócić do liczenia "na piechotę". Niemniej jednak
uważam, że o ile jest to w miarę proste zadanie, to nie jest to zadanie
trywialne i jest kupa "haczyków" na których projekt może się wyłożyć (mimo,
że będzie działał prawidłowo podczas testów w małej skali). Moim zdaniem
podstawowym błędem był niedoczas - trzy miesiące na znalezienie zespołu (tu
był ponoć jednoosobowy - ile w tym prawdy, nie wiem), analizę zagadnienia,
zaprojektowanie, napisanie, przetestowanie, oddanie wersji testowej
klientowi, naniesienie poprawek, testowanie, wdrożenie, przeszkolenie ludzi
itd. to na prawdę nie jest dużo czasu (zwłaszcza dla mniej doświadczonego
zespołu).

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

Też jestem zdania, że można to było lepiej. Poza tym ponoć okazało się, że
w systemie była kupa wszelakiej maści dziur i niedociągnięć. Po prostu ktoś
do tego źle podszedł (albo nie umiał, albo zbagatelizował sprawę). Takie
coś jak wybory samorządowe, to bez problemu nawet mySQL by uciągnął bo w
przypadku wyborów "transakcyjność" jest zapewniana przez obieg dokumentów,
no a kolejkowanie tasków to ma chyba każdy współczesny serwer aplikacji
więc pomysł o którym piszesz jest do zrealizowania praktycznie "za darmo"
(i przy okazji unikamy zarzynania macierzy dysków wielodostępem, zresztą
dla takiej ilości danych jak wybory, to można zbudować macierz z ramdysku i
dysków fizycznych - odczyt danych "natychmiastowy").

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

No oczywiście lepiej w ciągu godziny niż wcale :D