Názory k článku Využití databázových indexů

Ukladam log ze squidu do PostgreSQL a za mesic ma tabulka 200 000 zaznamu (firma s 10 aktivnimi pocitaci)... Jeste nemam napsanou aplikaci na vyhodnoceni dat (kolik uzivatel stravil denne na internetu a na cem nejvic casu apod.), ale jsem zvedavy, jak to bude rychle - nemate nekdo podobne zkusenosti, jak resit takovehle udesne tabulky? (za rok to bude 1.5 milionu zaznamu - to nemuze preci SQL zvladnout v tom rozumne(!) vyhledavat - nebo se mylim?)

Mysql s prstem v nose.

Jen to chce udelat indexy az pri zpracvani, treba rvat data do pomocne tabulky bez indexu a pak je jednou denne preklopit do te odkud se doluji data a ktera mit indexy bude.

No, ja zatim delam hromadny import kazdou hodinu a zvlada to v pohode...

1.5 milionu zaznamu je jeste pomerne mala tabulka :-)

My mame v tabulce nekolik miliard zaznamu a vyhledani je do par vterin. Pravda, je to v Oraclu :-)

No ten komentar nebyl treba, pri jedne tabulce bych na oracle nevsadil ani petnik ze to dokazes projit rychleji nez mysql. Jo, u slozitejsich spojeni by oracle jednoznacne vyhral ale s takovymi jednoduchymi malickostmi jako je tohle je mysql bezkonkurencni.

To je jen zazite ze si clovek rika ze milion je velke cislo - pritom to neni prakticky nic.

No nevim ale srovnavat MySQL s Oraclem je jako porovnavat Trabanta s Mercedesem ....

no zalezi od konkretneho pouzita.

ale viem ti dat priklad tabulky, ktora bude v mysql nepouzitelne pomala (vzdy to bude full table scan aj keby si spravil akykolvek index) a v oracle bude bleskova - pri pouziti rovnakeho SELECTu

staci vhodne zvolit IOT a mysql, postgres, mssql a hocico co nema IOT sa moze strcit ;) - z praxe som videl to zrychlenie ked oracle 8.0.5 IOT nemal a potom v 9.2.0 kde je IOU full supported

Polozil bych si otazku, jestli opravdu vsechny ty zaznamy potrebuju nebo jestli je alespon potrebuju v jedne databazi/tabulce. Pozadovane sumacni udaje bych jednou za mesic z dat vytahnul, ulozil do separatni databaze a podrobna data odsunul pryc.

Sumacni udaje lze vytvaret i prubezne pomoci aplikacni logiky v databazi (ulozene procedury, triggery,...).

>Pozadovane sumacni udaje bych jednou za mesic z
>dat vytahnul, ulozil do separatni databaze a
>podrobna data odsunul pryc.

Staci do separatni tabulky...

Aplikaci na zpracovani logu SQUIDU jsme vyvijeli. Pravda dela spoustu jinych veci nez jen off-line
prehledy (ex-post), ale ze zkusenosti lze jen doporucit pouziti neceho jineho nez PostgreSQL. Vzhledem k tomu, ze se uz z principu nejedna o transakcni zpracovani, tak zkuste treba MYSQL (bez transakci) je radove rychlejsi pro ucel, na ktery to potrebujete.
Jinak pro SQL jako jazyk to neni zadny problem.
Jen na okraj - jsem velkym priznivcem PostgreSQL a
MYSQL s nim nelze srovnavat, ale pro tento ucel se
MYSQL hodi opravdu lepe.

Nezalezi ani tak na "objemu dat" ale na optimalizaci ulozeni dat a na spravnem chovani k SQL engine. Muzu vas ubezpecit ze 1.5mil zaznamu je prd do stromovky. Zalezi tez na zeleze na kterem to honite (SMP system,RAM, Disky ?). Chce to vyuzit vlastnosti DB jako cluster index, bitmap indexy apod. Ne kazda SQL DB toto umi. Clovek dosahne nejlepsiho vykonu pokud nejde proti srsti SQL enginu. Nejlepe je si neco nacist o fungovani toho ci onoho engine a pak k nemu podle toho pristupovat. Napr. Oracle versus hinty a dobre napsany SQL statement muze udelat vysledek kde rozdil je v stovkach sekund. I na tabulkach kde je ulozeno cca 60 milionu zaznamu lze pres index dosahhnout radove nekolika ms pro pristup pres index. Jinak diky autorovi clanek je lehce napsan a pro lidi kteri nevedi o cem je rec je dosti ctivy.

A preco radsej nepouzijes MySQL? Pre tvoju potrebu by to bolo lepsie a jednoznacne a podstatne rychlejsie riesenie.

Jak to vypada tak uz nic dalsiho na toto tema nebude nasledovat :-) Takze doplnim jeste jednu vec, kterou povazuji za podstatnou:

MySQL umoznuje u textovych poli udelat index pouze na cast retecze - priklad z manualu:

CREATE INDEX part_of_name ON customer (name(10));

Vytvori index na prvnich deset znaku jmena zakaznika. To by se mohlo hodit pri zpracovavani logu squida vyse. Index pak nebude tak velky a nebudete v problemech, ze mate datovy soubor par set mega a indexovy nekolik giga :-)

Ale jinak ladeni vykonu MySQL je take docela veda, protoze je tam docela dost parametru, ktere ho mohou v ruzne mire ovlivnovat. Pokud by byl zajem, muzu o tom casem neco napsat. Nebo nekdo jiny...

