Temat: Jak efektywnie posortować wyniki zapytania UNION z bazy...

Potrzebuję odpowiedzi dla jednego z użytkowników wisdio.com. Będę wdzięczny za merytoryczną, uargumentowną opinię.

Więcej szczegółów pod adresem: http://wisd.io/NQ1bi

Temat: Jak efektywnie posortować wyniki zapytania UNION z bazy...

UNION to nie złączenie tabel a zapytań.
Dlaczego "Oczywiście UNION nie skorzysta z indeksów"? Skąd ten pomysł?

Wg mnie ORDER BY na bazie. Prawdopodobnie będzie niestety wykonane jako dodatkowy krok, tylko że w bazie będzie zdecydowanie szybciej niż w języku skryptowym.Piotr L. edytował(a) ten post dnia 10.11.11 o godzinie 15:35

Temat: Jak efektywnie posortować wyniki zapytania UNION z bazy...

hmm
czasem warto zrobić temporaty table i założyć na niej indeks po dodaniu kompletu danych

zrobienie inserta do tabeli bez indeksów nie jest aż tak czasochłonne a suma sumarum może się opłacić

Temat: Jak efektywnie posortować wyniki zapytania UNION z bazy...

Sortowanie u źródła chyba jest zawsze wydajniejsze niż na kliencie ? Poza tym na bazie często jest (tak jak wspomniał Przemo) daje często mozliwośc przepiania zapytania w inny sposób, aby jednak było wydajniejsze.

Temat: Jak efektywnie posortować wyniki zapytania UNION z bazy...

Przemysław R.:
hmm
czasem warto zrobić temporaty table i założyć na niej indeks po dodaniu kompletu danych

zrobienie inserta do tabeli bez indeksów nie jest aż tak czasochłonne a suma sumarum może się opłacić

A dlaczego nie najpierw poindeksować a potem wstawiać? Myślisz, że narzut na wielokrotne równoważenie drzewa (indeksy) będzie dużo większy niż na jego budowę? Nie jestem tego pewien, trzeba by sprofilować.

Pomysł z temp table jes generalnie niegłupi, ale tworzenie w każdym zapytaniu tabeli też kosztuje (*)

A może po prostu tak:

SELECT * FROM
(SELECT * FROM A WHERE ...
UNION
SELECT * FROM B WHERE...)
ORDER BY ...

jeśli A i B są indeksowane i kryterium wyszukiwania ten indeks wykorzystuje, to indeksy się nie pogubią. Żeby wykorzystać te indeksy i pomóc bazie można jeszcze tak:

SELECT * FROM
(SELECT * FROM A WHERE...
ORDER BY ...
UNION
SELECT * FROM B WHERE...
ORDER BY ...)
ORDER BY ...

(*) - jeśli wyników zapytania do posortowania jest dużo, to wg mnie zaproponowana przez Przemka tymczasowa tabela, którą poindeksujemy i posortujemy ma duży sens.

Wreszcie, można stworzyć zmaterializowany widok, na który założy się indeksy, a w zapytaniu tworzącym widok dane będą sortowane.

Rozwiązania należałoby porównać - zebranie statystyk i sprofilowanie.

Nie sortować na kliencie. Szczególnie jeśli danych do posortowania będzie dużo. Oprócz tego, że baza zrobi to szybciej używając indeksów, to na serwerze aplikacyjnym, w zależności od algorytmu sortującego, mogą się pojawić dodatkowe narzuty: dodatkowe włączenia GC, zmiana HeapSize itp. Bez sensu.Jakub Fila edytował(a) ten post dnia 11.11.11 o godzinie 13:03

Temat: Jak efektywnie posortować wyniki zapytania UNION z bazy...

Zależy, przy małych wynikach, sortowałbym na kliencie.
Kolejna sprawa, jak jest sam union, bez all to baza i tak posortuje wyniki, żeby zapewnić unikalność. Nie wiem, czy wstępne posortowanie coś tu zmieni - teoretycznie powinno. Może się też okazać, że wynik jest na tyle duży, że w ramie się tego nie da zrobić. A to oznacza, że oranie po dysku zakryje wszystko.
Zależy co to za zapytanie.

Temat: Jak efektywnie posortować wyniki zapytania UNION z bazy...

