Drzewa jeszcze raz, ale inaczej
Mikolaj Rydzewski - 14-12-2006 16:08
Drzewa jeszcze raz, ale inaczej
Witam,
Jest sobie nastepujaca struktura danych: drzewo obiektow (O). Ma ono
swoj korzen, kazdy obiekt moze miec ilosc swoich podobiektow. Nic
nadzwyczajnego. Jednak kazdy z tych obiektow O posiada zestaw pewnych
wlasciwosci (para klucz-wartosc). Obiekty dzieci O dziedzicza po
rodzicach zestaw ich wlasciwosci, moga tez 'nadpisac' wartosc
wlasciwosci rodzica swoja wartoscia.
Zeby bylo jasniej:
Obiekt O z wlasciwosciami (p1=>wartosc1 i p2=>wartosc2).
Obiekt O2 (dziecko O) automatycznie posiada wszystkie wlasciwosci
obiektu O.
Obiekt O3 (dziecko O2) poprzez nadpisanie jednej wlasciwosci oraz
dodanie nowej posiada taka ich liste: (p1=>wartoscO3, p2=>wartosc2,
p3=>wartosc3).
Oryginalnie wszystkie dane byly trzymane w wielu plikach XML. Zeby
jednak jakos sensownie to przeszukiwac zaimportowalem calosc do bazy
SQL. Zeby uproscic zapytania to z poziomu bazy nie ma dziedziczenia
wlasciwosci - kazdy rekord obiektu O posiada tyle rekordow w relacji 1-*
ile posiada on swoich (w tym dziedziczonych) wlasciwosci.
Do bazy sa zadawane pytania w rodzaju: znajdz obiekty O ktore posiadaja
(lub nie) okreslona wlasciwosc(i) (o okreslonej wartosci).
Jednak przy tej ilosci rekordow ktore mi powstaly w bazie (6tys glownych
i 3.5mln wlasciwosci) wydajnosc nie jest rewelacyjna. Pomijam duplikacje
danych, to nie jest problem. Interesuje mnie rozwiazanie, struktura bazy
i algorytm przeszukiwania, aby calosc byla wydajna. Jest sens sie o to
bic, czy tez taka wielka tabela ma szanse dzialac szybko i mam sie
skupic na konfiguracji samej bazy (i serwera)? Jakies pomysly?
Oczywiscie indeksy na odpowiednich polach sa ustawione. vacuum full
analyze (jest to postgres) zrobiony.
--
Mikolaj Rydzewski <miki@ceti.pl> http://ceti.pl/~miki/
PGP KeyID: 8b12ab02
There are three kinds of people: men, women, and unix.
hubert depesz lubaczewski - 14-12-2006 16:08
On 2006-11-30, Mikolaj Rydzewski <miki@ceti.pl> wrote:
> Jednak przy tej ilosci rekordow ktore mi powstaly w bazie (6tys glownych
> i 3.5mln wlasciwosci) wydajnosc nie jest rewelacyjna. Pomijam duplikacje
> danych, to nie jest problem. Interesuje mnie rozwiazanie, struktura bazy
> i algorytm przeszukiwania, aby calosc byla wydajna. Jest sens sie o to
> bic, czy tez taka wielka tabela ma szanse dzialac szybko i mam sie
> skupic na konfiguracji samej bazy (i serwera)? Jakies pomysly?
1. nie wiem jaka struktura, ani jakie zapytania. pokaz strukture,
zapytanie, explain analyze zapytania.
2. jak nie mozesz nic wycisnac indeksami, to zmien strukture - np. dodaj
tabele cache'ujaca cechy.
depesz
--
http://www.depesz.com/ -> nowy, jeszcze lepszy, depesz
Mikolaj Rydzewski - 14-12-2006 16:08
hubert depesz lubaczewski <depesz@depesz.com> wrote:
> 1. nie wiem jaka struktura, ani jakie zapytania. pokaz strukture,
> zapytanie, explain analyze zapytania.
W tej chwili nie mam dostepu do kodu zeby dokladnie podac zapytania, ale struktura
jest wg mnie typowa (pokazuje istotne pola):
-- glowna tabela z obiektami
table objects (
id int primary key,
parent_id int references objects(id) -- obiekt rodzic
)
-- tabela z wlasciwosciami obiektow
table properties (
id int primary key,
object_id int references objects(id),
property_id int references property_dict(id) -- slownik wlasciwosci
)
-- kazda z wlasciwosci moze miec wiele wartosci
table properties_values (
id int primary key,
property_id int references properties(id),
varchar value
)
Do takiej struktury ciezko chyba napisac zle zapytanie ;-)
W moim rozwiazaniu jesli np. glowny obiekt posiada przypisanych 100
wlasciwosci. I posiada on np. 200 obiektow-dzieci, to rekordow w tabeli
properties zrobi sie 200*100 = 20000. Nawet w przypadku gdy zaden z
obiektow-dzieci moze nie nadpisywac wlasciwosci rodzica.
Jak pisalem w bazie rzeczywistej wartosci te wynosza 6tys/3.5mln.
To czy zapytania chodza wolno to kwestia wzgledna ;-) Jestem ciekaw czy
uzywajac bardziej wymyslnej struktury daloby sie wycisnac lepszy wynik.
O ile sama obsluga drzewka w bazie SQL jest czesto opisywana (chocby na
tej grupie) to nie mam pomyslu na te 'dziedziczone wlasciwosci'.
> 2. jak nie mozesz nic wycisnac indeksami, to zmien strukture - np. dodaj
> tabele cache'ujaca cechy.
Mozesz rozwinac temat?
--
Mikolaj Rydzewski <miki@ceti.pl> http://ceti.pl/~miki/
PGP KeyID: 8b12ab02
There are three kinds of people: men, women, and unix.
zarafiq@poczta.onet.pl - 14-12-2006 16:08
> W moim rozwiazaniu jesli np. glowny obiekt posiada przypisanych 100
> wlasciwosci. I posiada on np. 200 obiektow-dzieci, to rekordow w tabeli
> properties zrobi sie 200*100 = 20000. Nawet w przypadku gdy zaden z
> obiektow-dzieci moze nie nadpisywac wlasciwosci rodzica.
> Jak pisalem w bazie rzeczywistej wartosci te wynosza 6tys/3.5mln.
A jaka jest ?rednia odleg?o?? od li?cia do korzenia? Je?li nie jest to daleko
to by? mo?e przez to kopiowanie w?a?ciwo?ci zyskujesz na prostocie
trac?c sporo na wydajno?ci.
> To czy zapytania chodza wolno to kwestia wzgledna ;-) Jestem ciekaw czy
No to napisz jak chodz? i jak by? chcia? ?eby chodzi?y.
Pozdrawiam
zarafiq
--
Wys?ano z serwisu OnetNiusy: http://niusy.onet.pl
hubert depesz lubaczewski - 14-12-2006 16:08
On 2006-11-30, Mikolaj Rydzewski <miki@ceti.pl> wrote:
> To czy zapytania chodza wolno to kwestia wzgledna ;-) Jestem ciekaw czy
> uzywajac bardziej wymyslnej struktury daloby sie wycisnac lepszy wynik.
> O ile sama obsluga drzewka w bazie SQL jest czesto opisywana (chocby na
> tej grupie) to nie mam pomyslu na te 'dziedziczone wlasciwosci'.
wydaje mi si?, ?e u?ywaj?c kilku prostych tricków (5 metoda drzew z faq,
distinct on, sprytne indeksy) powinno si? to da? zrobi? w czasie
pomijalnym.
>> 2. jak nie mozesz nic wycisnac indeksami, to zmien strukture - np. dodaj
>> tabele cache'ujaca cechy.
> Mozesz rozwinac temat?
triggery na tablice z cechami które aktualizuj? "cache" (w innej
tabeli), tak aby odpytanie o cechy by?o:
select * from cache where object_id = XXX;
depesz
--
http://www.depesz.com/ -> nowy, jeszcze lepszy, depesz
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
=?iso-8859-2?Q?=5BMS_SQL=5D_Czy_mo=BFna_wywo=B3a=E6_funkcje_t ylko_raz_dla?==?iso-8859-2?Q?_ca=B3ego_zbioru_=BCr=F3d=B3owego=3F?=
[MySQL] Zapytanie z =?ISO-8859-2?Q?dw=F3ch_tabel_na_raz_?==?ISO-8859-2?Q?i_grupowanie_po_wsp=F3lnym_polu=2E_Jak_=3F?=
mysql / drzewa / produkty jak to =?ISO-8859-2?Q?zrobi=E6_jedny?==?ISO-8859-2?Q?m_zapytaniem=3F?=
Re: Gdzie mozna jeszcze kupic Microsoft SQL 2000 Enterprise Edition??
Szkolenia z Microsoft Navision dofinansowane z UE - brakuje jeszcze4 ,osob - sorry za powtorke
=?ISO-8859-2?Q?[MS_SQL]_update_wielu_p=F3l_na_raz_z_selecta?=
[MySQL] - konwersja polskich znaków i jeszcze małe "conieco"
bazy danych typu open source jeszcze za slabe, ale...
(sprzedam) Wacom Intuos3 A4 -jeszcze 10 godzin:)
conversja typow z zasadami matematyki
zanotowane.pldoc.pisz.plpdf.pisz.plczterowers.keep.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 |
|
