Cześć, za pewne to częsty problem w firmach.
Mam bardzo dużą bazę danych, z których użytkownik może sobie wygenerować raport.
Zastanawiam się jak to dobrze zrobić, żeby nie położyć środowiska i nie zapchać całego ramu,
Używacie jakichś dostępnych już narzędzi w środowisku Javowo - Springowym?
Dla Spring Batch przypadek jest chyba odwrotny, czyli mamy ogromnego XML i wrzucamy go do DB. Chyba, że można też w drugą stronę.
Prośba o tipy zanim się Proof of conceptów naklepię :D
Poczytaj o hurtowaniach danych i hadoopie. Generalnie na produkcji nie generujemy raportów na transakcyjnych (w sensie do przetwarzania danych online) bazach danych. Java ze Springiem jednak nie do wszystkiego się nada ;)
@Charles_Ray: no nie nada się do wszystkiego. I niestety lipa jest.
Jak zrobię szybkie rozwiązanie to padną serwery i będzie na mnie.
Jak nie zrobię rozwiązania to nie będzie raportów i będzie dym i też na mnie :D
Na Hadoopa nie mam czasu, a i tak go nie umiem nic a nic.
Jak wrzucę możliwość generowania raportów to mam produkcję na głowie w Boże Narodzenie i ogólny ambaras ...
@0xmarcin nie są to dane tej skali jak napisałeś, ale duże na tyle, że jak te rekordy załaduję do pamięci i zacznę przetwarzać to wystarczy kilka na raz takich operacji i wszystko położone.
Szybki pomysł jest taki: zrób replikację do instancji read-only. Generuj raporty na tej drugiej instancji. Przy odrobinie szczęścia już taką replikę posiadasz, jak nie to warto o tym pomyśleć.
Bez podania nazwy i typu DB nie wiele można Ci pomóc, np. MS'owy sikłel-serwer ma bardzo dobre wsparcie do raportowania/hurtowni danych. Z kolei na Oracle to ja się np. w ogóle nie znam więc bym się nawet nie wypowiadał.
@0xmarcin: używamy Oraclowej DB. Replikacja o ile się nie mylę też jest wdrożona.
Coś myślę, że faktycznie nowy serwis (czy mikro to nie wiem) do generowania tych raportów by się przydał. Z tym, że też np, użytkownik kliknie: dej mi raport z ostatnich 3 miesięcy i bang: trzeba będzie wyciągnąć z 10 000 encji i już wszystko kwiczy.
Nawet jak zrobisz osobny serwis, to dojedziesz bazę. Pomysł z repliką read-only podoba mi się jako jakiś quick win, ale na pewno nie na dłuższa metę.
W jaki sposób joinowane?
Jeżeli masz porobione mapowania w jakimś jpa to sprawdź jak idzie ci te 10k encji.
Może zaciąga za duzo i dodatkowo później wyrzuca co nie potrzebne.
Tak jak wcześniej napisane zostało, do raportów jest replika.
Tylko, ze z replika tez jest wyzwanie. Każda obciąży ci system bazodanowy i dobrze mieć przy sobie kogoś kto doradzi. Najczęściej w IT wiedza o co chodzi.
@DKN: odniosę się do Twojego posta i komentarza :)
Czyli będę doradzał dedykowaną replikę bazy danych + wydzielony serwis tylko i wyłącznie do raportów.
@DKN no muszę te jony robić, bo nie jest to pchane prosto na twarz, ale są liczone jeszcze jakieś wartości z tych encji, a potem serializowane do określonego formatu.
Właśnie rozkminiałem jak zrobić z tych kilku tabel widoki.
Ale to muszę się bardziej podszkolić w materii baz danych, bo JPA i save(), albo findById() nie starcza :P
A ile w ogóle masz tych danych? Bo baza + ram całkiem dużo udźwigną
@DKN no muszę te jony robić, bo nie jest to pchane prosto na twarz, ale są liczone jeszcze jakieś wartości z tych encji, a potem serializowane do określonego formatu.
Właśnie rozkminiałem jak zrobić z tych kilku tabel widoki.
Ale to muszę się bardziej podszkolić w materii baz danych, bo JPA i save(), albo findById() nie starcza :P
Przepraszam, że tak wprost, ale komu Ty chcesz doradzać, skoro sam piszesz, że nie znasz się na bazach? Do tego jeszcze jakieś encje chcesz tworzyć pod raport? Przecież to kuriozum jakieś :D
Napisz
Pomijając jakieś porady doraźne to na dłuższą metę warto podejść do problemu od innej strony. Skoro potrzebujesz aby Twoje raporty (odczyt danych) nie rzutowały na prędkość głównej bazy (zapis danych) oraz musisz dostarczać odpowiedzi na jakieś złożone zapytania (jak mniemam, bo z prostymi zapytaniami raczej nie powinno być większego problemu) to warto rozważyć zastosowanie CQRS. Wtedy po stronie zapytań (Query w CQRS) możesz użyć oddzielnej bazy, ale dodatkowo możesz również tworzyć gotowe widoki pod konkretne rodzaje raportów. Innymi słowy możesz dowolnie denormalizować dane wedle potrzeb.
Przepraszam, ale czegoś tutaj nie rozumiem - dlaczego musisz WSZYSTKIE rekordy ładować do pamięci? Nie możesz tego robić w iteracji, pobierając z bazodanowego resultsetu rekord po rekordzie, aktualizując obiekt raportu będący instancją jakiejś klasy reprezentującej raport?
A ja podejdę do tematu z innej strony - zazwyczaj jak się ma aplikację webową i się widzi listę czegoś tam, to na jednej stronie jest tego 20, 50 bądź 100 - standardowy page size. Jak ktoś chce tego generować 10k rzeczy, to siłą rzeczy dużo czasu to zajmie.
A do generowania raportu polecam Jasper Reports
Po kolei - napisz, ile to jest dużo twoim zdaniem i jaką masz architekturę.
Zakładająm, że to zwykły MVC oraz baza danych. Bez zmian w architekturze:
Zmiany w architekturze:
4. Wspomniana replikacja bazy danych
5. Oddzielna aplikacja generująca raporty w tle tak, żeby to działało w ten sposób: użytkownik klika, że potrzebuje jakiegoś raportu - tutaj masz pełną dowolność jeśli chodzi o narzędzie. Jedyne co to musisz zaprojektować callback z jednej instancji do drugiej.
To tak na szybko, oczywiście opcji jest więcej, a wspomniane opcje można spokojnie łączyć (w ramach zdrowego rozsądku).
@Pinek: 10 tys. rekordów to jest mało i nawet niewielka JVM to udźwignie.
A zatem od początku.
Wnioski z powyższych postów:
Ogólnie zapomniałem: ta aplikacja to monolit i dlatego nie może mnie ponosić fantazja i zabierać zasobów na procesowanie raportów, jak inne corowe funkcjonalności muszą być dostępne.
Pracowałeś kiedykolwiek z ResultSetem?
https://docs.oracle.com/javase/7/docs/api/java/sql/ResultSet.html
Ustawiasz kursor na READ_ONLY oraz TYPE_FORWARD_ONLY i jedziesz rekord po rekordzie.
Nawet mając raport tworzony z 50 miliardów rekordów tym sposobem zużyjesz minimalną ilość RAMu, nie wspominając o jakichś śmiesznych 3 tysiącach rekordów LOL
Nie rozumiem po co ludzie tak strasznie chcą sobie komplikować i utrudniać życie - zrzuty do plików tekstowych, replikacje przy samym odczycie dla raportu? WTF?
@TomRZ: sprawa jest prosta. Komplikują sobie życie, w tym ja, bo nie mają wiedzy :) Dlatego dzięki Ci, bo ten ResultSet to chyba to czego szukam. Zabieram się za lekturę dokumentacji.
PS: Da się zrobić, żeby dla tego wątku, który właśnie zajmuje się generowaniem raportu określić górną granicę pamięci ram?
Co sądzicie o bieżącym zapisywaniu do pliku? Oszczędzi to ram?
o_O Ale po co? Mój laptop ma prawie 5 lat i ma 32GB ramu. W pracy serwery na których działa nasze oprogramowanie mają 256/512GB ramu każdy. A ty mówisz tutaj o 10k rekordów z 23 polami każde. Załóżmy że każde takie pole ma 10B, to by nam dało sumarycznie zawrotne 2.3MB a ty chcesz tu gdzieś oszczędać RAM. Załóżmy nawet że każde twoje pole ma 1000 razy więcej danych, to nadal jest raptem 2.3GB.
Poniższy post potraktuj (potraktujcie) jako nie znam się to się wypowiem.
Jak zrobię szybkie rozwiązanie to padną serwery i będzie na mnie.
Jak nie zrobię rozwiązania to nie będzie raportów i będzie dym i też na mnie :D
Na Hadoopa nie mam czasu, a i tak go nie umiem nic a nic.
Brzmi jak słabe skalowanie, ale nie wnikam, nie każdy ma nieograniczony Azure/AWS itp.
Bardzo mi się podobają tutaj pomysły zrobienia sobie czegoś na wzór hurtowni. Skoro robisz raporty to stawiam, że z danych, które już się nie zmieniają.
Robisz kilka/naście joinów do jednego raportu. Zamiast robić te joiny wtedy kiedy potrzebne są te raporty (a z tego co czytam nie pobiera się jednego raportu tylko jakąś ustaloną z góry liczbę) to pyk hurtownię raz dwa.
Po odpowiednim przetworzeniu danych/wykonaniu konkretnych operacji/przetworzeniu odpowiedniego eventu zebrać wszystkie potrzebne dane do kupy, władować w POJO i zapisać w osobnej bazie. Jak będzie trzeba je wyciągnąć to masz jednego SELECT'a i z głowy.
Przy takim podejściu możesz się wtedy na spokojnie zastanowić co z resztą (czyli danymi które masz w bazie ale jeszcze nie w hurtowni):
lazy - jak potrzebny raport to zbierasz wszystko do kupy, zapisujesz to nowe POJO i generujesz raporcik (zauważ, że stan hurtowni tutaj jest niespójny, ja bym z tego rozwiązania nie korzystał jeśli jest taka możliwość)Jak tych joinów jest rzeczywiście dużo to bardziej obeznani koledzy polecą jakieś rozwiązania. Zawsze jest JdbcTemplate ze Springa, który może pomóc trochę zredukować narzut JPA/Hibernate/Spring Data. Daj znać co tam wykminiłeś, lubię takie problemy :P
Architektura to zwykłe JPAowe repozytorium wystawione na kontroler, który zwraca strumień bajtów - encja na twarz i pchasz, nieładnie
P.S. Nie znam szczegółów, mogę doradzać źle, przepuść moją opinię przez sito. A, no i nigdy nie pracowałem na Oracle DB.
10k rekordów to możesz obrobić nawet w Excelu (pobierając dane przez Query).
Jakbyś miał dane pow. 65k wierszy, to poczytaj to:
https://dzone.com/articles/50-best-performance-practices-for-hibernate-5-amp
Hmm RAM ramem, ale co z operacjami IO? Przecież taki raport musi być albo JSONem (serializacja 10 000 obiektów trochę zajmie czasu), albo pdfem (wtedy zapis do pliku który będzie mieć ~~300 stron też chyba nie pójdzie szybko)
IMO jeśli to większy plik to powinien być wygenerowany asynchronicznie, zapisany na dysku a później pobrany kolejnym requestem czy coś w tym stylu
Do tego typu problemów warto zainteresować się takimi rozwiązaniami jak HDFS lub Cassandra (jako storage) i Apache Flink (przetwarzanie danych). Flink pozwala zarówno na ciągłe przetwarzanie i jednorazowe przetwarzanie zdefiniowanego zbioru danych (Twój przypadek). Masz tam też gotowe connectory do różnych źródeł danych (np. Cassandra).