Jo, jo, jen do toho! :-) Sice jsem o tom uz neco nasel na netu, ale prilis moudry jsem z toho nebyl.. Urcite by se to hodilo i dalsim :-). Taky by me zajimalo, jestli se da vykon MySQL nejak monitorovat, treba zjistit, kolik si ktera databaze bere strojoveho casu, atd..

RTFM? MySQL ma pomerne dobry system stress-testu kde si muzete ozkouset jak se to bude chovat, staci chtit :)

omlouvam se za dotaz "mimo misu" ale potreboval bych poradit.... Potrebuji nejaky free databzovy system, ktery obsahuje SQL-92 paletu prikazu. Zatim jsem zkousel mysql ale to je strasny smejd, ktery neumi napr. create view a celou radu jinych standardu. idealni by bylo, kdyby to bylo free, slo to nainstalit pod windows NT a melo to i nejake GUI.....

Ad 1) MySQL neni smejd, je to lehky SQL engine, ktery je pravdepodobne urcen k jinym ucelum nez potrebujete ale rozhodne kvuli tomu neni smejd. Ma chyby, ma slabiny, ale ktery SW je nema.

Ad 2) Prima databazi pod NT s GUI dela M$ a urcite je to clickaci a barevny, tak jak potrebujete... Akorat to neni zadara a to je dobre, jen at si Widlaci priplatej...:)

ad mysql souhlasim

ad bod 2), je to zase jednostrane zamerena reakce, ale co cekat. proc lidi musi byt natolik ubozi, aby nedokazali priznat kazdemu co jeho jest, nebo alespon nekecat o vecech o kterych nic nevi.

pod nt je k dispozici odlehcena verze sql serveru, zvana msde, ke stazeni ruzne po netu. zbezne vim ze se treba nesmi pouzit k vyrobe neceho co by bylo konkureceschopne accesu (protoze novej access bude bezet nad msde), ale myslim ze je jinak volne k pouziti (precist licenci).

bohuzel k tomu nejsou pridany gui ovladaci nastroje, jinak dostupny k ms sql serveru (mimochodem podle me celkem dost dobry), nicmene pokud nekde mate sql server, tak ty nastroje funguji i na msde. taky se na netu vali free aplikace pro spravu MS SQL/MSDE databazi psany v asp.net.

jinak samosrejme postgres bezi pod nt taky, svyho casu SAP (eeeeee) uvolnil nejaky svuj DB stroj volne k dispozici (verze 7.neco).

ale jinak je to v pohode, hlawne ze widlaci i lidi co pouzivaji oba systemy platit nemusi !!!

PS: jeste jsem nevidel pouzitelny free/oss gui k mysql/postgres. nelze se tedy divit, ze nekteri jedinci radsi gui zatrati, protoze se jim nevyplati s nim delat, a kdyz neni kvaliti free/OSS gui, pak ty komercni prece musi byt shity taky, proc na ne teda nehazet spinu, ze panove ? pokud nekdo o dobrem gui manageru treba pro mysql/postgres slysel, rad si to prohlednu.

phpmyadmin?

A pro Postgre SQL je phpPgAdmin jenz roste na http://phppgadmin.sourceforge.net/

http://pgadmin.postgresql.org

Free GUI k MySQL je několik. Nejdříve jsem používal MysqlWinAdmin, dnes používám SQLyog a ten je opravdu perfektní. A jeho funkce jsou tak vyspělé, že je o dost víc, než jen manažer. A někdy taky pro jednoduché sázení a editace výsledků SQL dotazů používám IMySQL. Samozřejmě existují i weboví správci, jako phpMyAdmin, ale já ho nepoužívám, nemusím-li. Binárka je pro mě vždy lepší.

Nutno říci, že výrobce MySQL propaguje na svém webu takové hnusné shity, co vydává za perfektní grafické rozhraní pro MySQL, že se ani nedivím povzdechu toho člověka nade mnou. Někdy mám pocit, že u některých grafických programů standardně propagovaných přímo výrobcem MySQL ten člověk se právě učí programovat. Ale nic, alespoň jsem si ulevil.

<sarkasmus>On existuje nejaky DB system, ktery PLNE implementuje SQL 92? :-)))</sarkasmus>

Pokud potrebujete tyto vychytavky, zkuste Postgres. MySQL je spis vhodne jako "sklad dat s prvky SQL databaze" nez jako platforma ktera by mohla konkurovat moznostem napr Oracle. Neimplementuje spoustu veci (treba subselecty jsou teprve az v alfa verzi 4.1 :-( ), ale zato je hodne rychla.

A aby se nereklo, ze jen flamuju....

Ad 3) To co shanite umi do jiste miry Postgres SQL, ale nejsem si jist, zda uz dotahli SQL-92 uplne, kazdopadne to meli v planu.

Leda zkusit MSDE (je to MS SQL) akorát že to má dost omezení (5 connections, a kdovícoještě), ale je to zadara. Výkonově je to myslím stejně silný jak MSSQL. Nejde to teda použít pro web, ale pro vývoj nebo nějaký program běžící lokálně jo.

