Generowanie plików schedulerem w aplikacji działającej w klastrze

Cześć wszystkim.
Poniższy wątek jest luźno związany z moim poprzednim wątkiem więc jakby kogoś interesował kontekst to zapraszam tutaj: Wydajne wyciąganie danych z bazy w Javie
Przechodząc do rzeczy:
Mam za zadanie zaimplementować mechanizm generowania zestawień w aplikacji. Zestawienia mają się generować codziennie w godzinach nocnych. Do tego momentu wszystko jest dla mnie zrozumiałe ale okazało się że aplikacja działa w klastrze, tzn. wychodząc na produkcję jest uruchamiana w kilku instancjach które współdzielą bazę, nie wiem czy to docker czy coś innego. Wiedza ta jest po stronie zespołu wdrożeniowego. Powyższa sytuacja ma następujące konsekwencje:

1. Jeżeli istnieje np. 5 instancji aplikacji i wszystkie o godzinie 23:00 zaczną generować raport/chcieć się dobrać do tych samych danych (baza współdzielone między instancjami) to istnieje czy istnieje możliwość jakiegoś locka na bazie danych (jeżeli źle to nazywam to niech ktoś mnie poprawi ) ? Wydaje mi się że tak skoro wszystkie instancje używają tych samych danych do logowania/użytkownika do bazy. Baza to OracleDB dla rozjaśnienia.
2. Aplikacja jest napisana w Springu i znalazłem coś takiego celem zabezpieczenia się przed owymi lockami na bazie: https://www.baeldung.com/shedlock-spring, i moje pytanie brzmi: ktoś z Was drodzy forumowicze używał Shedlocka ze Springiem w środowisku produkcyjnym? Jakie inne rozwiązania istnieją do rozwiązania tego problemu? Znalazłem jeszcze Quartza ale wydał mi się on strasznie niedostępny w przypadku gdy chciałem do klas implementujących interfejs Job wstrzykiwać zależności przez konstruktor z @Autowired a znalezione tutoriale ze spinaniem Quartza ze Springiem wydały mi się zagmatwane. Jak radzicie sobie z problemem dostępu do danych przy aplikacji w wielu instancjach/jakich technologii używacie?
3. Później zaczęła frapować mnie inna kwestia, mianowicie: jeżeli 5 instancji aplikacji będzie generować zestawienie bazując na tych samych danych to w rezultacie dostanę 5 xlsów z raportem o tej samej treści co wydaje mi się bez sensu. Zastanawia mnie kwestia czy wywołanie tego generowania raportu nie powinno być wyciągnięte poza aplikację, w sensie: zewnętrzny klient woła aplikację SOAPem/RESTem na metodę np. generujZestawienie a to żądanie dopiero trafia do jakiejś tam konkretnej instancji za pośrednictwem gatewaya. Które z tych podejść ma sens? Dodam że wygenerowany zestawienie ma być zapisywane na FTPie więc metoda generujZestawienie jest czystym voidem.

Używałem tego i tego na produkcji. Shedlock używałem z implementacją couchbase, działa spoko.
Quartz polecam tylko z sql job store.

jeżeli 5 instancji aplikacji będzie generować zestawienie bazując na tych samych danych to w rezultacie dostanę 5 xlsów z raportem o tej samej treści co wydaje mi się bez sensu

Z shedlockiem nie powinno.

Zwykle wydzielam jakiś oddzielny mikroserwis np. jobs, który strzela eventami do rabbitmq lub na kafke
a event może być np. odebrany gdzieś w innej usłudze odpowiedzialnej za generowanie.

Satandardowo, jeśli wydajność jest jakimś potencjalnym problemem, raporty robi się na zreplikowanej bazie. Albo wręcz spacjalnej bazie do raportów albo wręcz w full data warehouse.
Zresztą z wielu względów jest to wygodne. W oracle masz różne mechanizmy do replikacji - streams, (coś jeszcze co zapomniałem jak się nazywa) i Golden Gate.

lookacode1 napisał(a):

Zwykle wydzielam jakiś oddzielny mikroserwis np. jobs, który strzela eventami do rabbitmq lub na kafke
a event może być np. odebrany gdzieś w innej usłudze odpowiedzialnej za generowanie.

Czyli wygląda to tak jak u Ciebie z mikroserwisem Job, mniej więcej jak na rysunku poniżej, dobrze zrozumiałem?

https://imgur.com/a/qT05zld

jarekr000000 napisał(a):

