Vlákno názorů k článku Několik poznámek ke sloupcovým databázím od aubi - Pehledl jsem neco, nebo se tady srovnava databaze...
-
aubi (neregistrovaný)
Pehledl jsem neco, nebo se tady srovnava databaze indexujici sloupce s databazi bez indexu?
A prekvapive jsou vysledky ve prospech indexu, ale zase pomalu updatuji.
Autore, kdyz jste odbornik na PG, proc nesrovnavate srovnatelne? Zapomnel jste rict, co od te databaze chcete. Analyzy? Pak v testu PG chybi indexy. OLTP? Pak tam nejsou rychlosti transakci u sloupcove db.
Petr
-
Srovnavam analyticke operace - OLAP. V PG nemam indexy, protoze jejich pouziti u starjoinoveho schematu je diskutabilni - u agregaci vetsiho casti tabulky se nepouziji a v kazdem pripade zpomaluji DML operace, a pokud mate vetsi mnozstvi sloupcu (a tudiz i vetsi mnozstvi indexu), tak pak rychlost hromadnych DML operaci muze byt problematicka. Samozrejme, ze PG je na tom hure - protoze neni optimalizovana pro toto pouziti. Na druhou stranu mnoho organizaci PG pro OLAP pouziva a resi problemy s vykonem.
-
Karel (neregistrovaný)
Indexy sice zpomalují DML, ale i tak je PG v insert/update/delete rychlejší než MonetDB. Otázka tedy je, nakolik by bylo PG pomalejší ve chvíli, kdy přidám tolik indexů, aby i DML bylo stejně pomalé jako MonetDB. Možná to pak nebude pomalejší o dva řády, ale jen o jeden. Osobně bych ale spíše čekal, že i po přidání 10+ indexů to DML bude pořád rychlejší než MonetDB.
Každopádně za článek díky, je dobré vědět, že sloupcové databáze umí být o tolik rychlejší než "klasická DB". Optimalizace dotazů a databázových operací je podstatná část mé práce (Oracle). Běžně dosahuji drobnými změnami SQL a tabulek desetinásobného zrychlení (oni naši programátoři na optimalizace moc nehledí a ani nemají reálnou představu o tom, jak se s daty nakonec pracuje, takže ne že bych já byl tak skvělý, spíš oni se s tím tak málo zalamují (což jim nevyčítám, protože je fakt, že se nakonec optimalizuje tak sotva 3% kódu, co napíšou, zbytek za to nestojí)). Vědět, že bych dost možná u "dat ke čtení" mohl zrychlit ještě desetkrát, je dobré. Navíc i bez toho, aby ta databáze byla rázem 3x větší. Teď jen musím nastudovat, jak MongoDB a Oracle efektivně propojit.
-
aubi (neregistrovaný)
Takze OLAP/dotazy. Na DML se vykasleme, ty jste nesrovnaval.
Pak srovnavate indexy ve sloupcove databazi s prostym ulozenim v PG a mystifikujete ctenare, ze to je klasicka databaze. Neni. Klasicka databaze pouziva indexy tam, kde to zrychluje operace.
Az budete chtit porovnat transakce, napiste clanek o nich. Nebo napiste clanek o vsem. Ale ne o jedne funkci jedne databaze a jine funkci druhe.
Bohuzel tenhle clanek presne kopiruje trend "Noqsl databaze jsou lepsi, protoze neumim SQL".
No, aspon jsem se dozvedel o kompresi za behu. To bylo zajimavy.
-
Několikařádkové DML operace byly rychlostně srovnatelné s PostgreSQL - v typicky OLAP režimu (v závěru článku to zmiňuji). Testoval jsem masivní insert, který byl cca o 20% pomalejší než u PostgreSQL - nicméně na PostgreSQL nebyl jediný index. Každý index by tento insert o hodně zpomalil.
Tento článek je o použití OLAP databáze na OLAP zátěž. Jelikož většina čtenářů nemá zkušenosti s žádnou OLAP databází (a dost často PostgreSQL používají i pro OLAP), tak používám srovnání s PostgreSQL - kde si navíc troufám odhadnout, že dokáži přesně odhadnout úzká hrdla - na rozdíl od MonetDB, který běžel opravdu s defaultní konfigurací, a kde sofistikovanější optimalizaci neumím.
Mým cílem je nasměrovat některé čtenáře ke specializovaným OLAP databázím, protože používají db pro OLAP úlohy a třeba nevědí, že existují speciální databáze, které tyto úlohy mohou výrazně urychlit. Jsou to ale specializované databáze, které se hodí na speciální úlohy - rozhodně neříkám, že klasické row engine databáze tady už zítra nebudou. Budou, ale v OLAPu buďto budou používat kombinované enginy typu dva v jednom - což je strategie MS SQL, HANY nebo budou výrazně pomalejší. A pro někoho 2h noční doraz je v pohodě, pro jiného je 3 min dotaz kdykoliv dost pomalý. U některých aplikací si mohu dovolit ruční optimalizaci, preagregace, ruční optimalizaci indexů, jinde si to dovolit nemohu (nebo je to obtížnější) v důsledku desítek tisíc různých databází, různých typů dotazů.
-
karel (neregistrovaný)
Souhlasim, je dobre ze existuje tento typ databazi, a ze to spousta lidi neoceni no co se da delat, nekdy clovek potrebuje datovy sklad nekdy relace a jindy proste jen sloupcovou databazi.
Dobry programator neni ten co se nauci v mysql a php patlat eshop jeden za druhym, ale ten co na konkretni problem pouzije specificke nastroje tak aby jej vyresil co nejlepe. To je jako z jazyky nekdy je v pohode pouzit bash, nekdy se to komplikuje tak radeji python, php, perl protoze zas clovek nechce moc resyt typy no a nekdy je to proste pomale tak se prejde o lvl niz. No a nekdy staci jen ssd. Proste vydy to chce se zamyslet a hlavne nejet vyjetejma kolejema, clovek pak zlenivy a zestarne.
-
Filip JirsákStříbrný podporovatelPokud máte pocit, že Pavel Stěhule neumí SQL, hledejte chybu na své straně.
