Kod na 1 corowym z 2GB RAM VPSie i bazą w pgsql działa ok 6-10 minut i jest dla mnie nie akceptowalny szczególnie dla takiej ilości danych. Niestety z zewnętrznego źródła dostaję zawsze komplet UIDów (teraz ok 100 tys.) nieważnych dokumentów bez żadnych dodatkowych znaczników. Chcę wyfiltrować dokumenty do usunięcia i je usunąć skoro trafiły na czarna listę i zapisać czarną listę dla rozpropagowania dalej identyfikatory dokumentów, które zostały usunięte.
@JacobTheLiar: Metoda isDocumentInvalid do poprawy. Dla Seta są szybsze sposoby na sprawdzenie czy obiekt się w nim znajduje niż zamiana na strumień i przechodzenie po wszystkich elementach aż się nie znajdzie szukanego.
@JacobTheLiar: Te invalidDocuments dostajesz z jakiejś bazy? Query w SQLu będzie nieporównywalnie szybsze niż operacje na streamie. Jeśli możesz przesuń to do warstwy persystencji.
@JacobTheLiar: Generalnie tak, choć i tak wszystko zależy od implementacji hashCode i equals. W twoim przypadku nie ma natomiast potrzeby łamania zasad i: - albo zmapujesz sobie Set do zbióru Uid i w nim będziesz szukał - albo do contains przekażesz new InvalidDocument(document.getUid())
@63274682374: niestety zmiana tego pogorszyła sprawę i jest teraz 13 minut filtrowania. klasy hashe i equalsy mają. Pobieranie z bazy trwało niecałą sekundę.
@JacobTheLiar: a i wd mnie, Twoja metoda isDocumentInvalid jest w porządku. Drugie pytanie jak wygląda ta metoda: removeInvalid.removeInvalidDocuments(toDelete);
Wd mnie powinien iść sql który wygląda tak: delete * from documents d where d.id in (i tutaj id wszystkich documentów do wywalenia). Druga rzecz invalidDocumentRepository.saveAll(toAddInvalidDocuments) powinna być batchem.
@JacobTheLiar: > Pobieranie z bazy trwało niecałą sekundę. Raczej nie. Operacje bazodanowe są tutaj najbardziej czasochłonne. Najprawdopodobniej źle mierzysz czas wykonania, nie bierzesz pod uwagę tego co jest dociągane lazy itp... Zmiana, którą wprowadziłeś na pewno przyspieszyła samo wyszukiwanie. Jedyne co mogło pogorszyć wydajność to tworzenie nowego obiektu i to tylko jeśłi masz jakiś kod w
@63274682374: a co jest złego w tym sprawdzeniu? Wykonuje się to liniowo, porównuje hashe 2 stringów. I kończy kiedy znajdzie. Dokładnie robi to samo co metoda contains z listy.
Dokładnie robi to samo co metoda contains z listy.
@saquas: Dokładnie... tylko, że tu mamy Set!. Wyszukiwanie w nim tak jakby to była lista to o wiele gorsza złożoność. Tym bardziej, że ze sprawdzanych 50k obiektów znajduje kilka/kilknaście obiektów w zbiorze 100k. Oznacza to, że ok 50k razy iterujesz po wszystkich 100k obiektów... a to już strasznie dużo.
@saquas: @63274682374: wszystko ekstra, mimo wszystko dla takiej ilości danych powinno lecieć max kilka sekund przy tej konfiguracji serwera, a nie kilka-kilkanaście minut. dzięki sugestii @63274682374
Operacje bazodanowe są tutaj najbardziej czasochłonne.
zabrałem się za dokładne analizowanie serwera i to on okazał się winny całemu zamieszaniu (założę osobny wątek, na jego temat). Okazało się, że po ostatnim włamie na mój serwer VPS ktoś coś zostawił co żarło całe
Kod na 1 corowym z 2GB RAM VPSie i bazą w pgsql działa ok 6-10 minut i jest dla mnie nie akceptowalny szczególnie dla takiej ilości danych.
Niestety z zewnętrznego źródła dostaję zawsze komplet UIDów (teraz ok 100 tys.) nieważnych dokumentów bez żadnych dodatkowych znaczników.
Chcę wyfiltrować dokumenty do usunięcia i je usunąć skoro trafiły na czarna listę i zapisać czarną listę dla rozpropagowania dalej identyfikatory dokumentów, które zostały usunięte.
- albo zmapujesz sobie Set do zbióru Uid i w nim będziesz szukał
- albo do contains przekażesz new InvalidDocument(document.getUid())
return invalidDocuments.contains(new InvalidDocument(document.getUid()));Jak nie takie szybkie pytanie: jak wygląda metoda: invalidDocumentRepository.saveAll(toAddInvalidDocuments)?
Wd mnie powinien iść sql który wygląda tak: delete * from documents d where d.id in (i tutaj id wszystkich documentów do wywalenia). Druga rzecz invalidDocumentRepository.saveAll(toAddInvalidDocuments) powinna być batchem.
@saquas: serio?
@JacobTheLiar: > Pobieranie z bazy trwało niecałą sekundę.
Raczej nie. Operacje bazodanowe są tutaj najbardziej czasochłonne. Najprawdopodobniej źle mierzysz czas wykonania, nie bierzesz pod uwagę tego co jest dociągane lazy itp...
Zmiana, którą wprowadziłeś na pewno przyspieszyła samo wyszukiwanie. Jedyne co mogło pogorszyć wydajność to tworzenie nowego obiektu i to tylko jeśłi masz jakiś kod w
ogólnie każde repository jest springowe/hibernate. podobnie saveall i delete all z JpaRepository.
rozdzieliłem pobieranie i filtrowanie
@saquas: Dokładnie... tylko, że tu mamy Set!. Wyszukiwanie w nim tak jakby to była lista to o wiele gorsza złożoność. Tym bardziej, że ze sprawdzanych 50k obiektów znajduje kilka/kilknaście obiektów w zbiorze 100k. Oznacza to, że ok 50k razy iterujesz po wszystkich 100k obiektów... a to już strasznie dużo.
dzięki sugestii @63274682374
zabrałem się za dokładne analizowanie serwera i to on okazał się winny całemu zamieszaniu (założę osobny wątek, na jego temat). Okazało się, że po ostatnim włamie na mój serwer VPS ktoś coś zostawił co żarło całe
źródło: comment_16043868198q24jhmz2Q6bBiGfm51VvT.jpg
Pobierzśrednie pobieranie danych z bazy - 11ms
średnie czasy filtrowania