Vlákno názorů k článku [ ( LEFT|RIGHT [ OUTER ])| INNER ] JOIN v SQL od Radim Kolář - normalizace dat je taky napytel, je to sice...
-
normalizace dat je taky napytel, je to sice napohled hezke a vseobecne uznavano jako dobry design. Ale kdyz mate velke tabulky tak si zatracene rychle zacnete uvedomovat jak pridani kazde dalsi tabulky do selectu brzdi.
Dnes neni zadny duvod pro normalizaci za kazdou cenu. Mista na disku a v pameti je vice nez dost a sekvencni pristup je rychly.
Sekvencni nacitani denormalizovane tabulky je mnohem rychlejsi nez behani po 3 ruznych tabulkach soucasne. Sekvencni cteni je minimalne 5-8x rychlejsi nez nahodny pristup a dnesni storage servery umi z pole sekvencne cist 2GBajty/sec. Pod pojmem storage server nemyslim zadny uber highend, ale nic zvlastniho bezne pouzivany stroj za cca $35K s rekneme 50ti lowend sata disky. Storage server s SAS 15k rpm disky ma podstatne lepsi prujezd, tomu taky odpovida cena. -
Anonymní Pepa (neregistrovaný)Ona se taky databázová architektura nejdříve normalizuje (třeba až na 5. formu), ale pak se zase musí denormalizovat podle datové logiky a způsobu práce s daty. Univerzální architektura neexistuje.
A rychlost načítání není jediné omezení. Namátko - velikost tuplu,velikost rezervované paměti a další. Kvalita dat (je třeba si uvědomit, ře použití indexu je efeketivní při zhruba odfiltrování 20-50% záznamů, jinak se použije fullscan) je otázka, kterou je velmi brát v potaz! -
Zkuste si auditovat pár shopů jako já a zjistíte, že to není pravda. Sekvenční čtení je samozřejmě rychlejší, mimochodem sekvenční čtení se použije i když spojujete tabulky, ale má jeden dost nepříjemný důsledek. Dost Vám zacloumá s cache. Přístup do denormalizovaných tabulek není tak častý (většinou se jedná o analýzy, reporty) a je mnohem efektivnější použít OLAP nebo materializované tabulky. Docela dost se setkávám s tím, že místo toho, aby ve firmě nasadili OLAP, tak právě vymýšlejí takovéto brikule. Tím problém nevyřeší, a ještě mají problém s hw. Hlavní důvod pro normalizaci je dekompozice dat. Pokud máte dobře dekomponovaná data, budou se dobře psát selecty. Pokud máte denormalizovaná data, pak v podstatě používáte SQL jen jako data storage, a vlastně SQL Vám je spíš na škodu než k užitku. -
J (neregistrovaný)Hmm, no nevim, pracuju s takovou pidi databazickou(vsehovsudy 60GB), ale kazdodene mam chut rozbit jejimu navrhari hubu, jelikoz to co by se pri rozumnem navrhu dalo delat v jednotkach ms trva sekundy a to celkem bez ohledu na vykon HW ...
Takove veci jako zamykani se vyvojarum asi resit nechtelo vubec, takze stav kdy kvuli selectu do DB stoji 1/2 firmy je celkem normal ... no a nez bych se dockal od vyvojaru, vysesil sem si to radsi sam, stacilo semo tamo pridat index ... -
anonymníNo jednak je to dane tym, ze aj Oracle moze byt 'zadara' - http://www.oracle.com/technology/products/database/xe/index.html
alebo tym, ze nikto normalny sa nerozhodne prevadzkovat vacsi system na SATA do desktopu...
Pritom 2xRaptor (ak uz sme na desktope) je treba len na Redo logy, este stale treba aspon 3 na storage a minimalne dalsi na system.
Mozno prave preto su to vacsinou chytre polia, ktorych cena ide v pohode do nasobkov 100k.
Teraz ma napada, ze Raid 5 asi bezne na desktope nie je, takze este jeden do 0+1 raidu... Potom sa niet co cudovat, ze za 50k len za disky ma clovek ani nie 200G na databazu ;-) -
Rejpal (neregistrovaný)
• Supports up to 4GB of user data (in addition to Oracle system data) • Single instance only of Oracle Database XE on any server • May be installed on a multiple CPU server, but only executes on one processor in any server • May be installed on a server with any amount of memory, but will only use up to 1GB RAM of available memory
No to je výhra. ;-) S Firebirdem redo log nepotřebuju -> ušetřím na těch dvou discích. ;-) Raptor je taky polospotřební zboží, dyť už je dělají i "s okýnkem", bůh ví, co je to za mechaniku. :-/ A to "chytré pole" je přeci jen cenově někde trošku jinde, ne? BTW, žil jsem v domnění, že RAID 5 pro databázi s mnoha zápisy nemá smysl. -
anonymníAle iste... Ani Oracle nemusi mat na Redo logy vlastny strip :-) Dat ich sice na ten isty disk ako ostatne je fakt hovadina, ale ked tomu systemu budete davat riadne po cuni, bude radi,ze ich mate v stripe...
http://en.wikipedia.org/wiki/Redo_log -
Rejpal (neregistrovaný)Díky za upozornění, ale já vím, co je Redo Log. Kdybych měl Oracle, určitě bych nějaký potřeboval a nějaký disk by se pro něj našel, ale naštěstí používám Firebird, který ukládá delta-komprimované zpětné verze řádků na totožnou databázovou stránku (což v drtivé většně případů ani nepřeteče, ani to nevyžaduje samostatnou diskovou operaci kvůli logu).
-
anonymníO FB viem len tolko, ze existuje... Ale na druhu stranu nevidim moc efektivitu v ukladani cohokolvek na 60 miest na disku, ked to mozem v sequencnom zapise natlacit na rychle medium! A to je IMO to najpodstatnejsie na REDO logu... Ide sequencne a len pise... na 60 miest v DB sa to moze nasledne sypat aj 10 hodin ;-)
-
Rejpal (neregistrovaný)A po dobu deseti hodin ta data nebudou vůbec vidět, nebo to z toho logu bude engine tahat nepříliš efektivními metodami "bokem"? Já tedy nevím, ale snad všechny databáze se starají o to, aby se data flushovala na disk nějakým rozumným způsobem. :-) Pominu-li bulk load, tak nevidím potřebu zapisovat padesát MB za sekundu na jeden disk. Dvacet pět let nasazení a statisíce instalací prokazují, že i bez logu bokem to "just works". Čím neříkám, že log navíc není pěkný, zřejmě umožňuje nějaké ty vychytávky navíc, nicméně spousta lidí asi vyžije i bez nich. :-)
-
nojo ale redo log je naprosto mission critical feature, nebot umoznuje kontinualni zalohovani, standby mode, data auditing, flashback. Bez nej by to proste v produkci neslo.
fb online zalohovat jde sice diky MVCC, ale Oracle DB/2 by bez redo logu vubec nesly online zalohovat, pokud by nebyly na jednom zarizeni a zarizeni by umelo snapshoty.
Jeste je zajimave upozornit na to, ze DB/2 narozdil od Oracle pouziva redo logy i pro rollback.
Zajimave ze obe dve top db pozivaji misto multigeneracni architektury row, page level locky. Kterych tedy drzi pozehnane, koukam na muj Oracle a ma tak cca 160k aktivnich zamku a kdyz si spustim oracle jen sam pro sebe, tak 1 user connected 530 locks held :)
Sice nemusi delat garbage collection, ale zase jim dost nesvedci dlouhe transakce - znama Oracle chyba snapshot too old. po zkusenosti s pgsql bych rekl ze multigeneracni architektura je lepsi, ta garbage collection nema moc velkou rezii a obe dve DB scanuji periodicky DB aby si aktualizovaly statistiky, tak by mohli GC delat pri tom. Krom toho jde GC delat i prubezne pri nacitani stranky.
ČLÁNKY DO MAILU