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.

do góry

On 2015-07-29, szemrany <s...@o...off> wrote:
>>> I skąd przekonanie o braku potrzeby szybkiego przelewu u Kowalskiego? Gdyby
>>> to była prawda nie istniałyby BlueCashe, Przelewy24, DotPaye, PayPale,
>>> Transferuje, Payu, zPay, PayByNet, ePrzelerwy, YetiPay i pewnie jeszcze
>>> jakieś. Zgodzisz się?
>>
>> Ja się nie zgodzę. Pieniądze z tych usług "płatności ekspresowych" nadal
>> idzie dwa-trzy dni. To nie o szybkość przelewu chodzi, tylko
>> o automatyzację księgowania wpłaty i natychmiastowe potwierdzenie
>> zlecenia przelewu.
>
> Możesz się nie zgadzać, ale:
> a) pieniądz idzie natychmiast, bo każdy z tych pośredników ma rachunki we
> wszystkich obsługiwanych bankach i klient robiąc przelew z np. ING na PKO
> robi de facto do ichniego ING, a oni ze swojego PKO do odbiorcy docelowego
> - online.

Idzie? Widziałeś od strony osoby sprzedającej? Bo ja w którymś momencie
widziałem warunki i stało, że idzie dwa-trzy dni.

> b) kompletnie mnie czy Kowalskiego jako klienta nie obchodzi mechanizm
> działania tylko efekt, robię przelew i po 15 sekundach jest u odbiorcy na
> koncie. Koniec tematu. Wszyscy zadowoleni.

Nie. Ciebie jako Kowalskiego nie interesuje kiedy u odbiorcy przelew
dojdzie. Ciebie interesuje, że automat odbiorcy natychmiast wie, że
zapłaciłeś (czyli nie ma czekania na reakcję człowieka następnego dnia
roboczego). I dokładnie to jest realizowane: sprzedający od razu dostaje
potwierdzenie i to potwierdzenie jest przetwarzalne maszynowo.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 2015-07-29 10:19, M.M. pisze:
> 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.

obawiam się, że właśnie tak zaprojektowali. To, że coś w laboratorium
trwa 1s, nie znaczy, że tyle będzie trwało w rzeczywistości, kwestia
jakości łącza, dodatkowo - zapis powinien być w transakcji, żeby nie
było wpadek, że dane się rozjeżdżają, bo wydarzyło się coś
nieprzewidzianego. Ze względu na to by kontrolować poprawność, powinny
się zapisać nie tylko dane, ale również kto je wysłał, o której godzinie
i jakie dane te dane MUSZĄ być spójne i dobrze by były to 2 rożne
dokumenty - tak jak jest to przyjęte w dobrych programach księgowych -
że jeśli rozjadą się dane w jednym miejscu - można ich poprawność
sprawdzić pobierając dane inaczej zapisane - do innych celów. Więc tu
nie chodzi o wydajność maszyny na której chodzi serwer - ale wydajność
łącza oraz projekt bazy. I tu posypały się obie rzeczy - najpierw nie
wytrzymało łącze, a następnie okazało się, że dane nie zostały zapisany
w sposób spójny, tak więc nikt nie wiedział, czy wszystko co zostało
wysłane zostało prawidłowo zapisane.


--
Kaczus
http://kaczus.ppa.pl

do góry

On Wednesday, July 29, 2015 at 10:51:04 AM UTC+2, Tomasz Kaczanowski wrote:
> W dniu 2015-07-29 10:19, M.M. pisze:
> > 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.
>
> obawiam się, że właśnie tak zaprojektowali.
Jaki konkretnie widzisz problem w tym schemacie?


> To, że coś w laboratorium
> trwa 1s, nie znaczy, że tyle będzie trwało w rzeczywistości,
Dlaczego w rzeczywistości nie można podpiąć kilku komputerów na
zapas?

> kwestia jakości łącza, dodatkowo -
Kilka łączy trzeba użyć.

> zapis powinien być w transakcji, żeby nie
> było wpadek, że dane się rozjeżdżają, bo wydarzyło się coś
> nieprzewidzianego.
No pewnie, ale to może nawet przyspieszać operacje. Bez jawnych
transakcji, każde zapytanie jest obejmowane transakcją.

> Ze względu na to by kontrolować poprawność, powinny
> się zapisać nie tylko dane, ale również kto je wysłał, o której godzinie
> i jakie dane te dane MUSZĄ być spójne i dobrze by były to 2 rożne
> dokumenty - tak jak jest to przyjęte w dobrych programach księgowych -
> że jeśli rozjadą się dane w jednym miejscu - można ich poprawność
> sprawdzić pobierając dane inaczej zapisane - do innych celów.
To wszystko też da się podciągnąć pod tamten najprostszy schemat.