Pro web to použít jde, např. na W2K3 Server Web Edition nic jinéno než MSDE nenarvete. :-(
Co se týče omezení - není to 5 connection, nýbrž 5 paralelně zpracovávaných úloh (ostatní čekají ve frontě), max. velikost jedné databáze je tuším že 2GB, není tam možnost fulltext indexů a nemá to GUI (čili ovládání jedině přes SQL dotazy, nebo přes nástroj třetí strany, popř. použít administrační konzoli z plného SQL serveru - samozřejmě o tom nesmí vědět ochránci autorských práv ;-)... Ale třeba právě pro malý webový (pokud nepotřebujete ten fulltext) je MSDE pod Win32 platformou výborná. Plný výčet vlastností by měl být někde na webu MS, stáhnout se nechá např. z http://www.asp.net/webmatrix/download.aspx?tabindex=4

asi te bude zajimat www.sapdb.org. Ma i tu nativ podporu windows (tested s win2k), coz u postgresql neni ten pripad - myslim ze na tom sice pracuji, ale soucasna verze pod win bezi pres cygwin

A jakou to ma podporu Delphi? Pres ODBC nebo jsou nativni komponenty (preferuji) a co PHP? I kdyz kdybych par lidem navrhl SAP tak me umuci... Ted ho zrovna resime a kluci od SAPu nejsou schopni niceho!!!

Pokud bys nechtel ty Widle tak Sybase dala k dispozici svou OLTP databazi Adaptive Server Enterprise 11.0.3 pro Linux zcela zadarmo. Vyssi verze (aktualni 12.5), stejne jako verze pro Widle ci jine unixy jsou placene. Vice http://linux.sybase.com/ase/11033download.html .

www.sapdb.org

Muzete zkusit Sybase 11 pro Linux (http://linux.sybase.com) - je to sice starsi verze, ale umi toho docela dost.

Dovolim si len poznamenat, ze VIEWs nie su sucastou standardu ANSI SQL/92 ale ANSI SQL/95.

Nikoli.
Alespon podle: Mastering SQL - Martin Gruber,
jsou pohledy (views) soucasti SQL92.

ze jo, ja si to taky myslim. SQL jsem se ucil z Understanding the new SQL : a complete guide (Jim Melton, Alan R. Simon ), kde v uvodu bylo uvedeno ze popisuje SQL-92 ... a views tam jsou

Dovolil bych si jen poznamenat, ze zadny ANSI SQL/95 neexistuje, zrejme mate na mysli neco ala SQL3, ANSI SQL/97 (take neexistujici, protoze se to nestihlo) apod., jedine co se stihlo jsou ruzne mezi-veci (treba v roce 1996)...

Jinak koukam, ze lidi maji docela hokej v tom, co ktere ANSI SQL obsahuje, ze treba existuje Entry level apod... vzhledem k tomu, ze to bylo soucasti me diplomky a v podstate na toto tema jsem mel pripraveny clanek pro Roota (asi tak pred 2 lety) - nakonec jsem to nedokoncil - mozna by stalo za to to dopsat, pripadne prijit s kuzi na trh a ostatni by mohli mit pripominky, takze bychom se nakonec dobrali pravdy.

Roote mas zajem?

PS: Vyvoj by vsak byl tak do roku 1998/9, novejsi veci jsem prestal sledovat, prakticky je nikdo stejne nema implementovane nebo ma, ale firemne (shodou okolnosti to protlacil dal:-))

nezabudnite na Firebird, je to najlepsi a naozaj free SQL server s dobrou implementacoiu SQL-92 (stored procedures, views, triggers, user defined prcedures, ...). Odporucam:) http://firebird.sourceforge.net

Taky se musim přidat ke chvále Firebirdu (i když nějaké chybky taky má, ale kdo je nemá, žejo)...

Pro počáteční seznámení bych spíš doporučil URL http://www.ibphoenix.cz/ resp. http://www.ibphoenix.com/ nebo http://www.firebirdsql.org/

Taky bych se přimlouval začít spíše s FireBirdem, nebo s Interbase. Je to vynikající databáze s multigenerační architekturou s podporou všeho možného a tvářící se dost přívětivě.

sorry, ale co znamena "multigeneracni architektura"?

Chtel bych doplnit informaci ohledne malohodnotovych atributu a jejich indexace. Pokud podle malohodnotoveho atributu budete vyhledavat, neprinese indexace tohoto atributu zadne zrychleni. Pro takove atributy umi nektere databaze (Oracle) vytvaret "binarni" indexy.
Dalsi poznamka se tyka pouzivani prikazu select a rychlosti odezvy. I presto, ze budete mit zvolene dobre indexy, vyhnete se pouzivani vnorenych selektu. Zpomaleni neni citelne na ucebnicovem prikladu, ale na databazi s mnoha set zaznamy obzvalste pri spojeni vice tabulek. Podobna poznamka plati pro rozsahle where podminky s operatorem "or" nad vice tabulkami.
Dalsi poznamka se tyka tabulek, kde je index nad vetsinou atributu. Napriklad tabulka obsahuje ctyri atibuty: tri ideca (cizi klice) a jednu hodnotovy atribut. Pokud se k tabulce pritupuje zaroven s omezenim na vsechny tri cizi klice, je zbytecne po nalezeni zaznamu v indexu jit pro hodnotu do tabulky. K urychleni pritupu k takovym tabulkam exituji specelni struktury (v Oracle se jmenuji "index table") uchovavajici hodnotu primo v klici.

Posledni poznamka je navrhem na problem s databazi squid logu. Prochazeni milionu zaznamu bude pochopitelne pomalejsi nez select nad desitkami zaznamu. Proto se nabizi pouziti datoveho skladu a z primaprni tabulky podle zamyslenych statistik vysumovat data do nove vytvorene tabulky (tabulek). Tato operace se da presunout na nocni hodiny a bezne denni prochazeni a statistiky jsou pak mnohonasobne rychlejsi.