Satandardowo, jeśli wydajność jest jakimś potencjalnym problemem, raporty robi się na zreplikowanej bazie. Albo wręcz spacjalnej bazie do raportów albo wręcz w full data warehouse.
Zresztą z wielu względów jest to wygodne. W oracle masz różne mechanizmy do replikacji - streams, (coś jeszcze co zapomniałem jak się nazywa) i Golden Gate.

Jestem za nisko w hierarchii zespołu/firmy aby forsować tak radykalne rozwiązania jak replikacja bazy chociaż pracowałem w firmie gdzie zestawienia/raportu były generowane w oparciu o bazę lustrzaną do produkcji i to rozwiązanie się sprawdzało. Tak samo jak w poprzednim wątku @Shalom sugerował aby przebudować strukturę bazy/rozpisać na nowo - to byłoby dobre rozwiązanie ale nie ma opcji abym to przepchnął i aby ktoś wyżej to klepnął. Bo "już jest jak jest i szkoda tego ruszać".

Nie wiem czy to pomoze ale U nas w jeden node jest ustawiony na takie rzeczy jak joby. Jest jeden master a reszta to slavy ktore nie maja ustawionych w propertiesach jobow.

1. Czy chcesz mieć jedno jedyne zestawienie, czy to można jakoś podzielić między te nody?
2. Jeśli chcesz tylko jedno, to czemu to w ogóle nie jest osobny serwis który się tym zajmuje? Jak chcesz być nowoczesny, to pasuje tu moze jakaś Lambda/Serverless skoro chcesz to robić tylko raz dziennie i w sumie nie obchodzi cię specjalnie latency i chcesz to triggerować czasowo. Idealna opcja pod właśnie jakieś serverless.

Shalom napisał(a):

1. Czy chcesz mieć jedno jedyne zestawienie, czy to można jakoś podzielić między te nody?
2. Jeśli chcesz tylko jedno, to czemu to w ogóle nie jest osobny serwis który się tym zajmuje? Jak chcesz być nowoczesny, to pasuje tu moze jakaś Lambda/Serverless skoro chcesz to robić tylko raz dziennie i w sumie nie obchodzi cię specjalnie latency i chcesz to triggerować czasowo. Idealna opcja pod właśnie jakieś serverless.

1. To nie jest jeszcze w zespole doprecyzowane, nie mam jeszcze informacji jak sobie ludzie z góry życzą aby było tj. czy zestawienie ma być dzielone na mniejsze party i rozkładane w nodach czy traktowane jeden wielki task/zadanie. Zakładając wątki na forum miałem w głowie koncepcje że jest to jedno, niepodzielne zadanie.

2. Tak jak napisałem wcześniej, nawet gdyby zestawienie okazało się jednym niepodzielnym taskiem to nie mam takiej siły przebicia aby zaproponować, z sukcesem, innowacje w postaci Serverless - nawet gdyby ten byłby idealnym rozwiązaniem. "Bo zespół zna to i to, do tej pory działało i guzik ich obchodzi że świat poszedł do przodu, ma być tak jak w starych projektach" - takie streszczenie dzisiejszego mojego spotkania z teamem. Czemu nie ma dedykowanego serwisu do zestawień? Bo ktoś zdecydował że łatwiej/szybciej będzie ten moduł dokleić do monolitu w Springu 4 podajże niż silić się na drobnicę w deploymencie - bo się doklepie do tego co jest bez fanaberii.

Generalnie chciałbym wszystkim podziękować za odpowiedzi, na pewno mi się przydadzą w przyszłości gdy będę miał większą wolność twórczą w projekcie. ;) Na tę chwilę wątek można uznać za zamknięty.

Skoro nie masz możliwości wejścia z nowymi technologiami, korzystaj z tego co masz. A skoro masz OracleDB, to może wystarczy widok zmaterializowany (tak jak pisałem w poprzednim wątku). Tu przykład: https://stackoverflow.com/questions/22481099/create-materialized-view-which-refresh-records-on-daily
Podobnie z schedulerem, Oracle też coś takiego ma i być może poradzi sobie również w klastrze: https://docs.oracle.com/cd/B19306_01/server.102/b14231/schedover.htm#i1006857

Jednym z wyjść (jeśli nie inne, powyższe) może być wydzielona instancja tej samej aplikacji z włączonymi jobami, a te skalowalne działają z wyłączonymi. Takie podejście masz np. w Ruby on Rails gdzie workery z sidekiqa odpalasz sobie jako jakby osobną instancję tylko do jobów. Nie jest pewnie idealnie ale jeśli nie możesz iść w serverless/osobny mikroserwis, itp. to może możecie spróbować tego? Jeśli jedna instancja wystarczy to masz rozwiązany problem z lockami i generowanie raportów X razy