Zastosowałem tę metodę na takim jednym białym misiu poznanym tutaj na forum.
Jego raport zrył mi beret i nie pozostało nic innego jak napisać system od początku bo poprzednia wersja nie nadawała się do sprzedaży klientom z biznesowego punku widzenia patrząc. A ten biały miś wie o czym mówi bo on żyje ze sprzedawania projektów klientom.
Świat profesjonalistów i ekspertów. Początkowo zadajesz podstawowe pytania niczym pokorny Sokrates, na które otrzymujesz niezrozumiałe odpowiedzi. Stopniowo stajesz się bardziej wnikliwy, ale niestety Eutyfron nie ma już dla Ciebie czasu.
Spore ryzyko w większości przypadków, że jednak zostanie przepchnięte coś, co nie powinno się tam znaleźć. Constraints mogą być warte swojej ceny.
Też się nie znam.
Wozidłem można jeździć do sklepu, a hatchback’iem wozić urobek. Skoro jedno i drugie ma koła…
Głodzenie nie jest obojętne. Architektura współczesnych procesorów sprzyja umiejącym zsynchronizować posługiwanie się sztućcami, przeterminowana żywność leci do kosza.
Brak rzetelności nie wynika z liczby zaangażowanych osób.
Sedno jest gdzie indziej. Nie o to chodzi “czym”. Clue jest, że jest to robota. A każda praca wymaga czasu i zasobów. To czy ktoś je zupę widelcem to już inna para kaloszy, liczy się to, że je lub przynajmniej próbuje z mniejszymi lub większymi sukcesami 
Jakość kodu a brak rzetelności to dwie różne rzeczy. Czym innym jest kod nieoptymalny, a czym innym jest kod pełen błędów, uszyty tylko, aby działał i przeszedł testy.
Za co klient płaci?
No to taki dostał jakie wprowadził metryki 
o wspólnym mianowniku stawianym (albo i nie) na kancie koperty. Rzetelność rozpieprza wyniki kwartalne po stronie właściciela operatora klawiatury.
“kod bez błędów” zalicza się do non-functional-requirements a te tnie się w pierwszej kolejności. Z drugiej strony nie widziałem jeszcze postulatu “kod bez błędów” nawet po stronie nfr projektu. Pewnie mało jeszcze widziałem.
miało być tanio to jest.
za funkcjonalność.
no właśnie że nie.
Zapuściłem długi test w którym nakarmiłem bazę danych 13 milionami transakcji. Procesor mielił twardzielem przez lekko ponad dobę, baza danych urosła mi od tego z zera na 16 GB a średnia wydajność wyniosła 133 transakcje na sekundę.
Przy czym to nie jest tak że transakcje są coraz wolniejsze:
na początku rzeczywiście do bazy danych wpisywane są 195 transakcje na sekundę ale od pewnego momentu wydajność systemu (warunkowana wydajnością dysku zapewne, bo czegóż by innego) spada do ok. 130 transakcji na sekundę i pozostaje na tym poziomie do końca testu.
Transakcje wyglądają klasycznie jak na bazę danych, tzn. przeczytaj dane z tabeli, przemiel je, zapisz z powrotem i rozpocznij od początku pętlę. I tak 13 milionów razy pod rząd.
Ponieważ używam SSD do przechowywania na nim bazy danych doszedłem do wniosku że na początku dane zapisywane są do kości “demo” dysku SSD służących do obsługi testów wydajności zapuszczanych przez użytkowników a po ich zapełnieniu bloki przenoszone są do kości schowanych przed użytkownikami, to znaczy wolnych ale za to tanich. I że proces przepisywania z kości szybkich do wolnych w tle nie wyrabia kiedy bombarduję dysk coraz to nowymi danymi do zapisu.
Cooorwa mać. To ile musiałby kosztować SSD żeby był cały zrobiony z komórek pamięci o wydajności i charakterystykach części wlutowywanej dla oszukania klientów ?
Coooo?!
Co Ty mi tu…
Kolizje na macierzach szybciej lecą, a 16GB mieści się w ramie (o ile jest to obraz Matejki). Jakie 133 operacje na sekundę? Na tosterze to odpalałeś? Bo na programatorze od pralki powinno iść szybciej.
Transakcje w bazie danych w znaczeniu ACID. Każda z nich modyfikuje 135 wierszy w różnych tabelach tej samej bazy danych.
na laptopie. Nienajnowszym, nienajstarszym. Ma dysk nvme oraz i7 z ośmioma rdzeniami taktowanymi 1,9 GHz. Laptop ma też sprzętowy szyfrator AES którego używam do obsługi zaszyfrowanego AESem dysku SSD.
osiem macierzy…
ile kloców znaczących w wierszu?
To ja mówię o jednym rdzeniu na i5 bo nic mocniejszego nie używam.
Syndrom Medyka. Dysk SSD musi być. Najszybciejszy.
Bo macierz x wirujących dysków z redundancją, odzyskiem, backupem, wymianą w tle i prędkością x razy większą i kosztem x razy mniejszym jest be do być może ważnych transakcji.
Szkoda prądu na taki test.
Hola hola ja mam sprzętowy RAID z dysków twardych HDD (owszem klasy enterprise,kazdy dysk 24 Terabajty, ale CMR )
W SSD zanim padnie komórka to najczęściej ucegla się kontroler
Na osobnym redundowanym zasilaczu?
W skrzynce qnap. Osobno. Listwa zasilająca jest.
Na pytanie po co tak odpowiadam: bo wolno, bo lubię, bo tak już mam.
Czasami się zastanawiam ile to tysięcy razy przewyższa potrzeby. Bo nawet jest najmocniejszy obecnie procek dla graczy i AMD x870e no i SSD na PCiE 5.0 też jest.
Niektórzy mają swoje schizy niegroźne dla otoczenia groźne dla portfela.
taki laptop kupiłem przed pandemią jeszcze. Lekko przechodzony był już wtedy, dzisiaj przechodzony jest bardziej. No to nie będę w używanego laptopa wkręcał kręcioła skoro ma już ten nvme i ssd. To niech sobie chodzi tak jak z Chin skręcony przypłynął.
Do pisania i testowania amatorskiego kodu ?
Kupiłbyś dzieciakowi Porsche żeby nauczył się na nim prowadzić samochody ?
ważne to one będą jak będą je odpalać klienci. Na razie odpalam je hobbystycznie bo testuję co wklepałem w klawiaturę. Jak klienci uznają że im się podoba to sypną kasą, za kasę kupi się macierze, kontrolery, szafy i profesjonalne dyski.
okazało się że średnia prędkość pojedynczej transakcji pozostaje stała (z opisywanym wyżej wahnięciem z winy konstrukcji dysku SSD jak zakładam) w funkcji wzrostu rozmiaru bazy danych. To dla mnie bardzo ważne. Bardzo.
Za dużo widziałem profesjonalnego oprogramowania które zwalniało wraz z puchnącą bazą danych. Widziałem również payrolle ludzi odpowiedzialnych za dostarczanie tego badziewia i … a dość już tego klepania się po własnych pagonach. Da się odkleić od siebie delty rozmiaru baz danych i ich wydajności transakcyjnej. A że amator to pisze i doświadczalnie udowodnił … no cóż.
Mój kod działa tak samo szybko od zera do 16 GB i od zera do 13 mln transakcji, zakładam że wyżej też będzie liniowo hulać aż walnie w jakiś limit typu koniec zakresu danych, brak miejsca na dysku, limit wielkości pliku w OSie itd. Na razie wysycam i maltretuję to co mam pod ręką. Jak klienci zapłacą za więcej to będę wysycał większe dyski i piłował szybsze kontrolery.
Na razie silnik systemu w bazie danych działa tak jak teoretycy zakładają i w szkołach wykładają a zawodowi programiści za ciężki hajs nie dowożą. Ten miś jest na miarę moich możliwości.
Mam ten problem więc chunkuję i swapuję po kawałku.
Sprawdzaleś swapfile’a czy Ci też puchnie?
Czy najbardziej obciążona tabela cała mieści się w ramie? A może trzeba rozdzielić niektóre tabele na mniejsze, aby mnie bylo swapowania ramu?
Moze zamiast pojedynczej tabeli wynikowej zrzucać wynika do tabel czesciowych po kilkanaście-kilkadziesiat tysięcy rekordów?
Wszystko na ramie, tylko to są tabele triangli z normalami pod kolizji. Ekstrakty z vertex bufferów. Ale jechanie po bazie danych i odhaczanie “ty nie, ty też nie, ty… przyjrzyjmy się… nie” powoduje, że trzeba dawać tego aptecznie. Sam rozmiar chunka jest problemem, bo później z tego referuję sobie lokalne i dopiero mielę kawałek godny uwagi.
Więc sobie zrobiłem przeładowywane chunki. Swap całych 8GB z groszami zajmuje jakieś 1.2sekundy.
Pytania były bardziej do @gruby, bo przy wysyceniu dane muszą biegać non stop ram<->ssd.
Pytanie pomocnicze: ile TBW tego ssd zostało po takiej sesji? 16G końcowe może oznaczać, że tam terabajty ganiały w tę i z powrotem
nie puchnie.
Teoretycznie jeszcze tak. Transakcja zapisuje swoje wyniki do czterech tabeli "insert"ami modyfikując piątą tabelę "update"ami.
na razie baza danych jest w sumie mniejsza niż ilość RAM. Więc będę musiał odpalić dodatkowy test żeby nadmuchać bazę danych powyżej rozmiaru RAM i zobaczyć czy laptop zaczął swapować. Dobry punkt !
To jeszcze nie jest ten punkt rozwoju projektu, na razie największa tabela zawiera 26 milionów rekordów po stworzeniu 13 milionów transakcji i waży 7.2 GB bo przechowywana jest w dedykowanym dla niej pliku.
jak już wspomniałem wcześniej laptop jest stary
i oram nim z premedytacją.
to ryzyko istnieje. Dlatego na razie bez macierzy, kontrolerów i inwestycji w hardware. Testuję na używanym sprzęcie. Jak padnie SSD to go wymienię bo laptopa nie wyrzucę - za dobry jest. Zaorany SSD to w tym układzie collateral. Backup jest.
Jeśli ganiasz to pod windą, to możesz jeszcze przerzucić scheduler jądra z user na services. Wtedy baza będzie miała pierwszeństwo do procka od aplikacji użyszkodnika i nie będzie musiała czekać, czy użyszkodnik czegoś nie chce odpalić.