On Wednesday, July 29, 2015 at 12:44:18 PM UTC+2, Tomasz Kaczanowski wrote:
> W dniu 2015-07-29 12:35, M.M. pisze:
> > On Wednesday, July 29, 2015 at 12:10:56 PM UTC+2, Piotr Chamera wrote:
> >> a "ekstremalna sytuacja", to rzeczywisty efekt działania takiego
> >> nieprzemyślanego systemu, który obserwowaliśmy w praktyce podczas
> >> wyborów.
> > Rozmawiamy o jednym elemencie tego systemu: zbieranie danych.
> >
> >>> Zaczęli projektować i skopali, jakby po prostu zrobili
> >>
> >> to nie jest proste (albo może precyzyjniej byłoby powiedzieć, że to nie
> >> jest wielki system [czyli w pewnym sensie prosty], ale jednak kilka
> >> rzeczy wymaga przemyślenia i zaprojektowania).
> > Jak pisałem kilka postów wcześniej: nie dziwię się że padło jako
> > całość. Dziwię się, że stracili dane, że trzeba było wprowadzać od
> > nowa, że czekali aż tak długo... i nie wiem jakie tam jeszcze były problemy.
> >
> >>
> >>> 1) połączenie
> >>
> >> obsługujemy tylko jedno połączenie jednocześnie? czy więcej? jeśli
> >> więcej, to ile? wszystkie 2500 jednocześnie (bo tak też może się
> >> zdarzyć)? jeśli jedno, to co jeśli klient się połączył i nie przesyła
> >> danych, a inni czekają? jeśli pula połączeń jest ograniczona, to co
> >> robimy z nadmiarowymi? itd...
> > Co masz na myśli, pisząc 'itd'? Nie znam specyfikacji tegoż systemu.
> > Uczepiłem się tych 2500 paczek danych na 3600 sekund, co nie wydaje się
> > zbytnio trudne. Jaki średni rozmiar miała paczka? Jeśli mamy ograniczoną
> > pulę połączeń, to co jest złego w odrzuceniu?
>
> Nie paczek danych a połączeń, to jakby co innego. Paczki danych to jakby
> najmniejszy składnik całości, kwestia jest przyjąć właśnie te połączenia
> i obsłużyć, a nie ile danych trzeba przesłać.
Tak, w ścisłym sensie masz oczywiście rację, ale jeśli połączenie (na
etapie zbierania danych) nie jest w głównej mierze 'paczką danych', to
może właśnie dlatego padło?



> >> na dalszych etapach masz podobne wybory, które wpływają na przyjęte
> >> rozwiązania i musisz wybrać tak, aby żadna sekwencja możliwych zdarzeń
> >> nie prowadziła do awarii...
> > Zgodzę się, że zgranie każdego, w pobieżnej ocenie 'łatwego', systemu w
> > jedną niezawodną całość, może okazać się bardzo trudne. Ale żeby padło na
> > etapie zbierania danych i straciło spójność, jakoś wydaje mi się dziwne.
>
> A oprogramowywałeś jakieś większe bazy danych? Coś co musi trzymać
> spójność i dane dla bezpieczeństwa powinny być w kilku tabelach
> zapisane? Coś do czego dobija się więcej osób jednocześnie?
Poczekaj. Mieszanka pobierania danych, parsowania, normalizacji, dbania
o spójność i zapisywania w bazie jest najgorszym kodem spageti w najbardziej
krytycznym miejscu.

Dla mnie zbieranie danych to zbieranie danych. Jest takie powiedzenie, że
najprostsze rozwiązania działają najlepiej. Jeśli nie miesza się zbierania
danych z całą resztą, to można zbieranie danych oprogramować w miarę
prostym, niezawodnym i wydajnym kodem. I to wszystko można zrobić na
bazie gotowych narzędzi, jak choćby mysqla.

A jeśli w jednym połączeniu chcemy obsłużyć 'wszystko', to co w tym dziwnego, że
nawet wybitna grupa specjalistów źle wyliczyła obciążenie i system padł, no i
padł w momencie bardzo krytycznym dla bezpieczeństwa danych.







>
>
> --
> Kaczus
> http://kaczus.cba.pl