Przechowywanie tysiecy obiektow w pamieci, czy to jest okej?

Witam,

Jestem poczatkujacym programista, zrobilem narzedzie ktore polyka dane wejsciowe, robi na nich okreslone operacje po czym zrzuca na koniec wynik do pliku.

Zrobilem to na zasadzie wczytania danych wejsciowych jako obiektow, jedno zadanie = 1 obiekt, sa one wczytywane na 'kolejke' LinkedBlockingQueue (poniewaz workerów obrabiajacych dane jest wiele i pobieraja z tej kolejki kolejne elementy, obrobka 1 elementu trwa ok 1-5sek poniewaz odbywa sie przez siec/zewn API) po czym po otrzymaniu odpowiedzi z serwera wrzuca dany obiekt usupelniony o brakujace wartosci na kolejkę wyjsciową (tez LinkedBlockingQueue).

danych do obróbki moze byc czasami duzo np 15tyś, więc po uruchomieniu programu tworzone jest 15tys obiektow (kazdy ma kilka pól typu String oraz int wiec nic wielkiego), są one obrabiane i zrzucane do pliku z kolejki wyjsciowej.

Otóż kolega ktory z Javą nie ma doczynienia, ale programuje w Pythonie (nie znam jego punktu widzenia bo nie programowalem w pythonie) caly czas twierdzi ze nie powinienem przechowywac tyle danych w pamieci, tylko w bazie danych. Wiem jak to zrobić, tj wczytac wszystko do bazy danych np postgres, pozniej pojedynczo kazdy worker by zczytywal pojedyncze dane po czym je uzupelnial, a na koniec wygenerowac plik wynikowy z bazy danych, ale moje pytanie brzmi: czy ma to większy sens?
Czy faktycznie nie powinienem przechowywac tych obiektow w pamieci tylko w bazie danych? Czy zwiekszy, badz zmniejszy to wydajnosc?
O bezpieczenstwo danych się nie martwie bo i tam mam proces ktory zrzuca plik wynikowy co okreslony czas, zeby w razie jakiegos nieoczekiwanego wywalenia móc kontynuowac dalej itd.

Szukam w internecie jakis poradnikow.dobrych praktyk w tym temacie ale z marnym skutkiem.

Dzieki za ew podpowiedzi :)

Wg mnie nie ma sensu to co twoj kolega proponuje.

Obejrzyj sobie to, chyba pasuje :D (@jarekr000000, przyklad tych 2 rozwiazan to parafraza sytuacji z zycia?)

W pythonie ta baza danych tak samo nie ma sensu w tym przypadku jak w javie. Albo kolega uprawia cargo cult, albo musi sobie dokupić trochę ramu.

W tym przypadku na 15 tysiecy obiektów, jeśli pesymistycznie założymy, że na te kilka pól potrzeba 1024 bajty to musi sobie dokupić 15mb ramu.
Mam gdzieś w starym kompie (penium iii) taką kostkę 256mb. Więc starczy z zapasem. Mogę pożyczyć.

Właśnie już wszyscy Ci wystarczająco wyjaśnili - możesz nawet to pokazać koledze żeby się doedukował. Dorzucę jednak jedną wypowiedź Linusa Torvaldsa, którą myślę, że coraz bardziej trzeba wziąć sobie do serca:

Torvalds przypomniał jednocześnie, że jeszcze do niedawna wydajność warstwy sprzętowej systemów IT potrafiła podwajać się każdego roku. Takie tempo powoli się kończy i dlatego Torvalds ma nadzieję, że programiści wrócą teraz do czasów gdy bardziej dbali o wydajność oprogramowania zamiast zakładać- tak jak ma to niestety miejsce obecnie - że coraz to szybciej pracujący sprzęt załatwi za nich tę sprawę.

Owczywiście optymalizacja taką jak twój kolega zaprezentował nie ma żadnego sensu, ale generalnie o sensownych optymalizacjach możliwe, że będziemy musieli pamiętać o nich coraz bardziej i przejmować się nimi, bo tempo postępu powoli się zatrzymuje. Możliwe, że nasze komputery będą coraz bardziej wrażliwe na nasze mem i cpu leaki.

Nie wiem czy to Cię pocieszy, ale na jednym z systemów wciągaliśmy dane do pamięci, w peaku było 160 GB, wiec te 15k obiektów to nic... Największa ilość danych w pamięci jaką widziałem, to był system z 1TB RAMu pod bazę in-memory.

Zamiast martwić się czy to dużo czy mało, powinieneś pomyśleć czy potrzebujesz te dane przechowywać w trwałym składzie i co się stanie z Twoim przetwarzaniem jak braknie prądu (przysłowiowa pani sprzątaczka odpinająca kable od serwera, żeby odkurzacz podłączyć). Jak nic się nie stanie i odtworzysz sobie stan przetwarzania, to po co Ci baza?

Dane do bazy wpisuje sie jak potrzebujesz persystencji, tzn przechowywania ich długo i trwale. Jeśli są do dane na których operujesz to nie bardzo jest sens. Ba, w "prawdziwym życiu" takie dane z bazy i tak ładuje sie do cache w pamięci aplikacji i nie czyta ich non stop.

gdzieś w kościach czułem ze taka będzie odpowiedz, ale miło słyszeć potwierdzenie :) Dzieki za odpowiedzi!

P.S. własnie oglądam w/w wykład i swietnie się bawię :D

yarel napisał(a):

Zamiast martwić się czy to dużo czy mało, powinieneś pomyśleć czy potrzebujesz te dane przechowywać w trwałym składzie i co się stanie z Twoim przetwarzaniem jak braknie prądu (przysłowiowa pani sprzątaczka odpinająca kable od serwera, żeby odkurzacz podłączyć). Jak nic się nie stanie i odtworzysz sobie stan przetwarzania, to po co Ci baza?

W moim przypadku dane wynikowe sa zrzucane do pliku, tj cala kolejka wyjsciowa co krotki odstep czasu (2min), w razie nieoczekiwanego zamknięcia zaczynam od poczatku ale wczytujac przetworzone juz dane ktore sa automatycznie zrzucane do kolejki wynikowej, a operacje dzieją się tylko na nie przetworzonych obiektach. W najgorszym przypadku strace dane z 2minut, przy 15K danych jest to dosyc malo na co moge sobie pozwolic (do 100 zapytan, 2min pracy) i ponowić zapytania.

Raczej rzadko to się zdarza bo tylko w razie wlasnie 'wylaczenia pradu' bo wszystkie wyjatki ktore wyłapałem podczas testow (wystepujace po wystartowaniu workerow/ rozpoczeciu zapytan) uruchamiaja awaryjne generowanie wynikow wiec zwykle nie trace nic.

Zacząłem się teraz wczytywać w Java Persistance, nie slyszalem o tym tak szczerze :)