Raport, który generuje się 20 minut, powinien być dostępny w sekundę

Piątek, 15:00. Zarząd chce zestawienie sprzedaży za kwartał. Otwierasz moduł raportów, klikasz "Generuj", patrzysz na kręcące się kółko i czekasz. 5 minut. 10 minut. 20 minut. W międzyczasie reszta firmy narzeka, że "system znowu muli". Bo Twój raport zjadł cały procesor serwera.

Znasz to? Większość użytkowników systemów ERP - tak.

Dlaczego legacy ERP zamula przy raportach

Jeden wątek blokuje wszystko

Tradycyjne systemy ERP (PHP, Java, .NET) działają w modelu request-response. Każde żądanie zajmuje wątek serwera. Gdy raport wymaga przeskanowania miliona rekordów, ten wątek jest zajęty przez 20 minut. A serwer ma ich ograniczoną liczbę.

Efekt? Twój raport blokuje zasoby, które mogłyby obsługiwać innych użytkowników. Wystawianie faktur zwalnia, wyszukiwanie klientów trwa wieczność, ludzie zaczynają dzwonić do IT.

Brak optymalizacji zapytań

Wiele legacy systemów generuje raporty przez pobranie wszystkich danych do pamięci aplikacji i przetworzenie ich w kodzie. Zamiast powiedzieć bazie danych "policz sumę sprzedaży pogrupowaną po miesiącach", pobierają milion wierszy i sumują je w pętli for. To jak kazać magazynierowi przynieść wszystkie faktury z archiwum do biura, zamiast poprosić go o policzenie ich na miejscu.

Brak cache'owania

Zarząd generuje ten sam raport kwartalny 15 razy dziennie, bo każdy chce "mieć pewność, że dane są aktualne". System za każdym razem liczy od zera. Te same dane, to samo zapytanie, 20 minut czekania × 15 = 5 godzin pracy serwera dziennie na jednym raporcie.

Synchroniczne przetwarzanie

Klikasz "Generuj raport" i... czekasz. Przeglądarka pokazuje białą stronę albo spinner. Nie możesz nic innego zrobić w systemie, bo zakładka jest zablokowana. Otwierasz nową zakładkę - ale serwer i tak jest zajęty Twoim raportem.

Jak to wygląda w Phoenix LiveView na BEAM

Izolacja procesów - raport nie blokuje nikogo

W BEAM każda operacja to osobny, izolowany proces. Twój raport kwartalny to jeden proces. Faktura, którą kolega właśnie wystawia - to inny proces. Działają równolegle na osobnych rdzeniach procesora, z osobną pamięcią.

Gdy Twój raport zjada 100% jednego rdzenia, reszta systemu nawet nie drgnie. Ośmiordzeniowy serwer oznacza, że raport może zająć jeden rdzeń, a siedem pozostałych obsługuje resztę firmy bez spowolnienia.

Streaming wyników w czasie rzeczywistym

W LiveView nie czekasz 20 minut na białą stronę. Raport generuje się w tle, a wyniki streamują się na ekran w miarę jak są obliczane:

• Sekundy 1-3: na ekranie pojawiają się dane za styczeń
• Sekundy 3-6: dochodzą dane za luty i marzec, wykresy się aktualizują
• Sekundy 6-10: pojawia się pełen kwartał z podsumowaniem

Widzisz postęp w czasie rzeczywistym. Możesz zacząć analizować dane, zanim cały raport się wygeneruje. Nie ma białej strony, nie ma spinnera, nie ma frustracji.

PostgreSQL robi to, do czego został stworzony

Zamiast pobierać milion wierszy i sumować w aplikacji, budujemy zapytania SQL, które robią agregację w bazie danych. PostgreSQL jest w tym genialny:

• Materialized views - raport kwartalny jest przeliczany raz, wynik jest gotowy w milisekundach
• Indeksy na daty i partycjonowanie - filtrowanie po zakresie dat to skanowanie małego fragmentu tabeli, nie całej
• Window functions - porównanie rok do roku, narastająco, średnia krocząca - to jedno zapytanie SQL, nie pętla w kodzie
• pg_stat_statements - widzimy dokładnie, które zapytanie jest wolne i dlaczego