> Więc tu
> nie chodzi o wydajność maszyny na której chodzi serwer - ale wydajność
> łącza oraz projekt bazy.
Ale w takim prostym schemacie można ekstremalnie powielać maszyny z
łączami.

> I tu posypały się obie rzeczy - najpierw nie
> wytrzymało łącze, a następnie okazało się, że dane nie zostały zapisany
> w sposób spójny, tak więc nikt nie wiedział, czy wszystko co zostało
> wysłane zostało prawidłowo zapisane.
Nie wiem co tam się stało, ale to co opisujecie, nie wydaje się jakoś
specjalnie trudne. Owszem, może być, gdy się dorzuca do tego schematu
jakieś ciężkie przetwarzanie... Przy przetwarzaniu wszystko może
pójść nie tak jak powinno.

W podobnej sytuacji stosuję liniową
tabelę. Dane są tylko zapisywane. Potem dane są traktowane jak
kolejka do przetwarzania. Jeśli przy przetwarzaniu narobię błędów, to
wynik skasuję, poprawię błędy i odpalam skrypt na nowo. Ostatnio
skorygowałem w ten sposób błąd który zaburzał wyniki od kilku miesięcy.

do góry

On 2015-07-29, M.M. <m...@g...com> wrote:
>> To, że coś w laboratorium
>> trwa 1s, nie znaczy, że tyle będzie trwało w rzeczywistości,
> Dlaczego w rzeczywistości nie można podpiąć kilku komputerów na
> zapas?

Bo ani systemy rozproszone, ani nawet redundancja w ramach jednej sieci
(jeden segment ethernetowy) nie działają w ten sposób. Nie da się po
prostu rzucić dwa razy więcej maszyn i nagle przyjąć dwa razy większy
ruch, jeśli system nie został do tego specjalnie zaprojektowany.

>> zapis powinien być w transakcji, żeby nie
>> było wpadek, że dane się rozjeżdżają, bo wydarzyło się coś
>> nieprzewidzianego.
> No pewnie, ale to może nawet przyspieszać operacje. Bez jawnych
> transakcji, każde zapytanie jest obejmowane transakcją.

Nie rozumiesz do czego służą transakcje, prawda? Zresztą niby skąd.
Jakiś czas temu się przyznałeś, że nie jesteś programistą i właściwie to
się na tym nie znasz na poziomie zawodowym.

Transakcje służą do zapewnienia, że *dwa lub więcej* zapisów są albo
wykonane w komplecie, albo nie wykonane wcale.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Wednesday, July 29, 2015 at 11:13:46 AM UTC+2, Stachu 'Dozzie' K. wrote:
> On 2015-07-29, M.M. wrote:
> >> To, że coś w laboratorium
> >> trwa 1s, nie znaczy, że tyle będzie trwało w rzeczywistości,
> > Dlaczego w rzeczywistości nie można podpiąć kilku komputerów na
> > zapas?
>
> Bo ani systemy rozproszone, ani nawet redundancja w ramach jednej sieci
> (jeden segment ethernetowy) nie działają w ten sposób. Nie da się po
> prostu rzucić dwa razy więcej maszyn i nagle przyjąć dwa razy większy
> ruch, jeśli system nie został do tego specjalnie zaprojektowany.
Nie zrozumiałeś o czym jest ta rozmowa, wróć i doczytaj.

>
> >> zapis powinien być w transakcji, żeby nie
> >> było wpadek, że dane się rozjeżdżają, bo wydarzyło się coś
> >> nieprzewidzianego.
> > No pewnie, ale to może nawet przyspieszać operacje. Bez jawnych
> > transakcji, każde zapytanie jest obejmowane transakcją.
>
> Nie rozumiesz do czego służą transakcje, prawda? Zresztą niby skąd.
> Jakiś czas temu się przyznałeś, że nie jesteś programistą i właściwie to
> się na tym nie znasz na poziomie zawodowym.
>
> Transakcje służą do zapewnienia, że *dwa lub więcej* zapisów są albo
> wykonane w komplecie, albo nie wykonane wcale.
Jak wyżej, czytaj ze zrozumieniem.

do góry

On 2015-07-29, M.M. <m...@g...com> wrote:
> On Wednesday, July 29, 2015 at 11:13:46 AM UTC+2, Stachu 'Dozzie' K. wrote:
>> On 2015-07-29, M.M. wrote:
>> >> To, że coś w laboratorium
>> >> trwa 1s, nie znaczy, że tyle będzie trwało w rzeczywistości,
>> > Dlaczego w rzeczywistości nie można podpiąć kilku komputerów na
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^
>> > zapas?
>>
>> Bo ani systemy rozproszone, ani nawet redundancja w ramach jednej sieci
>> (jeden segment ethernetowy) nie działają w ten sposób. Nie da się po
>> prostu rzucić dwa razy więcej maszyn i nagle przyjąć dwa razy większy
>> ruch, jeśli system nie został do tego specjalnie zaprojektowany.
> Nie zrozumiałeś o czym jest ta rozmowa, wróć i doczytaj.