Nejedna se o binarni, ale o bitmapove indexy.
Ad "index table": Normalni tabulky se ukladaji jako heap, tj. nejsou setridene a pro urychleni vyhledavani je nutne vytvorit indexy nebo partitions. Pokud se vsak k datum v tabulce bude primarne pristupovat pres primarni klic a tabulka se prilis casto neaktualizuje, je vhodne ji rovnou reprezentovat ve forme indexu, tj. setridene podle primarniho klice. Tato representace ma vsak i dost nevyhod a osobne jsem nezjistil ze by byla nejak fantasticky rychlejsi nezli kombinace table+index. Samozrejme prinasi vyraznou usporu mista zejmena pro cross referenci mezi dvema tabulkami (mapovani n x m ).
Ad datawarehouse: S uspechem lze pouzit partitioning bez nutnosti mit specializovanou databazi.

Este by som doplnil moznost odporucit databazovemu serveru akym sposobom ma narabat s udajmi. Syntax je: /*+ hint */
Pricom takychto hintov su (aspon v db Oracle) desiatky.
Napr. pre odporucenie indexu pri selecte je syntax:
SELECT /*+ INDEX ( table [index [index]...] ) */
...

1) a ako teda napisat select nad viacerymi tabulkami bez pouzitia "rozsiahlych" where podmienok a/alebo vnorenych selektov?

2) btw vsetky index(y/i?:) v oracle uchovavaju hodnotu atributu ("priamo v kluci"). index organised tables 'len' zabranuju zbytocnej duplikacii dat a s tym spojenej rezii.

3) tie indexy su bitmapove nie "binarne"

To nepouzivate? Proc? Driv jsem si s ni dost hral a stacila mi. Beha bez problemu jak na Windows, tak na unixech a na rozdil od ukladatka MySQL je to relacni databaze :-)
Uz jsem s ni dlouho nedelal, nevite, jak to s ni vytpada?

firebird jsem zkousel ale neumi to napr. CASE ... takze taky nic moc .....

Verze 1.5 už umí (mimo jiné) CASE, NULLIF i COALLESCE.

Pri Vasem prispevku mne jeste napadla WinBase602 od Software 602 - nema ta take nejakou variantu s nulovou cenou?

autor pise :
Databázové indexy slouží ke zrychlení přístupu k datům a měly by se používat u všech sloupců, podle kterých se vyhledává, třídí nebo podle kterých se spojují tabulky.

mysli se tim i ze by mel byt index na sloupci na nemz typicky dotaz ma selektivitu rekneme 80 % ??? To asi ne, ze pane autore... Vememe li v uvahu ze pristup na rekord pres index je 4x pomalejsi nez pristup primo (napr pri fullscanu) a dal ze indexy zpomaluji update a insert operace, zvysuji naroky na misto apod.. meli bychom rici ze indexy nemuzeme mastit bezhlave jak nas napadne ale na sloupce kde se to vyplati z hlediska dotazu ktere budeme provadet. Flaknu to vod voka rekneme kde selektivita bude do dvaceti procent

ad free SQL urcite doporucim PostgreSQL, nejenom z duvodu ze jednim z vyvojaru je Pavel Zak (napr prepared statements nemylim-li se) ale hlavne proto ze v nem najdete temer vsechno co potrebujete, zvlada poradny objemy dat a ma i nejakej svinsky hezkej gui tool jen si nemuzu vzpomenout jak se jmenuje (nepouzivam ho) napsanej nad WXWindows toolkitem takze jede na stomilionech platforem, myslim pgadmin nebo tak nejak, v mailing listech postgresu je vo nem zminka.

SQL wraperem nad souborovou databazi (cti MySQL) bych se vubec nezabejval. Hracky patri detem.

Ono je škoda, že autor vysvětluje napůl MySQL, místo aby šel jen po indexech. Mimochodem, nesouhlasím s názory na nezabývání se MySQL, protože má svůj účel a je velmi mnoho situací, kde slouží velmi dobře. MySQL nemusí být souborová databáze, taková je pouze, kdy tvoříte tabulky typu "MyISAM", jinak pracuje se segmenty na disku jako jiné transakční databáze. Ale jinak jsem si všiml, že zastánci Postgresu jsou vyjímečně vysazení na MySQL.

Nicméně v indexech se používá pravidlo 20%, tj. pokud index slouží k vyhledání méně, než 20% řádků tabulky, je rozhodně efektivní. U rozsáhlých tabulek je to zase trochu jinak. Osobně se ale domnívám, že prostě potřeba uvážit poměr frekvence použití indexu / zápis. A i to není dokonalé, chce to trochu citu. Zkrátka indexy zpomalují zápis a za určitých situací mohou urychlit čtení, či vyhledání subsetu dat pro úpravy.

Pokud je index používán třeba jen jednou za měsíc, u velkých databází může být výhodné ho těsně před použitím vytvořit a zase po použití dropnout. Atd..

To, že by se indexy měly používat uváženě, je dobrá připomínka a v článku by to mělo být zmíněno. Např. MySQL ale indexy nepoužívá v případě, kdy je potřeba sáhnout na víc než 30% řádek, takže ke zpomalení SELECTu nedojde (ke zpomalení INSERTu však samozřejmě ano). Věřím, že i "chytřejší" databáze budou podobné strategie používat.