Raport, który w legacy trwał 20 minut, w zoptymalizowanym PostgreSQL trwa 200 milisekund. Nie dlatego, że mamy szybszy serwer - dlatego, że prosimy bazę o właściwą rzecz.

Inteligentne cache'owanie

Zarząd generuje raport 15 razy dziennie? System oblicza go raz i serwuje z cache'a. Gdy dane się zmienią (nowa faktura, nowe zamówienie), cache jest automatycznie unieważniany i raport przelicza się w tle - zanim ktokolwiek go otworzy.

Efekt: raport jest zawsze gotowy. Zero czekania. Otwierasz - dane są.

Notyfikacje zamiast odpytywania

W legacy: "Czy raport się już wygenerował?" Klik. "Nie, jeszcze nie." Czekasz. Klik. "Nie." Czekasz. Klik.

W LiveView: uruchamiasz raport, wracasz do pracy. Gdy raport jest gotowy, na ekranie pojawia się powiadomienie: "Twój raport kwartalny jest gotowy. Otwórz." Bez odpytywania, bez sprawdzania - serwer sam mówi Ci, kiedy skończył.

Dashboard zamiast raportów

Pytanie fundamentalne: czy naprawdę potrzebujesz raportów?

Raporty to artefakt ery, w której dane były drogie w przetworzeniu. Generowałeś raport, drukowałeś, analizowałeś. Dziś dane mogą być na żywo.

Zamiast "generuj raport sprzedaży za styczeń" - dashboard, na którym sprzedaż za styczeń aktualizuje się z każdą nową transakcją. W czasie rzeczywistym. Bez klikania "Generuj".

Phoenix LiveView jest do tego stworzony:

• Widgety z KPI - aktualna sprzedaż, średni koszyk, konwersja. Aktualizują się same
• Wykresy live - nowa transakcja pojawia się na wykresie w sekundę po jej zamknięciu
• Filtry bez przeładowań - zmieniasz zakres dat, kategorię produktu, region - dane przeliczają się natychmiast
• Alerty - sprzedaż spadła poniżej progu? System Ci powie, zanim sam zauważysz

Zarząd nie potrzebuje raportu kwartalnego w piątek o 15:00. Potrzebuje odpowiedzi na pytanie "jak idzie sprzedaż" - w dowolnym momencie, natychmiast.

Migracja raportów - od czego zacząć

Krok 1: Zmierz co masz

Które raporty są generowane najczęściej? Które trwają najdłużej? Które blokują system? Zwykle 5 raportów odpowiada za 80% problemu.

Krok 2: Zoptymalizuj bazę

Zanim przepiszesz cokolwiek, sprawdź czy problem nie leży w bazie danych. Brakujące indeksy, nieoptymalne zapytania, brak partycjonowania. Czasem 2 dni pracy z PostgreSQL skraca raport z 20 minut do 30 sekund - bez zmiany aplikacji.

Krok 3: Zbuduj dashboardy

Zacznij od jednego dashboardu - najważniejszego. Sprzedaż? Magazyn? Produkcja? Zbuduj go w LiveView, podłącz do istniejącej bazy danych. Reszta systemu nadal działa po staremu, ale zarząd ma real-time widok na kluczowe metryki.

Krok 4: Przenoś kolejne raporty

Stopniowo zamieniaj statyczne raporty na interaktywne dashboardy. Każdy kolejny jest łatwiejszy, bo infrastruktura jest już gotowa.

Ile to kosztuje vs ile kosztuje status quo

Policzmy koszty obecnego stanu:

• 20 minut oczekiwania × 15 raportów dziennie × 220 dni roboczych = 1100 godzin rocznie zmarnowanych na czekanie na raporty
• Spowolnienie systemu podczas generowania raportów - trudne do wyceny, ale realne: wolniejsze fakturowanie, wolniejsze wyszukiwanie, frustracja zespołu
• Decyzje oparte o nieaktualne dane - raport z piątku nie uwzględnia transakcji z poniedziałku rano. Zarząd podejmuje decyzje o 3 dni za późno

Dashboard w LiveView eliminuje te koszty. Nie wszystkie na raz - zaczynasz od jednego raportu, mierzysz efekt, budujesz dalej.

Chcesz zobaczyć, jak Twój najwolniejszy raport może wyglądać jako real-time dashboard? Porozmawiajmy - pokażemy prototyp na Twoich danych.