"Tabulka" sloupcové databáze je tvořena pouze indexy, pro každý sloupec jeden. Z toho vyplývají výhody rychlých SELECT nad jedním sloupcem, ale také nevýhody, například velmi pomalý insert/update/delete. Dnešní slušná SQL databáze umí mnoho operací provést pouze nad indexem také.
A opět tradičně se tvůrci MonetDB vykašlali na pokročilou správu paměti, takže i kdyby to nakrásně bylo rychlé, stejně se to obtížně nasadí do produkce.
Tady to píšou: https://www.monetdb.org/Documentation/Guide/Compression
U SAPů mají B-tree rovnou v syntaxi:
CREATE [UNIQUE] [BTREE | CPBTREE] INDEX <index_name> ON <table_name> (<column_name_order>, ...) [ASC | DESC]
Možná to jsou nějaké modifikace b-tree, ale jistě to s tím dost souvisí.
To je právě o tom, jak široce chápu pojem index - mohu mít hierarchicky organizovaná data v blobech a celkem nativní organizace bude forma btree - a osobně mám problém to nazvat index (i když to výrazně bude zrychlovat data). Na druhou stranu u MS SQL sloupcové indexy je duální memory sloupcová databáze, která se označuje jako index. To, co se v MonetDB a Vertice určitě nenazývá indexem, tak u MS SQL se jako index označuje - takže záleží s kterou terminologií se člověk setkal.
No v podstatě data uložená ani nepotřebujete, stačí vám jen indexy, a indexy indexů, a entita bude reprezentovaná jednoznačným číslem. Budete mít index Jméno například {Jan: 2121111211, Josef: 211118181} a nebo další index Příjmení {Novák: 2121111211, Novák: 211118181}. Když pak indexy setřídíte podle entit, získáte všechny informace k dané entitě. Zápis nemusí být složitý, jde vlastně o indexaci virtuální tabulky (id, Jméno, Příjmení} podle každého sloupce, přičemž změna indexu při zápisu znamená jen zápis dvojice [id, název sloupce]. Při zápisu nových informací musíte nejdříve identifikovat správnou entitu a nebo vytvořit novou, pokud neexistuje. :-)))
Index je v databázích cokoliv, co umožňuje přístup k datům rychleji než prostým procházením celé množiny dat.
V indexu mohou být i vlastní data, například mnoho let v MS SQL clustered index jsou data rovnou součástí indexu.
Že v tom tvůrci MonetDB mají hokej mě nepřekvapuje, ještě se mají hodně co učit.
Ano jistě, ale přece je to jen změna paradigmatu, přechod od syntetického jazyka popisu dat pocházející ještě od dob děrných štítků, kdy nějaký vztah komplexně popisovalo jedno slovo, v tomto případě štítek, záznam(record) (db stroj s ním zachází jako se slovem) k analytickému jazyku popisu dat, kdy stanoveným postupem získáte informaci ze slov, tedy nalezením atributů ve vhodném pořadí (db stroj sestavuje větu). Oba přístupy mají své výhody. Sloupcové databáze, pokud dojdou k dynamické tvorbě vztahů, budou v sobě obsahovat i vztahy, které do nich explicitně nebyly dány, ale dojde se k ním analýzou vzniklé struktury dat. A to bude ta technologická změna, tedy až si tyto možnosti uvědomí i tvůrci MonetDB :-))) Nakonec dojdeme ke struktuře topologicky podobné lidskému mozku. :-)
Tak inuitštinou a nebo angličtinou vyjádříte to samé, přesto konstrukce těch jazyků je odlišná, inuitština je řádková kdy základní jednotkou je slovo, například v "inuitštině" "kus-voda-kámen-studený-vzít-byl-jím" (jedno slovo) a v "angličtině", ta je zase sloupcová, by to znělo "on dělal vzít kus ledu". No a v každém jazyce bude vaše myšlení naprogramováno (určeno) trochu jinak, i když budete přemýšlet o stejných věcech. Angličtina shodou okolností byla dobrá pro vytvoření programovacích jazyků díky svým analytickým rysům, kdybyste jako základ pro programovací jazyk vzal češtinu, byly by s tím větší problémy, protože by vám vadilo třeba skloňování. A podobně ovlivní přemýšlení o zachycení reality databází její uspořádání do řádků a nebo sloupců. Proto jiné paradigma. Navíc pro obé je vhodná jiná architektura hardware.
Tak dobře, vyjádření nové a ještě paradigma je příliš silné, řekněme tedy, že jde o poněkud odlišný interní mentální model, trochu méně navázaný na pojem relace. Při práci s nimi pozornost tolik nesoustřeďujete na vlastní relaci, ta je dána, ale na samotný obsah daného sloupce v rámci zkoumané relace.
Myslim, ze jsi nepochopil smysl tech sloupcovych databazi. Pouzivaji se prave pro ten OLAP, tedy analyzu treba historickych udalosti (napr. probehlych transakci). Typicky jde o siroke denormalizovane tabulky, ktere se casto ctou (a ne nutne vsechny sloupce), napriklad pro reportovani nebo sumarizaci. Naopak updatovani tech tabulek se vetsinou dela malo nebo vubec, a pokud, tak se to dela najednou pro velke mnozstvi radek (pripadne se vkladaji sekvencne).
Takze insert/update/delete muze byt klidne pomaly, protoze se nepouziva. Naopak vyhoda v ulozeni po sloupcich je v tom, ze se usetri za I/O operace, pokud chceme zpracovavat jen vybrane sloupce (nemusime cist cely radek). Coz u masivnich tabulek (treba s miliardami radek) hraje roli.
Trosku jsem ted na pochybach, zda jsi vubec ten clanek cetl, protoze tohle vsechno tam autor rika.
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.
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.
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ů.
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.
Dobrý den,
děkuji za hezký a pro mě aktuální článek. Pár měsíců zpátky jsem se na MonetDB díval, ale ve všech dostupných testech pracovali maximálně s databázemi do řádu stamiliónů záznamů. Nemá tu někdo zkušenosti, případně našel odkaz, kde se pracuje s datasety od dva až tři řády vyššími? A jaká jsou v té chvíli hlavní omezení (i/o, pamět)?
jen je třeba změnit paradigma, co znamená zápis do sloupce? Znamená jeho setřídění, takže když se algoritmus třídění rozšíří i o nesetříděnou část, kam může kdokoliv cokoliv zapisovat a jeden uživatel třídí kopii tabulky, může do třídění přibírat i hodnoty z té společné nesetříděné části. Nakonec zápis může znamenat zápis do nesetříděného poolu a databázový stroj může zajišťovat kontinuální třídění a zatřiďování informací z nesetříděné části. A setřídit sloupec bude nutné teprve tehdy až poklesne efektivita vyhledávání pod určitou mez, nejprve se bude snažit vyhledat klíč v setříděné části, nenajde-li jej, projde sekvenčně nesetříděnou část, celé se setřídí, až procházení sekvenční části bude příliš zdržovat.
Když se to tak vezme, tak trochu podobné to má vertika - zapisuje se primárně do paměti - WOS (write optimized storage) a po určitém čase dochází k zápisu na disk do ROS (read optimized storage).
Trochu z jiného soudku je experimentální database cracking, kdy indexy se vytvářejí dynamicky při čtení tabulky a optimalizují se podle přečtených dat. S tím jak roste výkon CPU a hlavně paměť, tak se zvětšuje prostor pro podobné experimenty.
Paradigma je dané současným hardware, změnit nejde, paměti jsou 500x pomalejší než je potřeba a takhle se dá hrát jenom s tím co se vejde do L1 cache a to tedy není mnoho.
Problém s paralelním zápisem do sloupce více uživateli současně řeší Intel TSX, ale výše uvedené problémy nikoliv.
http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions
No tak není problém L1 cache zvětšovat, třeba na úkor složitosti procesoru, nakonec klidně si můžete vytvořit speciální experimentální db procesor na bázi FPGA obvodů. A budou-li tyto db úspěšné, změní se i architektury běžných procesorů. K práci s databází můžete využít i výpočetní výkon grafické karty, výpočty ve vektorové grafice mají obdobný charakter.
No a tím jsem začal, pokud se sloupcové db ujmou, bude i specializovaný hardware. A cena tolik nerozhoduje, když vám technologie přinese podstatnou konkurenční výhodu a máte na počáteční investice. Výhodu by to mělo, že by to mohly montovat stejné linky co montují SSD disky.