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.