Nie zrozumiałeś co sam napisałeś. Wróć i doczytaj.

>> >> zapis powinien być w transakcji, żeby nie
>> >> było wpadek, że dane się rozjeżdżają, bo wydarzyło się coś
>> >> nieprzewidzianego.
>> > No pewnie, ale to może nawet przyspieszać operacje. Bez jawnych
>> > transakcji, każde zapytanie jest obejmowane transakcją.
>>
>> Nie rozumiesz do czego służą transakcje, prawda? Zresztą niby skąd.
>> Jakiś czas temu się przyznałeś, że nie jesteś programistą i właściwie to
>> się na tym nie znasz na poziomie zawodowym.
>>
>> Transakcje służą do zapewnienia, że *dwa lub więcej* zapisów są albo
>> wykonane w komplecie, albo nie wykonane wcale.
> Jak wyżej, czytaj ze zrozumieniem.

No to wyjaśnij, gdzie się rozminąłem z tematem rozmowy? (Bieżącym
tematem!) Bo rzucać "nie rozómisz; czytaj ze zrozumieniem" bez żadnego
uzasadnienia jest łatwo.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Wednesday, July 29, 2015 at 11:50:19 AM UTC+2, Stachu 'Dozzie' K. wrote:
> On 2015-07-29, M.M. wrote:
> > On Wednesday, July 29, 2015 at 11:13:46 AM UTC+2, Stachu 'Dozzie' K. wrote:
> >> On 2015-07-29, M.M. wrote:
> >> >> To, że coś w laboratorium
> >> >> trwa 1s, nie znaczy, że tyle będzie trwało w rzeczywistości,
> >> > Dlaczego w rzeczywistości nie można podpiąć kilku komputerów na
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^
> >> > zapas?
> >>
> >> Bo ani systemy rozproszone, ani nawet redundancja w ramach jednej sieci
> >> (jeden segment ethernetowy) nie działają w ten sposób. Nie da się po
> >> prostu rzucić dwa razy więcej maszyn i nagle przyjąć dwa razy większy
> >> ruch, jeśli system nie został do tego specjalnie zaprojektowany.
> > Nie zrozumiałeś o czym jest ta rozmowa, wróć i doczytaj.
>
> Nie zrozumiałeś co sam napisałeś. Wróć i doczytaj.
>
> >> >> zapis powinien być w transakcji, żeby nie
> >> >> było wpadek, że dane się rozjeżdżają, bo wydarzyło się coś
> >> >> nieprzewidzianego.
> >> > No pewnie, ale to może nawet przyspieszać operacje. Bez jawnych
> >> > transakcji, każde zapytanie jest obejmowane transakcją.
> >>
> >> Nie rozumiesz do czego służą transakcje, prawda? Zresztą niby skąd.
> >> Jakiś czas temu się przyznałeś, że nie jesteś programistą i właściwie to
> >> się na tym nie znasz na poziomie zawodowym.
> >>
> >> Transakcje służą do zapewnienia, że *dwa lub więcej* zapisów są albo
> >> wykonane w komplecie, albo nie wykonane wcale.
> > Jak wyżej, czytaj ze zrozumieniem.
>
> No to wyjaśnij, gdzie się rozminąłem z tematem rozmowy? (Bieżącym
> tematem!) Bo rzucać "nie rozómisz; czytaj ze zrozumieniem" bez żadnego
> uzasadnienia jest łatwo.
Rozminąłeś się w dwóch lub trzech momentach w jednym poście, za
dużo pisania. Poza tym szkoda czas na tłumaczenie komuś, kto
jeszcze nigdy poprawnie nie zrozumiał mojej wypowiedzi.

>
> --
> Secunia non olet.
> Stanislaw Klekot

do góry

W dniu 2015-07-29 o 10:19, M.M. pisze:
> 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ę?

moje ,,pomyśleli", to np. twoje ,,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." więc robimy na pałę...

a ,,ekstremalna sytuacja", to rzeczywisty efekt działania takiego
nieprzemyślanego systemu, który obserwowaliśmy w praktyce podczas
wyborów.

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

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

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

do góry

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?


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

Ja miałem tego typu problemy, gdy łączyłem zbieranie danych z ich opracowaniem.
Gdy te etapy rozdzielam, to ilość problemów na etapie pobierania danych
spadła prawie do zera. Z dalszym opracowaniem danych też mam nie mało
problemów, ale cóż, każdemu zdarzają się błędy w kodzie.

Pozdrawiam

do góry