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