Použití indexů i nad sloupci s malým rozptylem má však význam, pokud omezujeme velikost výstupu pomocí LIMIT.

Pouzivaji. Optimalizator databaze obecne by mel vzit do uvahy SQL dotaz, databazove schema (kde jsou jake indexy), aktualni obsah pameti (data v cache) a samozrejme take statistiky o datech (pocet radku, selekcni sila...).
A pote rozhodnout jak postupne zpracovat dotaz, ktere indexy pouzit, jak cist data (treba udelat ten table scan), jak je zamykat...

... a když to z nějakého důvodu nefunguje, pořád je tu ještě klauzule 'plan'.

Optimalizator dotazu je obecne straslive slozita vec. Abyste mohl dopredu rici, ze dotaz pujde po vice nez 30% radku, museli byste mit detailni histogramy. Pro velke tabulky (miliony a vice radku) je to problem, protoze distinct hodnot byva zpravidla desetitisice a vice. Navic histogramy je nutne udrzovat, coz pri vice nez jedne paralelni session pracujici s tabulkou by vyzadovalo neustale soupereni o systemove resources nebo tak jak to dela Oracle, je nutne histogramy a statistiky cas od casu refreshnout.
Dotazy, ktere jsem potreboval optimalizovat jsem vzdycky musel opatrit hinty, nebot databaze neni schopna dotaz vzdy korektne optimalizovat. Delam na Oraclu, ale jinde to bude zrejme to same, nebot princip je ten samy, pouze mnozstvi investovane prace a penez je jine.

nu, někdy je taky možné mít všechno co budu potřebovat přímo v indexu (všechny sloupečky co jsou potřeba pro daný dotaz), takže budu číst třeba 80% dat ale pořád jsem 20% ušetřil. ;)

ja osobne by som volil do selektivity max.10%

Dobry den, mam trochu offtopic dotaz, ale neni kam se jinam obratit... Nevite prosim o robusnim fulltextu, ktery by zvladal rychle praci s asi 0.5 mil textovych souboru, booleovske op., near, vyhledavani v ruznych polich atd.. popr. vektorove prohledavani (vazeni termu)? Musi mit perfektne zvladnute vyhledavani v ceskem textu, lematizaci (truncation), popr. gramaticky slovnik na doplnovani ostatnich tvaru slov.

Nemam 100% predstavu, kolik takovz soft stoji, ale proto se ptam. Preferuji hlavne levne nabidky, ale za jakykoliv tip na komercni nabidku budu vdecny. (Pokud snad nekde existuje nejaky srovnavaci clanek, tak rovnez...) Dikz moc.

Napadaji mne Autonomy nebo Verity. Prvne jemnovany pouziva obsahoveho vyhledavani pomoci AI, ktere je nezavisle na pouzitem jazyce a dava vysoce presne vysledky.
Verity pak pouziva semantickych stromu a ma podporu cestiny od firmy Tovek.
V obou pripadech jde ale o ceny v radu statisicu.

Oracle by to mel vsecko zvladnout. Ma i kompletni ceskou gramatiku, takze hledanim 'clovek' najdete i 'lide'.
V nekomercnim okruhu bude problem s cestinou. PostgreSQL ma nejaky fultext, ale ten jsem nezkoumal.

Fulltext pod PostgreSQL jsem zkoumal loni, tehdy jsem našel dvě věci, obě si dělaly do separátní tabulky seznam slov vázaný na původní záznamy. Čili spíš šidítko než fulltext. Možná už vymyslel někdo něco lepšího, ale pokud ne, tak bohužel v tomto směru není PostgreSQL to pravé ořechové, to už radši MySQL - ale to ho zase umí jen u MyISAM databází, které pro změnu nezvládají třeba transakce. To pak má občas člověk chuť řvát a mlátit hlavičkou o zeď...:-(

jojo, to my windozaci zname ;o)
ze by uz linux softy prebiraly i tyhle nedostatky z windozu ;o))

Fulltextové (plnotextové) databáze:

ConText CZ
producent: Sefira, spol. s r. o., Česká republika
Lokalizace a rozšíření funkčnosti modulu Oracle Context Cartridge (interMedia Text) o práci s českými a slovenskými texty.

Excalibur
producent: Excalibur Technologies
zastoupení v ČR: INCAD, spol. s r. o.

SuperText
producent: 5D software, spol. s r. o.

TexPro
producent: Fulcrum - Exprit, spol. s r. o.
zastoupení v ČR: Exprit, spol. s r. o.

Verity K2, TOPIC
producent: Verity, Inc.
WAIS

Tady je jeden co zvlada 20milionu stranek a min zvladne taky :)

http://jyxo.cz/doc.php?d=serv

jak to tady ctu, napada me takovy hloupoucky dotaz - mohl by prosim nekdo udelat strucne porovnani MySQL/Postgres/Firebird a janevimco jeste je ted v soucasnosti "in"?
nemyslim nic ve stylu "ktera databaze na jakem selectu usetri milisekundu", toho se po webu vali tuny, ale spis nejaka doporuceni pro zacatecnika, co si ma pro sve ucely nainstalovat a nadale se s tim trapit (nezli zkouset kazdy tyden neco noveho) ...
momentalne si na svem webiku hraju s MySQL, staci mi, ale cervicek pochybnosti vrta - zvolil jsem spravne, nemam prejit jinam driv, nez by se stal prechod prilis slozitym?

