[postgres 8.x] Wolny tsearch ?
mechcinski@tlen.pl - 12-11-2006 00:38
[postgres 8.x] Wolny tsearch ?
Witam, mam maly problem z optymalizacja bazy i zastanawiam sie czy
powinienem sie rozgladac za wlasnym serwerem czy moze uda mi sie
pociagnac to na czym stoi(wirtual - juz nie wiem ktory z kolei......)
Kluczowa tabela(400tys rekordow) "opisy" - ma kolumny : id,
opis(text).
W kolumnie 'opis' trzymam angielskojezyczne slowa kluczowe opisujace
zdjecia - przyklad: 'young beauty woman flower hand close-up', w jednym
opisie jest od kilkunastu do kilkudziesieciu slow kluczowych.
Najbardziej wydajnym rozwiazaniem okazl sie byc tsearch.
Indeksuje slowa-UPDATE opisy SET idxFTI=to_tsvector('default', opis);
zakladam index : CREATE INDEX idxFTI_idx ON opisy USING gist(idxFTI); -
czyli standardowo....
Oprocz tego mam tabele "foto" z pozostalymi informacjami o zdejcciach w
kilku kolumnach, rzecz jasna rekordow tyle samo, rozmiary: foto 280Mb
opisy 420Mb...
Moje pierwsze zdziwienie to rozniece w czasach dla zapytan:
select count(*) from foto - 2 sekundy
select count(*) from opisy - 20 sekund - pojecia nie mam skad takie
rozbierznosci ...przeciez ilosc rekordow jest ta sama ...
Wracajac do tsearcha - o ile zapytanie zwracajace porcje wynikow(i tu
sie nie dziwie ze dziala szybko):
SELECT id FROM opisy
WHERE idxfti @@ to_tsquery('default', 'summer & flower')
limit 100;
- ponizej sekundy
o tyle zapytanie zwracajace ilosc wszystkich pasujacych rekordow
SELECT count(*) FROM opisy
WHERE idxfti @@ to_tsquery('default', 'summer &
flower');
trwa juz bardzo dlugo....20-30 sekund dla zliczonych rekordow
stanowiacych >10% wszystkich....
Czy sam tseach dostarcza jakies procedury zliczajace - nie sadze...
A moze zajac sie konfiguracja tseracha , slowniki itd - ale tez nie
wydaje mi sie...
Czy da sie ta baze jescze w jakis sposob zoptymalizowac - nie sadze ...
Czy musze szukac maszyny - tak mi sie wydaje....
Pozdrawima
Mec
Wojtek pBT - 12-11-2006 01:29
Dnia 22-09-2006 o 21:15:19 <mechcinski@tlen.pl> napisał(a):
> Moje pierwsze zdziwienie to rozniece w czasach dla zapytan:
> select count(*) from foto - 2 sekundy
> select count(*) from opisy - 20 sekund - pojecia nie mam skad takie
> rozbierznosci ...przeciez ilosc rekordow jest ta sama ...
>
Twoje zdziwienie wynika z niedoczyania. W postgres nie warto używać do
testów count(*) bo jest bardzo nie miarodajne - a może właśnie
miarodajne... SQL musi sobie zliczyć wszystkie rekordy. I z nieznanych mi
powodów Postgres robi to wyjątkowo powolnie...
Nie jestem na super bierząco - ale raczej trudno to będzie bardziej
zoptymalizować... Możesz albo pokazywać: strona 1 2 ... AS kolejne albo
zmienić silnik
pozdro, pBT
--
Używam klienta poczty Opera Mail: http://www.opera.com/mail/
Bartek Siebab - 12-11-2006 01:30
> Dnia 22-09-2006 o 21:15:19 <mechcinski@tlen.pl> napisał(a):
>
>
>> Moje pierwsze zdziwienie to rozniece w czasach dla zapytan:
>> select count(*) from foto - 2 sekundy
>> select count(*) from opisy - 20 sekund - pojecia nie mam skad takie
>> rozbierznosci ...przeciez ilosc rekordow jest ta sama ...
A sprawdź jak będzie gdy ten count puścisz na pole z kluczem głównym
select count(polezkluczemglownym) from opisy;
--
..---------- -------- ------ ---- ---- --- - -- -
| Bartek `saphire` Siebab http://bartek.siebab.net
Paweł Matejski - 12-11-2006 01:30
mechcinski@tlen.pl wrote:
> Witam, mam maly problem z optymalizacja bazy i zastanawiam sie czy
> powinienem sie rozgladac za wlasnym serwerem czy moze uda mi sie
> pociagnac to na czym stoi(wirtual - juz nie wiem ktory z kolei......)
> Kluczowa tabela(400tys rekordow) "opisy" - ma kolumny : id,
> opis(text).
> W kolumnie 'opis' trzymam angielskojezyczne slowa kluczowe opisujace
> zdjecia - przyklad: 'young beauty woman flower hand close-up', w jednym
> opisie jest od kilkunastu do kilkudziesieciu slow kluczowych.
> Najbardziej wydajnym rozwiazaniem okazl sie byc tsearch.
> Indeksuje slowa-UPDATE opisy SET idxFTI=to_tsvector('default', opis);
> zakladam index : CREATE INDEX idxFTI_idx ON opisy USING gist(idxFTI); -
> czyli standardowo....
> Oprocz tego mam tabele "foto" z pozostalymi informacjami o zdejcciach w
> kilku kolumnach, rzecz jasna rekordow tyle samo, rozmiary: foto 280Mb
> opisy 420Mb...
> Moje pierwsze zdziwienie to rozniece w czasach dla zapytan:
> select count(*) from foto - 2 sekundy
> select count(*) from opisy - 20 sekund - pojecia nie mam skad takie
> rozbierznosci ...przeciez ilosc rekordow jest ta sama ...
Daj explain tych zapytań.
--
P.M.
herakles - 12-11-2006 01:30
mechcinski@tlen.pl wrote:
> Witam, mam maly problem z optymalizacja bazy i zastanawiam sie czy
> powinienem sie rozgladac za wlasnym serwerem czy moze uda mi sie
> pociagnac to na czym stoi(wirtual - juz nie wiem ktory z kolei......)
> Kluczowa tabela(400tys rekordow) "opisy" - ma kolumny : id,
> opis(text).
> W kolumnie 'opis' trzymam angielskojezyczne slowa kluczowe opisujace
> zdjecia - przyklad: 'young beauty woman flower hand close-up', w jednym
> opisie jest od kilkunastu do kilkudziesieciu slow kluczowych.
> Najbardziej wydajnym rozwiazaniem okazl sie byc tsearch.
> Indeksuje slowa-UPDATE opisy SET idxFTI=to_tsvector('default', opis);
> zakladam index : CREATE INDEX idxFTI_idx ON opisy USING gist(idxFTI); -
> czyli standardowo....
> Oprocz tego mam tabele "foto" z pozostalymi informacjami o zdejcciach w
> kilku kolumnach, rzecz jasna rekordow tyle samo, rozmiary: foto 280Mb
> opisy 420Mb...
> Moje pierwsze zdziwienie to rozniece w czasach dla zapytan:
> select count(*) from foto - 2 sekundy
> select count(*) from opisy - 20 sekund - pojecia nie mam skad takie
> rozbierznosci ...przeciez ilosc rekordow jest ta sama ...
Kiedyś odkryłem, że wszelkie operacje na tabelach w których jest dużo
danych(pole z długim opisem, pole z plikiem) w prostgrasie są bardzo
powolne jeśli nie używamy do identyfikacji rekordów primary keja albo
indeksu po innych polach, tzn. select count(pole_primary_key) będzie
szybki.
>
> Wracajac do tsearcha - o ile zapytanie zwracajace porcje wynikow(i tu
> sie nie dziwie ze dziala szybko):
> SELECT id FROM opisy
> WHERE idxfti @@ to_tsquery('default', 'summer & flower')
> limit 100;
> - ponizej sekundy
> o tyle zapytanie zwracajace ilosc wszystkich pasujacych rekordow
> SELECT count(*) FROM opisy
> WHERE idxfti @@ to_tsquery('default', 'summer &
> flower');
Bez sensu!!!
Robić dwa razy to samo.
dobrze jest stworzyć tabelkę, trzymającą wyniki zapytań i ją trigerować.
Zrób tak:
SELECT id into temp tymczas_id FROM opisy
WHERE idxfti @@ to_tsquery('default', 'summer & flower')
limit 100;
I teraz select count(id) from tymczas_id;
Oraz
select o.* from opisy o inner join tymczas_id t on t.id=o.id ...
To powinno śmiagać, oczywiście w przypadku gdy jest tam limit 100, jeśli
natomiast limit będzie dużo większy, to aby śmigało proponuje założyć
indeks na tabeli tymczasowej, albo z palca zrobić:
CREATE TEMP TABLE tymczas_id(.....
i zamiast: SELECT id into temp tymczas_id FROM opisy
WHERE idxfti @@ to_tsquery('default', 'summer & flower');
zrobić: insert into tymczas_id SELECT id FROM opisy
WHERE idxfti @@ to_tsquery('default', 'summer & flower');
CREATE INDEX .... na tymczas_id
Ważne indeks robić po tym insercie.
> trwa juz bardzo dlugo....20-30 sekund dla zliczonych rekordow
> stanowiacych >10% wszystkich....
>
> Czy sam tseach dostarcza jakies procedury zliczajace - nie sadze...
> A moze zajac sie konfiguracja tseracha , slowniki itd - ale tez nie
> wydaje mi sie...
> Czy da sie ta baze jescze w jakis sposob zoptymalizowac - nie sadze ...
Chcieć to móc, a móc to chcieć.
> Czy musze szukac maszyny - tak mi sie wydaje....
>
> Pozdrawima
> Mec
Wisisz mi flaszkę.
mechcinski@tlen.pl - 12-11-2006 01:31
Jesli chodzi o zliczanie po zindexowanej kolumnie - racja spora
poprawa.
herakles wrote:
> Bez sensu!!!
> Robić dwa razy to samo.
>
> dobrze jest stworzyć tabelkę, trzymającą wyniki zapytań i ją trigerować.
>
> Zrób tak:
> SELECT id into temp tymczas_id FROM opisy
> WHERE idxfti @@ to_tsquery('default', 'summer & flower')
> limit 100;
> I teraz select count(id) from tymczas_id;
> Oraz
> select o.* from opisy o inner join tymczas_id t on t.id=o.id ...
Tu sie raczej nie zrozumielismy...wyswietlajac wyniki wyszukiwania
pokazuje tez ich ilosc.
Wiec musze policzyc calosc wynikow i wyswitlic ich czesc..
> To powinno śmiagać, oczywiście w przypadku gdy jest tam limit 100, jeśli
> natomiast limit będzie dużo większy, to aby śmigało proponuje założyć
> indeks na tabeli tymczasowej, albo z palca zrobić:
> CREATE TEMP TABLE tymczas_id(.....
> i zamiast: SELECT id into temp tymczas_id FROM opisy
> WHERE idxfti @@ to_tsquery('default', 'summer & flower');
> zrobić: insert into tymczas_id SELECT id FROM opisy
> WHERE idxfti @@ to_tsquery('default', 'summer & flower');
> CREATE INDEX .... na tymczas_id
>
> Ważne indeks robić po tym insercie.
Idac tym tropem - mozna zakladac indeksy na tabeli tymczasowej ?
Jesli jednak mozna - wrzucenie wynikw do tabeli, zalozenie ne tej
tabeli indeksu, zliczenie rekordow tej tabeli bedzie szybsze ????
> Chcieć to móc, a móc to chcieć.
hehe lepsze to niz "jak sie nie ma co sie lubi to sie lubi co sie ma
".....
> Wisisz mi flaszkę.
mam gest - ballantines dla Ciebie
Mam wrazenie ze doszedelem do granicy wydajnosciowej maszyny i
postgresa...
Kiedys Ronald Kuczek zaproponowal na grupie (http://tinyurl.com/roarn)
rozwiazenie:
swish-e.
Wyszukiwanie pelnotekstowe oferowane przez tsearcha wysiada.Sprawdzone
- ten sam sprzet te saeme dane - postgres niestety wolnijeszy kilkaset
razy...
Tylko zastanawiam sie...o ile wyszukanie za pomoca swish-e jest malo
kosztowne, o tyle wrzucenie do postgresa z "zewnatrz" powiedzmy 30tys
identyfikatorow + join na tej tabeli to juz swoje kosztuje ?
Mec
herakles - 12-11-2006 01:31
mechcinski@tlen.pl wrote:
> Jesli chodzi o zliczanie po zindexowanej kolumnie - racja spora
> poprawa.
>
> herakles wrote:
>
>> Bez sensu!!!
>> Robić dwa razy to samo.
>>
>> dobrze jest stworzyć tabelkę, trzymającą wyniki zapytań i ją trigerować.
>>
>> Zrób tak:
>> SELECT id into temp tymczas_id FROM opisy
>> WHERE idxfti @@ to_tsquery('default', 'summer & flower')
>> limit 100;
>> I teraz select count(id) from tymczas_id;
>> Oraz
>> select o.* from opisy o inner join tymczas_id t on t.id=o.id ...
>
> Tu sie raczej nie zrozumielismy...wyswietlajac wyniki wyszukiwania
> pokazuje tez ich ilosc.
> Wiec musze policzyc calosc wynikow i wyswitlic ich czesc..
to wywal limit, tylko uważaj na szukanie spacji itp.
>
>> To powinno śmiagać, oczywiście w przypadku gdy jest tam limit 100, jeśli
>> natomiast limit będzie dużo większy, to aby śmigało proponuje założyć
>> indeks na tabeli tymczasowej, albo z palca zrobić:
>> CREATE TEMP TABLE tymczas_id(.....
>> i zamiast: SELECT id into temp tymczas_id FROM opisy
>> WHERE idxfti @@ to_tsquery('default', 'summer & flower');
>> zrobić: insert into tymczas_id SELECT id FROM opisy
>> WHERE idxfti @@ to_tsquery('default', 'summer & flower');
>> CREATE INDEX .... na tymczas_id
>>
>> Ważne indeks robić po tym insercie.
>
> Idac tym tropem - mozna zakladac indeksy na tabeli tymczasowej ?
TAK i z wolnej spuchniętej tabeli tymczaoswej, robi się zaje.. szybka
zmienna do obliczeń.
> Jesli jednak mozna - wrzucenie wynikw do tabeli, zalozenie ne tej
> tabeli indeksu, zliczenie rekordow tej tabeli bedzie szybsze ????
tak, bo znalazłeś powiedzmy 1000 wyników, wrzucasz je do tabeli tymczasowej
i już takie rzeczy jak county, czy kolejne wyświetlanie kolejnych wyników
robisz już na tej tabeli nie wyszukując za każdym razem bo już masz
wyszukane.
>
>
>> Chcieć to móc, a móc to chcieć.
>
> hehe lepsze to niz "jak sie nie ma co sie lubi to sie lubi co sie ma
> ".....
>
>> Wisisz mi flaszkę.
> mam gest - ballantines dla Ciebie
To jeszcze łinstony i łintermensy poproszę.
>
> Mam wrazenie ze doszedelem do granicy wydajnosciowej maszyny i
> postgresa...
Nie zawsze gdzieś się da coś przekopać i przyśpieszyć, w tej bazie, tylko
trzeba wykombinować jak. Natomiast problemem trudnym do załatwienia będzie
przyśpieszenie samego tserach, wtedy za to możesz spróbować zastosować
inny, mniej kobylasty.
> Kiedys Ronald Kuczek zaproponowal na grupie (http://tinyurl.com/roarn)
> rozwiazenie:
> swish-e.
> Wyszukiwanie pelnotekstowe oferowane przez tsearcha wysiada.Sprawdzone
> - ten sam sprzet te saeme dane - postgres niestety wolnijeszy kilkaset
> razy...
>
> Tylko zastanawiam sie...o ile wyszukanie za pomoca swish-e jest malo
> kosztowne, o tyle wrzucenie do postgresa z "zewnatrz" powiedzmy 30tys
> identyfikatorow + join na tej tabeli to juz swoje kosztuje ?
Samo wrzucenie może być bardzo kosztowne w przypadku 30 000 i inserta, ale
postgres ma inną lepszą metodę, mianowicie copy, a jeśli chodzi o
szczegółowy insert, to można zrobić copy do temp tabeli, a potem insert
into ... select ... from temp_tabela
mechcinski@tlen.pl - 12-11-2006 01:32
herakles wrote:
> > Jesli jednak mozna - wrzucenie wynikw do tabeli, zalozenie ne tej
> > tabeli indeksu, zliczenie rekordow tej tabeli bedzie szybsze ????
> tak, bo znalazłeś powiedzmy 1000 wyników, wrzucasz je do tabeli tymczasowej
> i już takie rzeczy jak county, czy kolejne wyświetlanie kolejnych wyników
> robisz już na tej tabeli nie wyszukując za każdym razem bo już masz
> wyszukane.
najbardziej czasochlonne jest zliczanie wszystkich wynikow,
wyszukiwanie porcji wynikow dziala szybko...
> Nie zawsze gdzieś się da coś przekopać i przyśpieszyć, w tej bazie, tylko
> trzeba wykombinować jak. Natomiast problemem trudnym do załatwienia będzie
> przyśpieszenie samego tserach, wtedy za to możesz spróbować zastosować
> inny, mniej kobylasty.
Jesli jest jakis fulltext do postgresa oprocz tsearcha - chetnie
potestuje. Znasz jaksi ?
Pozdrawiam
Mec
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
[PostgreSQL] - jak =?ISO-8859-2?Q?zabezpieczy=E6_interesy_tw?==?ISO-8859-2?Q?=F3rcy_systemu_=3F=3F=3F?=
postgresql - int/int
postgresql Select count(*) czy raczej Select count(ID)
[PostgreSQL] jak =?ISO-8859-2?Q?pobra=E6_warto=B6=E6_zwracan?==?ISO-8859-2?Q?=B1_przez_funkcj=EA=3F?=
[postgresql] INSERT OR UPDATE - jak =?ISO-8859-2?Q?b=EAdzie_na?==?ISO-8859-2?Q?jlepiej=3F?=
[postgresql] kilka =?ISO-8859-2?Q?rekord=F3w_subquery_jako_?==?ISO-8859-2?Q?string?=
[PostgreSQL] Jak =?ISO-8859-2?Q?po=B3=B1czy=E6_funkcje_z_w?==?ISO-8859-2?Q?idokiem?=
Postgres - replikcja master-master
Dopasowanie do "najlepszego" dopasowania :) [ PostgreSQL]
Problemy z =?ISO-8859-2?Q?instalacj=B1_PostgreSQL_na_syste?==?ISO-8859-2?Q?mach_Windows?=
zanotowane.pldoc.pisz.plpdf.pisz.plnatalia97.htw.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
