Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> Duże listy
zordon
post 7.12.2011, 15:41:39
Post #1





Grupa: Zarejestrowani
Postów: 358
Pomógł: 78
Dołączył: 4.11.2008
Skąd: Kraków

Ostrzeżenie: (0%)
-----


Witam,
chciałbym dowiedzieć się jak radzicie sobie z naprawdę dużymi listami?
Ostatnio klientka chciała dostać w panelu administracyjnym megalistę prezentującą na jednym ekranie jak najwięcej danych.
Główna tabela liczy kilkaset tysięcy rekordów, rekordy kilkadziesiąt (!) kolumn. Pani chciała sortować listę po każdej wyświetlanej kolumnie.
Wyświetlanych na stronie kolumn miało być kilkanaście, do tego również spoza głównej tabeli.

Oczywiście zaczęły się problemy wydajnościowe.
Gdyby nie konieczność sortowania po wszystkich kolumnach pobierałbym dane z innych tabel wyłącznie dla stronicowanych rekordów (mimo że stronicowanie ustawione na 100/stronę) ale przez to sortowanie musiałem zastosować kilka JOINów, które to właśnie najbardziej spowalniają zapytanie.
Cachowanie listy raczej nie wchodzi w grę, bo dane dość często się zmieniają, a kasowanie cache i generowanie go od razu dla całej listy byłoby już tragicznie wolne.
Odpowiednie założenie indeksów w bazie poprawiło wydajność, ale wciąż za mało

Wielu pewnie powie, że baza źle zaprojektowana i to przez to - bardzo możliwe, prawdopodobnie da się zrobić to lepiej. Jednak problem bardzo uogólniłem i załóżmy dla potrzeb pytania, że inaczej się "nie da" i musimy sobie jakoś poradzić z takim potworkiem.

Stosowanie widoków w bazie raczej nie poprawi wydajności? A co z procedurami? Może jakieś tabele tymczasowe?
Ciekaw jestem waszych rozwiązań w takim przypadku
Go to the top of the page
+Quote Post
athabus
post 7.12.2011, 17:20:27
Post #2





Grupa: Zarejestrowani
Postów: 898
Pomógł: 48
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


Kiedyś miałem podobną sytuację, tyle że dotyczącą pojedynczych selectów z wielu tabel, gdzie proste joiny nie wystarczały, tylko były potrzebne podzapytanie etc. Ogólnie wtedy zdecydowałem się na tabelę z cache. Sam cache był obsługiwany wyzwalaczami z poziomu bazy danych.
Takie rozwiązanie sprawdza się dobrze przynajmniej tak długo, jak bazowe tabele są zmieniane z umiarkowanym natężeniem. W innym przypadku sam narzut na cachowanie może być całkiem spory. U mnie zmiany były wykonywane głównie ręcznie przez administratora, za to z cachu korzystał cały frontend, więc to się opłaciło, bo selecty na tych tabelach stanowiły >99% zapytań.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 16.04.2024 - 05:37