No, porovnání tu nenapíšu, ale možná by vám pomohla moje zkušenost.

Já jsem s něčím na způsob databazí začínal u Paradoxu/BDE (to jen pro úplnost), pak jsem několik let programoval s Oracle, Sybase a MSSQL (tedy "velké databáze") a teď už dva roky skoro výhradně v Postgresu. S MySQL mám zkušenost jenom uživatelskou (instaloval jsem některé programy, které MySQL používají). Firebird neznám.

Z tohoto pohledu doporučuji Postgres. Zejména, pokud se chcete databázovým programováním zabývat do větší hloubky. Na Postgresu si můžete vyzkoušet víceméně všechny prvky 'velkých' databází, velkým plus je také výborná dokumentace která uvádí nejen do vlastní databáze, ale i do databázového programování vůbec.

no pokud potrebujete triggery, ulozene procedury, vlastni agregacni funkce, schemata, referencni integritu (i kdyz mozna to uz i mysql ma) a ja nevim co si este ted vzpomenout a nechcete delat tricet updatu nebo insertu za vterinu.... doporucim jako velky fanda postgresu prekvapive postgres.

pokud tyto veci nepotrebujete (coz je pripad databazi tak odhaduji o peti mozna deseti tabulkach tabulkach) tak je mozne si vzit na to mysql.

ale jak uz me tu nekdo vodhalil priznavam ze ja sem fakt vysazenej proti mysql takze muj nazor vubec nemusi bejt objektivni.

PostgreSQL, velice slusna podpora standardu, databaze je skutecne relacni (MySQL neni) a podporuje veci jako referencni integrita, jejichz absence cini z vetsiny projektu presahujicich 3-4 tabulky peklo.

Ostatne pokud vim, tak starsi verze se stala zakladem minimalne dvou komercnich databazi( PostgreSQL -> Sybase -> MS SQL), takze spatna volba to aasi nebude.

PostgreSQL ma take nektere unikatni nebo nebovykle rysy, ktere mohou v konkretni situaci usetrit dny prace.

nepouzivam ani jednu, ale presto by me zajimalo, co je to za vyhodu/co to prinese uzivateli/vyvojari, kdyz je ta postrgesql _skutecne_ relacni?

To, že se uživatel / začínající vývojář (pokud dobře rozumím původnímu dotazu) naučí pracovat s relační databází - tj. s něco pak použije u kterékoliv jiné relační databáze.

V případě MySQL se naučí pracovat s MySQL.

Já bych, při vědomí toho že na něco se jistě MySQL výborně hodí, doporučil to prvé, protože to otevírá daleko širší obzory - a nezavírá cestu ani k MySQL, když bude potřeba...

Jakékoli porovnání je Vám k ničemu. Výběr databáze záleží tvrdě na tom, co chcete dělat, a za jakých podmínek to chcete dělat. Najdou se situace, kdy MySQL bude nejlepší, jindy zase Postgres a jindy zase Firebird a jindy ...

MySQL - jednoduchá, rychlá, škálovatelná, nenáročná, běží i na slabých strojích, optimalizovaná pro web. Na druhé straně je ořezaná o věci, které rychlostně zdržují. Má i transakce a referenční integritu, přestože řada lidí zde bude tvrdit opak.

Postgres - open source databáze, která má procedury, triggery a jiné serepetičky, co se požaduje po větších databázích.

Firebird - klon Borlandovské databáze Interbase, v zásadě dobrá a nenáročná databáze

V zasade souhlasim.
Asi vsak patrim mezi radu lidi, kteri budou tvrdit,
ze s ref.integritou je to u MySQL ponekud osemetne.
Aktualni (stabilni) verze dle http://www.mysql.com/downloads/index.html
je 4.0. Verze ve ktere ma byt implementovan
FOREIGN KEY - 5.1. Tedy vzdalenejsi budoucnost.

Na druhou stranu pokud napr. chcete provozovat free
web site, pocet poskytovatelu, ktery vam nabidnou
X MB prostoru na disku + Y mista pro MySQL je pomerne velky. Obavam se ze totez rozhodne neplati
pro PostgeSQL ci Firebird. Ale rad se necham vyvest
z omylu ;-)

Stačí Vám toto?:

"In MySQL Version 3.23.44 or later, InnoDB tables support checking of foreign key constraints."

Mimochodem, dnes je je aktuální verze 4.0.x. Tedy už dost dlouhá minulost. Naprosto nechápu, kde jste přišel na tu 5.1. Klidně si samozřejmě můžete patřit lidi, kteří "vždycky budou tvrdit" cokoli, byť se to třeba nezakládá na pravdě.

To je prostě základní problém, většina lidí prostě říká, že MySQL nemá to, či ono, že je špatná, protože, a pokud to srovnáte s realitou, jsou to z takových 95% výmysly lidí, kteří o MySQL nic nevědí. Sorry.

MySQL má své určení, a je to jak říkáte, hlavně webová databáze a nebo malá databáze pro Vaší aplikaci. Můžete si klidně nahrát sdílenou knihovnu (DLL nebo so) k aplikaci a pracovat s daty. A díky konstrukci databáze MySQL si můžete být jistí, že práce s daty bude velmi komfortní, a přitom nebudete potřebovat hafo megabajtů paměti a nejnovější procesor. I to je třeba výhoda MySQL. Samozřejmě MySQL je také klasika pro web. MySQL je dobrá pro rozsáhlá data s jednoduchou strukturou, a pokud možno s převahou čtení.

