Vlákno názorů k článku Několik poznámek ke sloupcovým databázím od Kolemjdoucí - "Tabulka" sloupcové databáze je tvořena pouze indexy, pro...
-
Kolemjdoucí (neregistrovaný)
"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. -
Kolemjdoucí (neregistrovaný)
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.
-
Ivan Nový (neregistrovaný)
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. :-)))
-
Kolemjdoucí (neregistrovaný)
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. -
Ivan Nový (neregistrovaný)
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. :-)
-
Ivan Nový (neregistrovaný)
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.
-
Pavel TišnovskýZlatý podporovateljj s těmi jazyky je to pravda, sémantika značně ovlivní myšlení. Třeba v jazycích, které moc nedokážou vyjádřit budoucnost, mají jiný způsob určování směrů atd. atd.
-
Ivan Nový (neregistrovaný)
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.
-
JS (neregistrovaný)
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.
