Cześć,
Budujemy a w zasadzie przebudowujemy właśnie wspólnie z zespołem w firmie (na razie koncepcyjnie) panel raportowy. Jeżeli chodzi o technologię to standardowo java jako backend + angular na froncie. Ale nie o to chodzi. Chciałbym z wami porozmawiać, może coś ciekawego podpowiecie, w jaki sposób wykonać zaczytywanie danych z bazy. Baza to DB2 i na to akurat wpływu nie mamy. Gdybym miał postawił bym na Oracla no ale trudno. Baza bardzo prosta, dwie tabele, pierwsza z jakimś indeksem + obiekt w postaci XML-a (pole typu XML, nie żaden CLOB czy BLOB) i druga tabela połączona w relacji jeden do jednego z pierwszą gdzie siedzą 23 kolumny z danymi niezbędnymi do wyszukiwania w panelu raportowym. Czyli część pól po których panel ma wyszukiwać konkretne wnioski klientów i produktów powiązanych z klientem (całość siedzi w tym XML-u) jest rozbita relacyjnie, reszta jak chce się podejrzeć konkretnego klienta jest zaciągana z XML-a. No i tu zaczyna się problem. Bo aktualny panel działa baaardzo wolno. Niektóre XML-e parsowane są nawet po 30 sekund. Wszystko zależy od obciążenia serwera a z panelu korzysta ok 8 tysięcy osób. Sam XML zawiera średnio ok 100 tysięcy węzłów więc sami widzicie, jest bardzo duży. I teraz Zastanawiamy się jak to przebudować. Padają pomysły w postaci operowania na widokach zamiast na XML-alch. Na pewno trzeba będzie przebudować bazę ale brakuje nam takiego mocnego doświadczenia bazodanowego w tego typu kwestiach. Jak Wy ten temat widzicie? Jakbyście go 'ugryźli'?
Z Twojego posta zrozumiałem dwa punkty:
- jedna tabela przechowuje klucze wyszukiwania, a druga XMLa w CLOB/BLOB
- działa to "wolno"
Co jest wolne?
a) wyszukiwanie
b) wyciąganie XMLa z bazy
c) parsowanie XMLa po stronie aplikacji?
Z tego co napisałeś zrozumiałem, że chodzi o opcję c).
- Na co idzie te 30 sekund? Możliwe, że samo parsowanie jest "znośne", ale przy większym obciążeniu po prostu czas oczekiwania na jakiś zasób jest większy. W tym przypadku kolejka do CPU może być dłuższa i stąd większe czasy przetwarzania.
Jeśli dla XMLi o porównywalnych rozmiarach, czas przetwarzania jest drastycznie różny (w zależności od pory dnia), to ta wersja wydaje mi się prawdopodobna.
- Jak duże są to XMLe (w kb)? Średnia wielkość może dać niepełny obraz. Chodzi o histogram,
np.
20% ma rozmiar <8kb
30% od 8kb do 32kb
15% od 32b do 128kb
25% od 128kb do 512kb
10% >512kb
Wielkość i ilość "kubełków" dla histogramu może być oczywiście inna.
- Czy wyciągasz z XML ustalone elementy? np. masz 50 przypadków użycia i dla każdego wyciągasz "coś innego", ale ogólnie wiesz co?
Jeśli tak, to może po prostu indeksować XMLe w bazie? I korzystać z XQuery/XPath po stronie bazy? - Może XMLe da się pociąć na odrębne sekcje i trzymać je w bazie osobno?
- Może warto zmienić parser XMLa?
Cześć,
Na wstępie życzę Wszystkim Wesołych Świąt :).
Tak, wszystko dobrze zrozumiałeś. To co trwa długo właśnie parsowanie samego XML-a. A najgorsze jest to że potrzebuję całej jego zawartości :(. Gdybym potrzebował konkretnych pól, na pewno bym sobie je zapisał relacyjnie. Co do wagi samego XML-a to średnio jeden waży ok 1MB ale są i większe. Jak jest mało użytkowników czyli rano lub po południu to działa to znośnie. Jeden XML parsuje się ok 5 - 6s (co uważam że i tak jest długim czasem) natomiast gdy ilość osób jest większa to te czasy drastycznie rosną. Mam na bieŻąco (Boże, widzisz takie błędy i nie grzmisz) monitoring serwera bazodanowego i aplikacyjnego i zapytania do basy trwają milisekundy. Więc to nie baza jest problemem. Zresztą to jest prosty SQL który wyciąga XML-a. Natomiast wątki serwerowe usług odpowiadające za parsowanie trwają bardzo długo. A im dłużej dany wątek wisi tym dłużej czekają inne w kolejce bo serwer też nie jest jakoś super mocny ale dokładanie procesorów i pamięci niczego nie zmieni bo taka architektura jaka jest teraz zdegraduje każde zasoby. Dlatego chcemy to przebudować i przerzucić część rzeczy na bazę danych tylko nie wiem za bardzo jakie mamy możliwości. Nie oczekuję gotowego rozwiązania. Bardziej chodzi mi o 'hasła' o których warto abym poczytał.
- Jaki wg Ciebie powinien być czas parsowania 1MB XMLa?
- Jaki stos technologiczny?
- Jakiego parsera XML używasz?
- Jakie masz zasoby sprzętowe pod ten panel?
Piszesz, że z panelu korzysta 8k osób. Dla tylu użytkowników samo zaczytanie XMLi generuje 8GB RAMu. Zakładałbym, że serwer dla samych XMLi powinien mieć ze 12 GB RAM (tak, żeby utylizacja zasobu była na poziomie 60-70%).
kingu80 napisał(a):
Cześć,
Na wstępie życzę Wszystkim Wesołych Świąt :).Tak, wszystko dobrze zrozumiałeś.
A ja dalej nie rozumiem.
Czy w tych XML'ach są dane, które podlegają analizie?
Czy raczej w tym XML zapisane są metadane czym jest taka analiza?
To co trwa długo właśnie parsowanie samego XML-a.
Opowiedz na pytanie, co parsuje tego XMLa?
Bo może go parsować:
- Backend w Java
- Front w Angular
- Baza danych DB2.
Przy okazji, czy wy macie w zespole świadomość, że DB2 ma poważne możliwości w parsowaniu XML?
Np. wyciągniecie danych z dokumentu XML (włącznie z obsługą XQuery), przetworzenie i złączenie ich z dowolnymi danymi relacyjnymi to pikuś.
Dlaczego nie w tę stronę?
A najgorsze jest to że potrzebuję całej jego zawartości :(. Gdybym potrzebował konkretnych pól, na pewno bym sobie je zapisał relacyjnie.
To sobie zapisz, albo doczytaj co masz dostępnego pod ręką...
A masz DB2.
Co do wagi samego XML-a to średnio jeden waży ok 1MB ale są i większe.
Taki rozmiar, to nie powinien być żadne problem.
Jak jest mało użytkowników czyli rano lub po południu to działa to znośnie. Jeden XML parsuje się ok 5 - 6s (co uważam że i tak jest długim czasem) natomiast gdy ilość osób jest większa to te czasy drastycznie rosną. Mam na bieŻąco (Boże, widzisz takie błędy i nie grzmisz) monitoring serwera bazodanowego i aplikacyjnego i zapytania do basy trwają milisekundy. Więc to nie baza jest problemem.
Nie, to wasz serwer aplikacyjny jest problemem.
I głównym problemem raczej nie jest samo parsowanie XML (bo jak mało userów, to działa znośnie), a jego architektura.
To cudo się dławi przy obciążeniu...
Dowiedz się dlaczego.
Zresztą to jest prosty SQL który wyciąga XML-a.
Niech DB2 parsuje XMLa.
Natomiast wątki serwerowe usług odpowiadające za parsowanie trwają bardzo długo.
Na czym dokładnie polega to parsowanie?
I na czym dokładnie działa to wolno.
To są w sumie pytania do was, a nie do Cienie na grupę..
A im dłużej dany wątek wisi tym dłużej czekają inne w kolejce bo serwer też nie jest jakoś super mocny ale dokładanie procesorów i pamięci niczego nie zmieni bo taka architektura jaka jest teraz zdegraduje każde zasoby.
Macie skopane dwie rzeczy.
Sama architektura tego serwera jest z czapy, bo nie powinno się to tak zachowywać.
Samo parsowanie takich XML w takim czasie to jakiś totalny fuckup.
No chyba, że tam dzieje się jeszcze coś więcej...
Ale... skoro w tych XMLach są dane do analizy, które nie zmieniają się dość często, to dlaczego nie parsować ciągle te same XMLe zamiast zrobić to raz, keszować i potem używać?
Dlatego chcemy to przebudować i przerzucić część rzeczy na bazę danych tylko nie wiem za bardzo jakie mamy możliwości.
To radziłbym rozpocząć od manula do DB2.
Przesiadka na Oracle nic tu nie da, a nosi znamiona leczenia syfu pudrem.
Nie oczekuję gotowego rozwiązania. Bardziej chodzi mi o 'hasła' o których warto abym poczytał.
Najpierw to dowiedz się gdzie dokładnie leży problem, bo z tego co piszesz, to zwyczajnie nie wiesz.