[PostgreSQL] Czy Postgre da radę Opcje

[dado]

Mamy pytanie dotyczące sensu stawiana bazy na silniku postgre danych w przypadku gdy :

- baza zawiera ok. 400 milionów rekordów. Rozmiar rekordu od 120 do 950 bajtów.
- nie można tworzyć kluczy primary key bo dane w kolumnach nie są unikalne.
- baza ma pracować online wystawiona w intenrnecie z średnio 4,5 userami online.
- zapytania do bazy danych odwołują się do 3-6 tabel jednocześnie.

Baza zawiera wszystkie części samochodowe świata.

Czy jedynym wyjściem jest tutaj oracle?

W tym momencie zapytanie o wyświetelenie 30 rekordów w pgadminie do jednej z głównych tabel trwa około 4 minut. (tabela przeindeksowana i klastrowana)

Może ktoś borykał się z takimi bazami.

będę wdzięczny za każdą odpowiedź.

Ten post edytował dado 15.10.2008, 08:54:18

[calebos]

Sprawdzanie co robi zapytanie:

[SQL] pobierz, plaintext 
EXPLAIN SELECT...
[SQL] pobierz, plaintext 

To ze powiedziales że nie ma unikanlej wartości mowi o tym ze nie do konca ta tablica jest odpowiedno znormalizowana i może udałoby sie cos utargowac jakims rozbiciem, ale z tego co podajesz pozniej wyglada na to ze jest chyba ok.
Przy takiej ilosci rekordow pamietaj o problemie z powtarzalnoscia danych..

Nie znam sie na postgresie ale btree to chyba najprostsza forma indeksu nie ma tam czegos bardziej zmyslnego zeby operowal na wiekszych wycinkach wartosci kolumny? Takie drzewo to zamulacz i predzej trafisz skanujac tablice za pelna wartoscia jak chodzac po drzewie.

Muszisz krok po kroku robic sobie te zapytania i analizowac EXPLAIN oraz czas wykonania zapytania.
Na poczatku pytaj po prostu jedna kolumne bez zadnych ORDER itp,bez indeksow itp i analizuj sobie jak to dziala.
Nie daj sie oszukac buforowi bazy bo moze Ci cos zapamietac (zobacz jaka jest komenda na wyczyszczanie).

Na koniec jesli bedziesz wykonywac takie zapytania jak np
tab.kategoria=KLOCKI
tab.marka=VOLVO
tab.rok between X and Y

To mozesz utworzyc sobie indeksy na wielu kolumnach. Przeczytaj dokumentacje bo one dzialaja w momencie kiedy pytasz o 3 kolumny a jak juz zapytasz o 1 to ten indeks nie dziala (jakos tak).

Optymalizatory sa dziwne i trzeba patrzec co robia.

Np mysql nie radzi sobie z GROUP BY podczas laczenia 3 tablic a mogloby sie wydawac ze takie przypadki juz bedzie w stanie sobie rozpracowac.

Na koniec mozesz sie zastanowic nad cachem takich zapytan do talic pomocniczych oraz nad silnikiem wyszukiwania po frazie tez na tablicy pomocniczej.

PS. Tez jestem z Czestochowy wiec jak bedziesz potrzebowal wiecej pomocy to wal

Ten post edytował calebos 21.10.2008, 09:56:44

[phpion]

To mozesz utworzyc sobie indeksy na wielu kolumnach. Przeczytaj dokumentacje bo one dzialaja w momencie kiedy pytasz o 3 kolumny a jak juz zapytasz o 1 to ten indeks nie dziala (jakos tak).

Nie zgodzę się. Prawda jest taka, że pierwsza kolumna z indexu wielokolumnowego determinuje użycie danego indeksu. Jeżeli natomiast w warunku zostanie użyta np. druga kolumna to indeks również będzie pomocny ale jego "skuteczność" będzie niższa niż rozpoczęcie listy warunków od pierwszej kolumny indeksu. Nie można jednak powiedzieć, że indeks w ogóle nie zostanie użyty.

[calebos]

Nie zgodzę się. Prawda jest taka, że pierwsza kolumna z indexu wielokolumnowego determinuje użycie danego indeksu. Jeżeli natomiast w warunku zostanie użyta np. druga kolumna to indeks również będzie pomocny ale jego "skuteczność" będzie niższa niż rozpoczęcie listy warunków od pierwszej kolumny indeksu. Nie można jednak powiedzieć, że indeks w ogóle nie zostanie użyty.

Tez nie do konca piszesz prawde. Chodzi o roznice w zasadzie dzialania indeksu. W przypadku Postgre i uzyciu B-tree ten indeks zostanie uzyty tak jak napisales ale przy uzyciu gist juz jest uwarunkowany uzyciem pierwszej kolumny w warunkach.
MySQL tez nie uzyje indeksu przy uzyciu tylko 2 kolumny z indeksu musi miec pierwsza.