Sám nasazuji MySQL omezeně, ale když jí nasadím, nasadím jí tam, kde se projeví její kladné stránky. A pak si lebedím. A samozřejmě nejsem blázen, a nestavím třeba nad MySQL žádné účetní systémy, apod..

>In MySQL Version 3.23.44 or later, InnoDB tables
>support checking of foreign key constraints."
>...
>Naprosto nechápu, kde jste přišel na tu 5.1

Viz
http://www.mysql.com/doc/en/TODO_MySQL_5.1.html
1.9.3 New Features Planned For 5.1
FOREIGN KEY support for all table types.

Jinak nevim, proc jste nasadil tak konfrontacni
ton:
> jsou to z takových 95% výmysly lidí, kteří o
> MySQL nic nevědí

Nerikam, ze o MySQL toho vim hodne, ale neco snad
po dvoulete zkusenosti prece ;-)

Taky nerikam, ze MySQL je dobry ci spatny SRBD,
protoze nerad stoucham do vosiho hnizda.
Snazim se pouze klopotne davam dohromady fakta.
Jejich zhodnoceni pak ponecham na laskavem ctenari ;-)

V zasade souhlasim.
Asi vsak patrim mezi radu lidi, kteri budou tvrdit,
ze s ref.integritou je to u MySQL ponekud osemetne.
Aktualni (stabilni) verze dle http://www.mysql.com/downloads/index.html
je 4.0. Verze ve ktere ma byt implementovan
FOREIGN KEY - 5.1. Tedy vzdalenejsi budoucnost.

Na druhou stranu pokud napr. chcete provozovat free
web site, pocet poskytovatelu, ktery vam nabidnou
X MB prostoru na disku + Y mista pro MySQL je pomerne velky. Obavam se ze totez rozhodne neplati
pro PostgeSQL ci Firebird. Ale rad se necham vyvest
z omylu ;-)

PostgreSQL i Firebird jsou velmi vyspělé databáze. PostgreSQL má v některých směrech více funkcí, pro Firebird mluví možnost používat nástroje a komponenty, které jsou k dispozici pro InterBase (ocení zejména vývojáři v C++ Builder/Delphi/Kylix). Také mám pocit, že díky MGA Firebird lépe zvládá větší množství konkurenčních transakcí. Ale není to podloženo solidními testy, může to být i rozdílnou mírou zkušeností.

MySQL se od těch dvou hodně liší. Primárně je to databáze konstruovaná pro situace, kdy data moc nemodifikujete (a spíš insert než update) a potřebujete hlavně rychlé selecty. Takže podpora některých základních věcí (transakce, foreign keys) je dodělávána dodatečně (a není úplná), jiné chybějí zcela (stored procedures, triggers, ...). Výsledkem je, že uživatel MySQL je nucen prakticky vše řešit na straně klienta a získá tak určité špatné návyky. Přesto má MySQL své uplatnění a pro určité typy aplikací se docela dobře hodí.

Pokud se chcete něco s databázemi skutečně naučit, rozhodně bych doporučil spíš Firebird nebo PostgreSQL. Když pak budete potřebovat použít Sybase nebo MS SQL (nebo třeba i DB/2 či Oracle), budete rozhodně víc "doma".

Jinak ale musím poznamenat, že přechod z MySQL na Firebird není zdaleka takový problém jako přechod opačným směrem.

Na druhou stranu takova replikace databaze (distribuce jedne DB na vic stroju) se hodi. Pri povodnich nam docela pomohla :-) (Ma ji treba Postgres?)

Nevím jak PostgreSQL, ale pro Firebird lze použít IBReplicator. Je to komerční produkt - viz http://www.ibphoenix.com/main.nfs?a=ibphoenix&s=1058877771:11441&page=ibp_replicator
Praktické zkušenosti s ním ale nemám.

K postgresu existuje projekt, ktery pridava
High Availability. Soucasti normalni distrubuce to neni. Udelat neco takoveho nad databazi, ktera ma transakce trigery a ulozene procedury je neco jineho
nez udelat to nad mysql.

Otázkou je, zda to nad transakční databází není stejně jednoduché. Třeba taková Sybase čte transakční log a transakce replikuje dál.

moc diky vsem za info, nakonec jsem zvolil 602sql server -- snadna instalace, prijemne prostredi, vychytavky (napr import dat z ruznych formatu...), plna podpora SQL 92, atd ... a je to i pro linux, panove!

Ostatni produkty mi bud nesedely, nebo jsem je neumel nainstalovat. jeste jednou diky

Kdysi jsem vážně uvažoval o Interbase (tedy
ještě free verzi 6.0). Úspěšně jsem ji našel
na Internetu, nainstaloval - a poté zjistil,
že prakticky neexistuje free ODBC ovladač.
Systém funkční leč nepřístupný. I zalovil
jsem na CD Red Hat 7.1, našel Postgres a zprovoznil
ho. I ovladač ODBC byl k mání. Nejvíc mě ale
potěšilo, že umí bez problémů česky.

http://www.ibphoenix.com/main.nfs?a=ibphoenix&s=1058971675:15617&page=ibp_int_comps

