.NET in velika količina podatkov v bazi

Pomojem je problem, ker potrbuješ pri branju iz tabele Product_Property za vsako izbrano lastnost dodaten join. Verjetno se zadeva upočasni šele, ko je izbranih več lastnosti ali že pri prvi?

Baje ima Firebird "PLAN analyzer", ki deluje podobno kot EXPLAIN v mysqlu.

Preveri kako je z indexi, konfiguracijo baze, koliko ram-a lahko uporablja za hranjenje indexov itd...

Niste ta prvi, k ste se zaklal na microsoftovih tehnologijah.

Evo ti minus. Zakaj? Ker je brezvezen komentar, ki nima veze z originalnim vprašanjem. Zakaj pt.2? Ker sem že eksplicitno napisal, da se v te debate ne spuščam. Ker se mi ne da. Ker so zgolj 'versko prepričanje'.

Imaš predlog? Tudi na ne-microsoftovi tehnologiji? Bo več kot dobrodošel in se ti bom zanj lepo zahvalil.

Spartacus:

V SQL (Firebird SQL) bazi imam 3 tabele: Product (podatki o izdelkih), Property (možne lastnosti izdelkov) in Product_Property (lastnosti posameznih izdelkov, vmesna tabela)

Trenutno skupaj sestavljam filter (.NET web forms), ki bo na podlagi izbranih lastnosti vrnil spisek izdelkov, ki ustreza kriteriju. Do te točke je vse fine and dandy.

Problem pa se pojavi pri scenariju, ko gre za ogromno bazo: cca 200k izdelkov (Product), 40k lastnosti (Property) in približno 8 mio lastnosti izdelkov (Product_Property). Samo filtriranje traja precej predolgo, če program že vmes ne odleti zaradi premalo pomnilnika.

Ima kdo kakšen namig, izkušnjo, karkoli kako se te zadeve lotit? Kot že rečeno, gre za FirebirdSql bazo, na katero se .NET aplikacija poveže s pomočjo Firebird.NET providerja.

Hvala!

p.s.: Ker gre za integracijo na obstoječ sistem, bilokakšna prekopavanja baze ne pridejo v poštev. Lahko se doda kakšna zadeva, obstoječih tabel pa se ne sme dotikat.

je baza pravilno optimizirana?

A moraš vedno prikazati vse izdelke, ki ustrezajo izbranim filtrom?

Spartacus:

Evo ti minus. Zakaj? Ker je brezvezen komentar, ki nima veze z originalnim vprašanjem. Zakaj pt.2? Ker sem že eksplicitno napisal, da se v te debate ne spuščam. Ker se mi ne da. Ker so zgolj 'versko prepričanje'.

Imaš predlog? Tudi na ne-microsoftovi tehnologiji? Bo več kot dobrodošel in se ti bom zanj lepo zahvalil.

Moj komentar izraža sočutje.

Najprej je potrebno videti kveri. Potem pa še povej kakšne indekse imaš na teh 3 tabelah. Zelo verjetno ti dela kje full table scan. Sama količina podatkov ni problematična za izvedbo kverija, če so indeksi ok.

Tej začeti temi dolgujem še odgovor, hkrati pa sem ugotovil, da sem napisal premalo informacij, ki bi lahko pomagale pri iskanju odgovora, tako da se posipam s pepelom. Hkrati pa mi nekaj pravi, da tu ni ravno ogromno .NET programerjev (ta moment se spomnim samo na @mckmck, @ms3 in @urosbe) :)

Kljub temu pa - če se komu (tudi naključnemu obiskovalcu) privarčuje kakšna ura živcev, je pa že nekaj vredno :)

Skratka, problem ni bil direktno na bazi, ampak v implementaciji .NET rešitve. Bottleneck celotni zadevi so bili objekti tipa DataTable (s katerimi rešitev pač operira). V "starejšem" delu kode (ki je bila napisana pred nekaj leti) se je filtriranje delalo s pomočjo DataTable metode .Select(). Kar je delovalo, dokler ni prišlo do ogromne količine podatkov.

Potem pa smo filtriranje prepisali na LINQ in odzivni časi so se zmanjšali na 10% prvotne vrednosti. Tako ja, na 10% (torej, na eno desetino - iz ~90s na ~8-9s) prvotnega časa. Z vsakim tweakanjem pa se ta čas še manjša, tako da gremo očitno v pravo smer :)

hvala za tole!

sicer že par let nisem delal ničesar v .NET, ampak info je vsekakor koristen

@+1 .NET programer btw. Nevem sicer kako je v večjih firmah in vzdrževanjem teh aplikacij. Verjetno so še kar dataTable-i in podobno.

Kar smo novega delali v firmi je šlo vse z LINQ in FluentNHibernate. Stvari špilajo super. Pa naj bojo stvari še tako komplicirane.