Dotaz: Počet sloupců - výkon DB

[Radeczek]

Zdravím vás, před nějakou dobou jsem přebral databázi jednoho e-shopu, který prodává oblečení. V tabulce "produkty" jsou přirozeně uložené produkty. Jenže, někdo, kdo ten e-shop dělal, pouze předělával obchod s mobily tak, aby to prostě "nějak" fungovalo. Problém je v tom, že tabulka produkty má asi 50 sloupců, kde +- 20 jsou sloupce typu "GPRS", "INFRAPORT", "BATERIE", "PAMĚŤOVÁ KARTA" atp. A tyto sloupce jsou prázdné.

Můj dotaz tedy zní: "Má počet (ač prázdných) sloupců vliv na výkon databáze? (Rychlost složitějších joinů, počítání množství produktů v daných kategoriích atp.) ??"

Děkuji za reakce.

---

---

Odpovědi

[Filip Jirsák]

Určitě to má vliv na šířku věty v databázi a tedy na to, kolik dat se musí načíst při sekvenčním čtení. Záleží samozřejmě na tom, jaké jsou to datové typy… Na dotazy, které využívají indexy, by to nemělo mít vliv.

[kuka]

To asi zalezi na konkretni databazi, zda to vubec uklada a kolik to zabira mista. Napr. v Oracle se prazdne sloupce na konci radku vubec fyzicky neukladaji a pokud se prazdny sloupec uklada, zabira 1 byte. Obecne jakekoliv zbytecne nafouknuti radku vede k tomu, ze se do datoveho bloku vejde mene zaznamu a tedy se cte z disku vice bloku, mene zaznamu se vejde do cache atd., coz ma dopad na vykon (v ruznych scenarich samozrejme ruzne velky).

[Kit]

Zbytečné sloupce mají sice negativní vliv na výkon databáze, ale ve většině běžných případů bude ten výkonový propad stěží měřitelný. Zejména pokud ty sloupce jsou typu VARCHAR apod.

[radeczek]

Abych to upřesnil... jedná se o MySQL databázi, tabulka má cca 80 sloupců z toho 25 je VARCHAR(255) a je to prázdné.

Někdo tady zmínil, že to sice zrychlí, ale nepatrně... tzn. Když mám dotaz, který trvá třeba 10s zlepší se to nějakou desetinku? Nebo třeba o sekundu?

Či bude vyřízení jednotlivých dotazů stejně rychlé, jen se db "odlehčí" - bude se méně číst z disku, více věcí se vleze do cache, ale na rychlost nějakých složitějších joinů a countů to moc extra vliv mít nebude. Je tak?

[Kit]

Pokud bude zpracování dotazu na tak malém objemu dat trvat 10 sekund, svědčí to spíš o tom, že je špatně napsán nebo že je chybný datový model. V takovém případě se odstranění nadbytečných sloupců na rychlosti téměř neprojeví.

Jinými slovy: Pokud to chceš předělat, začni u nového datového modelu, udělej ho znovu a pořádně. V opačném případě bych to nechal být. Nesystémovým odebíráním sloupců si moc nepomůžeš.

Samozřejmě se v tom můžeš vrtat pro zábavu, v tom ti bránit nebudu. Bude to hezčí a něco se přitom naučíš, ale bez radikální změny nějaké zrychlení nečekej.

Také můžeš změnit databázi.

[radeczek]

Ok, těch 10s byl jen příklad. Jo DB je dost blbě (podle mě) udělaná, ale nějak zásadně to předělávat nebudu... je na to napojeno až moc věcí, aby to stálo za to úsilí. Objem dat je docela solidní (je tam kolem 60 000 položek, joiny jsou asi 3)

Nějak zvlášt řešit to teda nebudu. Spíš mě to jen tak zajímalo, nakolik by se to zrychlilo ;)

Dík moc.

[Michal Kubeček]

Jestli je těch sloupců 80, tak je ta struktura postavená na hlavu bez ohledu na to, co to udělá s výkonem.

[radeczek]

Jo, je to dost mizerně navržené... Prostě aby to "nějak" fungovalo bez ohledu na cokoliv jiného... Celé to předělávat nebudu, je na tom závislých několik desítek tísíc řádků opravdů _hnusného_ kódu. Je velice odstrašující případ proč kód prasit ;)

Šlo mi jen o to, zda by za minimální úsilí nešla ta DB trošku zrychlit ;)

[Michal Kubeček]

Ono by koneckonců bylo divné, kdyby byl zprasený jen návrh databáze a aplikace už ne. :-)

[Pavel Kysilka]

zdravim,

tak predelat to muzete. Vyuzijte pohledu/VIEW. Ona aplikace moc nepozna, ze se dotazuje na pohled nez na tabulku.

Me neco podobneho ceka na jedne moji starsi aplikaci, kde jsem tak nejak kombinoval nazvy sloupcu cesky a anglicky....

gf

[l0gik]

Z hlediska výkonu bych to neřešil, pokud tam nebudou statisíce výrobků. Největší problém vidím v tom, že budeš chtít podle těch sloupců třeba někdy vyhledávat, což znamená padesát indexů - a to zaplácne cache databáze. Ale při dnešní ceně pamětí a očekávaný velikosti dat (předpokládám, že jde o eshop) to je asi jedno.

Spíš bych přemejšlel z hlediska architektury, jestli nestojí za to to předělat na spešl tabulku vlastnost - hodnota. Např. proto, že do týdle tabulky těžko uložíš dvě možné hodnoty, např. možnost volby dvou baterií a vůbec se s tím pracuje daleko lépe (např. výpis všech vlastností, vlastností patřících do dané skupiny, tvorba různých filtrů atd...).

[b0rmann]

autor "databazi" je zrejme clovek z mozkem tezce poskozenym excelem, a o normalizaci zrejme neslysel ani v tramvaji.

[FooBar]

EAV je naprosto standardni metoda ukladani dat tohohle druhu, i kdyz nejde o relacni ukladani dat. Viz: http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model

Agresivni reakce je lepsi si setrit pro vetsi ulety :)

[Josef Kufner]

Koukni na explain často používaných dotazů a udělej dobře indexy. Tím tomu asi pomůžeš nejlíp.

Pokud ty sloupečky nevyužíváš, tak je smaž. Udělej si jejich seznam, grepni zdrojáky a uvidíš sám.

[dzolo]

DD,

pokud prázdné sloupce nejsou indexy, tak by to výkon nemělo ovlivnit. Problém bývá jen u indexů, které mají velký počet prázdných hodnot (NULL).

[Xerces]

Tak jak jsi to popsal bych se v tom nevrtal (jak píše Kit?). 60k řádků je nic, záleží samozřejmě na čem to běhá. BTW: A o přepsání celýho systému včetně app neuvažuješ? Jinak podle hesla, když něco funguje tak na to nesahej.

[Kit]

To souhlasí. Na tak malou databázi bych buď vůbec nesahal, anebo ji celou předělal. I obyčejné CSV na tak malém objemu dat často podá lepší výkon, než databáze indexovaná podle všech sloupců takto nesmyslně navržené tabulky.