Mozna to sem treba nepatri, ale je to trochu pribuzne tema. Noveji se daji vytvorit (v Oracle od verze 8i) i tzv. objektove tabulky, tj. tabulky, kde radka je tvorena objektem. Za primarni klic je pak mozne zvolit tzv. referenci na objekt, coz je normalni index udrzovany automaticky. Vyhodou je bezvadne API v C++ klientovi, kde je mozne nastavovat fieldy pres REF pointer a databaze sama ulozi tyto fieldy do tabulky. Neni tedy nutne davat prikaz update nebo insert. Je to hezke pro lidi pisici v C++, pro PLSQL nasinec to ma vyhodu ve zjednodusene navigaci (syntaxi) pri joinovani vice tabulek - neni nutne explicitne joinovat. Nevyhodou je neportabilita (ne vsechny databaze objektove SQL podporuji), objekty neni mozne pouzivat pres databazove linky a je nutne vyuzivat primarni klic, coz pro velke a casto se menici tabulky neni vzdy zadouci. Existuje jeste nekolik nevyhod, ale nebudu zabihat do detailu.
Objektove tabulky mam odzkousene, funguji dobre. Daji se pouzit zejmena na tabulku ruznych nastaveni (od zakladniho typu jsou odvozene dalsi specificke typy nastaveni).

Pekny clanek, jenom mam malou pripominku. To, co mate na obrazku neni B-strom (binarni strom) ale N-strom (n-arni strom). Ackoliv se binarni stromy take muzou pouzivat, spise se v relacnich databazich pouzivaji N-stromy. Umoznuji totiz relativne jednoduche vyvazovani a take strankovani na disk.

Hezky den

b-strom = balanced tree

B-strom je skutečně Balanced tree (vyvážený strom), používá se to i v české terminologii. Binární strom se tímto způsobem nezkracuje.

Chtěl bych požádat o radu, i když odpovědi již částečně zazněly. Pracoval jsem na Oracle, nyní na MSSQL (proti Oracle bohužel). Může mě někdo nahodit, jak ve srovnání s ostatními DB vypadá Interbase? Díky

O InterBase se dá říci přibližně totéž jako o Firebirdu, tak moc se zatím (IB 7.0, FB 1.0.3) ty dva projekty rozejít nestihly. InterBase ale není open source (kromě verze 6.0-6.0.1), od verze 6.5 ji Borland opět vyvíjí jako uzavřejný projekt (což je, zjednodušeně řečeno, hlavní důvod vzniku Firebirdu).

Zdravim. Mel bych mensi dotaz. Resim tento problem:
Kazdych 5 minut se do jedne tabulky ulozi data(cca 100 radku). tabulka ma tyto sloupce. in bytes,out bytes,in packets,out packets,timestamp. kdyz pak potrebuju tyto polozky sum() za celej mesic, tak to trva rekneme trosku hafo dlouho. ale pokud zapnu indexovani teto tabulky, tak dojde k tomu z pridavani je tak pomaly, ze za tech 5 minut nez se zacne pridavat znova, se nestihnout udelat ani indexy, takze disk vali furt. Jaky doporucujete reseni? da se v mysql udelat neco jako vytvoreni indexu jenom na cast polozek a zbytek aby dohledaval rucne? tozn. ze bych v noci udelal index cele tabulky, a pres den by se index nedelal na nove polozky.

Da se napr. vytvorit novou tabulku s indexama
a jednou za urc.cas.jedn. tam zaznamy zkopirovat/presunout, coz je z hlediska db teorie
naprosty hnus ;-)
Taky lze puvodni tabulku mit jako temporary
typu HEAP (viz http://www.mysql.com/doc/en/HEAP.html)
Do trvale tabulky pak ukladat pouze data prechroustana z HEAPu.

V první řadě se mi nezdá, že indexování popsaných 100 položek by stroj dokázalo vytížit na 5 minut. To musí být v nepořádku ještě něco jiného.

Ale hlavně je důležité rozmyslet si, nad kterými sloupci vůbec index nasadím. V příspěvku je uvedeno pouze "zapnu indexování tabulky". Jestli to znamená, že je vytvořen index nad všemi sloupci, je tento index v podstatě zbytečný. Jestli je vytvořen nad sloupcem timestamp, není také moc užitečný, protože když pokládám dotaz např. SELECT EXTRACT(YEAR_MONTH FROM timestamp) AS year_month, SUM(in_bytes) FROM data GROUP BY year_month, index se stejně nemůže použít, protože se sloupcem nepracuji přímo, ale přes funkci.

Správné řešení tedy vypadá tak, že se do tabulky přidá ještě sloupec year_month, nad kterým bude jediný index a který se bude počítat už v době vkládání záznamů.

Pokud vám však stačí údaje jako počet položek, jejich součet a průměr po měsících, je lepší primární data vůbec neukládat a jenom si v malé tabulce aktualizovat sledované hodnoty.

Moc vam vsem dekuji. Nakonec jsem to vyresil tak ze porovnavam timestamp < a > nez cislo ktere si v php vytvorim. Zobrazeni aktualniho roku je hotove do 3 sekund a to proti 5 minutam je velice znatelny rozdil. Jeste jednou moc dekuji.

Vážení,
hodně mě to jako amatéra zajímá - celá tato oblast, je možné doporučit nějakou literaturu, která by laikovi přiblížila metodiku databázových indexů a podobných záležitostí (včetně robustních věcí), nějaká pdf na webu, odkazy?
Google mi ne a ne dát odpověď, rád bych si něčím pojmově otevřel oči (nikoli v tom, že "existuje něco jako primární klíč", ale "existují tyto metodologie pro tovrbu indexových stromů, blablabla").

Děkuji - jde mi o odkazy.