Michał Z.:
Zależy, przy małych wynikach, sortowałbym na kliencie.
Kolejna sprawa, jak jest sam union, bez all to baza i tak posortuje wyniki, żeby zapewnić unikalność. Nie wiem, czy wstępne posortowanie coś tu zmieni - teoretycznie powinno. Może się też okazać, że wynik jest na tyle duży, że w ramie się tego nie da zrobić. A to oznacza, że oranie po dysku zakryje wszystko.
Zależy co to za zapytanie.

Z drugiej strony, to jeśli to jest rozsądnie zaprojektowany system wykorzystywany do poważnych zastosowań, to:
1. Oranie po dysku nie powinno być szczególnie kosztowne, bo przecież pod spodem powinna być macierz i przynajmniej 1 półka z 24 dyskami (a to już ok. 3-4 kIOPS). Ja zawsze kiedy projektuję fizyczną warstwę, to serwer DB musi być enterprise class, w tym w szczególności mieć porządne karty FC i udostępniać odpowiednią liczbę kanałów
2. Jeśli wyników jest niedużo, to w sumie nie ma znaczenia, gdzie się to posortuje, bo wymagania na moc i pamięć nie będą duże

Jeśli to nie jest poważny system, to why care? Wtedy ważne, żeby w ogóle działało.

Temat: Jak efektywnie posortować wyniki zapytania UNION z bazy...

Jakub Fila:

Michał Z.:
Zależy, przy małych wynikach, sortowałbym na kliencie.
Kolejna sprawa, jak jest sam union, bez all to baza i tak posortuje wyniki, żeby zapewnić unikalność. Nie wiem, czy wstępne posortowanie coś tu zmieni - teoretycznie powinno. Może się też okazać, że wynik jest na tyle duży, że w ramie się tego nie da zrobić. A to oznacza, że oranie po dysku zakryje wszystko.
Zależy co to za zapytanie.

Z drugiej strony, to jeśli to jest rozsądnie zaprojektowany system wykorzystywany do poważnych zastosowań, to:
1. Oranie po dysku nie powinno być szczególnie kosztowne, bo przecież pod spodem powinna być macierz i przynajmniej 1 półka z 24 dyskami (a to już ok. 3-4 kIOPS). Ja zawsze kiedy projektuję fizyczną warstwę, to serwer DB musi być enterprise class, w tym w szczególności mieć porządne karty FC i udostępniać odpowiednią liczbę kanałów
2. Jeśli wyników jest niedużo, to w sumie nie ma znaczenia, gdzie się to posortuje, bo wymagania na moc i pamięć nie będą duże

Jeśli to nie jest poważny system, to why care? Wtedy ważne, żeby w ogóle działało.

Oni. Nie wszyscy wychodzą z założenia, że "serwer DB musi być enterprise class"... Czasem jest tak, że baza mieści się np. w 60GB ramu i to jest optymalne. Po co inwestować w dyski? Zwykły RAID 10 na SATA wystarczy, no może jakieś SSD na logi transakcji. Wracając do tych unionów... posortowanie dużego zbioru danych wymaga dużo miejsca i mimo, że dane mieszczą się w ramie - do sortowania używany jest dysk. Tak samo wygląda sprawa z tabelami tymczasowymi. Może rozwiązaniem jest zrobienie dwóch osobnych zapytań i sortowanie na kliencie? Kto to może wiedzieć? :)

Z innej beczki. Ja, jak projektuję dostęp do danych to union pojawia się w raportach i z tego powodu nie jest to krytyczne. Tyle, że nie mam pojęcia co to za zapytanie. Czy jest optymalne, jak często jest wykonywane i czy czas wykonania jest krytyczny...

Na temat budżetu wiadomo tylko, że chodzi na PostgreSQLu, więc pewnie na FC nie ma co liczyć.

Temat: Jak efektywnie posortować wyniki zapytania UNION z bazy...

Jakub Fila:

Przemysław R.:
hmm
czasem warto zrobić temporaty table i założyć na niej indeks po dodaniu kompletu danych

zrobienie inserta do tabeli bez indeksów nie jest aż tak czasochłonne a suma sumarum może się opłacić

A dlaczego nie najpierw poindeksować a potem wstawiać? Myślisz, że narzut na wielokrotne równoważenie drzewa (indeksy) będzie dużo większy niż na jego budowę? Nie jestem tego pewien, trzeba by sprofilować.

Stare prawdy ludowe mówią, że właśnie jest tak jak napisałeś. Czyli, że opłaca się bardziej wstawiać do niepoindeksowanej tabeli. Ale co roku powstają nowe algorytmy, mechanizmy organizacji danych więc zgadzam się co do jednego - sprofilować nigdy nie zaszkodzi.