Dotaz: Vyplatí se přechod z MySQL na PostgreSQL?

[toi]

Ahoj, řeším teď dilema, potřebuju v aplikaci (jednodušší IS - cca 50 tabulek) používat cizí klíče a transakce, ale v MySQL to umí jen InnoDB a slyšel jsem, že se to může občas i "rozsypat". Nevím jak hodně je tahle informace pravdivá, ale každopádně mě to vyděsilo.

Uvažoval jsem proto o přechodu na Postgres, ale jinde jsem se dočetl, že je v některých případech pomalejší a neumí full text. Nebylo tam ale uvedené, které verze se to týká. Hrál jsem si s verzi 8.4 a zdá se, že to umí všechno co potřebuju.

Můj dotaz tedy zní: Používáte cizí klíče na MySQL a nikdy vás to nevypeklo, nebo jste raději přešli na Postgres a tam jde realizovat (samozřejmě s malými úpravami) všechno jako na MySQL stejně rychle?

Dík moc za zkušenosti.

Odpovědi

[Heron]

Na obyčejné weby, kde o nic nejde, používáme MySQL a to z toho důvodu, že s tím umí pracovat více programátorů.

PostgreSQL používáme na důležitější data a aplikace. Osobně bych doporučil přejít na PostgreSQL co nejdříve, dokud je to ještě z hlediska projektu možné.

Co se týče rychlosti, tak dřívější verze (8.1) byly o něco pomalejší než MySQL, ale dnes se situace obrátila a ve transkačním zpracování je v tomto souboji PSQL vítez (viz test, Radim testoval verzi 8.3). PostgreSQL server se dá také nastavit na vyšší výkon (dovolím si malou reklamu), viz seriál o optimalizaci.

Fulltext má psql dlouho (ani nevím jak dlouho ), dříve jako modul, který se musel doinstalovat, dnes již je součástí.

[cronin]

Odporúčam PostgreSQL.

[Filip Jirsák]

Pokud je to webová aplikace, která bude nasazená na nějakém levném webhostingu, mohlo by se vyplatit zůstat u MySQL (protože PostgreSQL zpravidla na levném webhostingu nenajdete). Jinak bych přešel na PostgreSQL, máte tam (a už dlouho, tj. odzkoušené) nástroje „velkých“ databází – pohledy, uložené procedury, triggery, transakce… MySQL (některé její enginy) něco z toho také už umí, ale je otázka, jak dobře.

MySQL je pokud vím rychlá v případě čtení, když databázi používáte spíš jako skladiště (ne moc strukturovaných) dat. Takže se hodí třeba pro zatížené webové aplikace, kde se z databáze hlavně čte. Jinak bych neřešil rychlost DB jako to nejdůležitější, podle mne je pro IS důležitější třeba to, že data v databázi budete mít konzistentní a správně strukturovaná. Nakonec tím ušetříte i tu rychlost, protože to, co byste s MySQL řešil až v aplikaci, vyřešíte už v databázi (triggery, pohledy apod.).

[trekker.dk]

(protože PostgreSQL zpravidla na levném webhostingu nenajdete)

Je otázka, co se ještě dá považovat za levný webhosting, ale s dovolením bych si přihřál polívčičku (kuk do odstavce Skripty a databáze)

[pavlix]

Já bych přihřál polívčičku třeba přátelém z virtualmaster.cz, kteří nabízejí virtuály. Člověku, co chce slušný webhosting pro větší množství aplikací nebo pro jednou větší aplikaci můžu virtuální servery obecně jen doporučit.

Náklady na infrastrukturu ve stovkách měsíčně bývají mizivé ve srovnání s ostatními náklady, které vývoj a provoz takové aplikace přináší.

[trekker.dk]

Akorát s touhle polívkou jsi off-topic - webhosting a virtuální server je dost odlišná služba. Hosting je předpřipravená služba - zpravidla máš nějaké webové rozhraní, kde si nastavíš služby, které jsou k dispozici, nahraješ aplikaci a funguješ. U virtuálního serveru si musíš v podstatě všechno udělat sám, nainstalovat démona pro web, DB apod.

[pavlix]

Důvod, proč nejsem offtopic jsem popsal ještě dřív, než jsi napsal, že jsem :).

U virtuálního serveru si musíš v podstatě všechno udělat sám, nainstalovat démona pro web, DB apod.

Nemáš pravdu.

Právě proto jsem přihříval polívčičku firmě, u které vím, že toto řeší.

[VM]

Používáme MySQL a InnoDB, máme tabulky se 14 milióny řádek, a za několik let se to zatím nerozsypalo

Samozřejmě doporučuji pravidelné automatické zálohy, rozsypání InnoDB je asi tak ta nejmenší starost. Častější jsou chyby disku, omyly uživatelů a adminů, chyby v databázových klientech apod. - na to už se záloha použila.

Osobně bych do té migrace nešel, dokud bych nezjistil, že se mi databáze opravdu sype.

[l0gik]

Pokud má být důvodem přechodu jen bezpečnost, tak pravidelné zálohování je levnější a jednodušší cesta. Pokud plánujete nějaké rozšiřování (co chápu, že ano), o postgresql bych silně uvažoval z důvodu daleko lepší podpory standardů. InnoDb to sice to vše co píšete umí (a snad už i poměrně stabilně) a navíc InnoDb tabulky se narozdíl od MyISAM nesypají (při výpadku proudu apod., doufám, že máte UPS), ale to je tak vše, co umí. I cizí klíče fungují jen napůl, protože nespouštějí triggery nad daty, které díky cascade mění, CTE neumí skoro vůbec atd...

Naopak fulltext už postgresql umí a co se týče rychlosti, tak na jednoduché dotazy je rychlejší MySQL, ale ty vás u jednoduchého IS trápit nebudou. A složité dotazy běhají lépe v postgresql. Osobně jsem z MySQL na postgresql přešel a zpátky by mě nedostali ani párem koní.

Ale jak píšu, pokud je ale v plánu jen nějaká menší úprava, přechod se Ti nevyplatí, pokud to plánuješ dál rozvíjet, silně bych o tom uvažoval.

[VM]

Osobně se triggerům, vloženým procedurám a podobným věcem po několika špatných zkušenostech raději vyhýbám, a používám jen cizí klíče. Myslím že je vhodnější mít databázi jednoduchou, a výpočty provádět v aplikaci. S tímhle přístupem mi více vyhovuje MySQL než PostgreSQL. Je to primárně otázka vkusu, ale nemyslím, že by MySQL nešla rozšiřovat - existují pod ní docela velké databáze.

[l0gik]

No - pokud chceš např. udržovat materializovaný pohledy, tak je IMHO rozhodně lepší trigger než aplikační přístup. Co se týče špatné zkušenosti, tak každej nástroj je vhodnej na něco a na něco zas ne.

A kromě toho, taková drobnost jako rekurzivní CTE umožní věc, kterou bys psal na apliakční vrstvě půl hodiny, tak napíšeš jedním dotazem za pět minut. Nebo to, že mysql má sice transakce a má fulltext. Ale nemá obojí dohromady. Atd....

Jinak v postgresql jde naprosto bez problémů psát jako v mysql - postgresu (mimo o něco hroší replikaci, ale i to se dosti zlepšilo s poslední verzí). Opačně to ale neplatí.

[VM]

Na věci typu rekurzivních dotazů nebo automatické aktualizace materializovaných pohledů MySQL opravdu není. Osobně jsem rád když je nepotřebuji, a zatím se to dařilo. Stejně tak nechci od databáze, aby při každém insertu pouštěla trigger s komplexním algoritmem používajícím dvacet jiných tabulek - vystačím s atomickou transakcí a integritou přes cizí klíče, zbytek zkontroluji v aplikaci. Fulltext v MySQL je zběsilost sama o sobě, tam bych spíše přemýšlel o vlastním algoritmu. Ale pokud tyhle "vychytávky" opravdu nutně nepotřebujete, pak má MySQL výhodu ve své jednoduchosti, rychlosti a rozšířenosti.

[l0gik]

Hmmm - o co je mysql jednodušší než postgresql? U postgresql člověk nemusí řešit Stejně tak větší rychlost mysql už dávno neplatí - obzvlášť pokud člověk používá transakce, jednotabulkové selecty nad MyISAM asi furt rychlejší budou, ale u dotazů do IS (aspoň teda do rozumnýho IS) to bude přinejmenším jedna jedna.

Psát si vlastní fulltext kvůli tomu, jak blbě ho má databáze implementovaný... no to je Tvůj boj , myslím, že změnit databázi je jednodušší.

Zbejvá jako jediný plus rozšířenost, nepředpokládám ale, že by firemní IS měli na freehostingu. A jinak je to jedno.

Ale hlavně: fór je v tom, že až jednou člověk začne potřebovat triggery, nebo komplexnější joiny, WINDOW funkce, vlastní funkce, CTE apod, tak už bude pozdě. Buď to člověk nějak zbastlí v mysql... nebo přejde.... ale čím se dělá přechod později, tím je to víc práce.

PS: A co se týče třeba těch rekurzivních CTE - neznám např. rozumnou, stejně rychlou a zároveň snadno použitelnou implementaci stromů v databázi. A strom je jedna z nejčastějších datovejch struktur...

[pavlix]

myslím, že změnit databázi je jednodušší.

A hlavně je to lepší a čistší řešení z dlouhodobého pohledu.

[Michal Kubeček]

Myslím že je vhodnější mít databázi jednoduchou, a výpočty provádět v aplikaci.

Máte ten názor něčím podložený nebo to je jen pocit?

[VM]

Jo, nějakou dobu jsem v tom programoval:

• ladit chyby v triggerech a vložených procedurách je za trest
• kód v databázi zvyšuje možnost deadlocků
• mít část kódu v aplikaci a část v databázi celý projekt značně znepřehlední
• je fajn že trigger provádí kontroly jako zda vložená mailová adresa obsahuje zavináč, ale ty způsobí databázovou chybu, která překazí celou operaci a kterou je na rozhraní stejně nutné ještě jednou zpracovat; podobné prkotiny je pohodlnější řešit přímo v aplikaci, a od DB požadovat jen atomicitu operací (viz transakce) a referenční integritu (cizí klíče).
• jednoduché schéma se dá snadno přemigrovat na jinou databázi nebo jinou verzi stejné databáze (maximálně se změní několik málo konkrétních konstrukcí), DB kód je prakticky neportovatelný

[dustin]

S tím souhlasím.

[Heron]

mít část kódu v aplikaci a část v databázi celý projekt značně znepřehlední

A co takhle mít vše v DB? (odstavec Databáze s tisíci uložených procedur).

[Filip Jirsák]

jednoduché schéma se dá snadno přemigrovat na jinou databázi nebo jinou verzi stejné databáze (maximálně se změní několik málo konkrétních konstrukcí), DB kód je prakticky neportovatelný

Z některých diskuzí a popisů vlastností to skoro vypadá, že databázové aplikace se vůbec nevyvíjí proto, aby se používaly a uchovávala se v nich nějaká data, ale aby se neustále migrovaly z databáze do databáze

[l0gik]

+1

[l0gik]

Souhlasím s tím, že absence dobrého IDE dělá vbývoj dosti problematický. Jenže na druhou stranu některé věci jsou bez nich neřešitelné. Např. materializované pohledy atd... Protože, buďto použiješ nějaký ORM model, který se o to bude starat. Jenže pak můžeš zahodit všechny vymoženosti datbází a optimalizace z nich plynoucí a výkon jde do kopru. To pak už je skoro lepší využáít NoSQL.

Anebo používáš SQL +- přímo. Pak ale zas místo jednoho kódu ho děláš na X různých místech a riskuješ, že ho X+1 místě zapomeneš.

Píšeš využívat cizí klíče? A jak to uděláš, když chceš při smazání nějakého podřízeného záznamu něco např. zapsat do logu?? Buď skončíš s cizíma klíčema na aplikační úrovni, se všema problémama, který to nese, nebo naopak s kódem v DB.

Co se týče zachytávání DB výjimek, tak pokud máš dobře navržený střeva, tak se neliší od zachytávání programátorských výjimek. Co se týče deadlocků, tak rozumnej kód deadlock nezpůsobí. Max co se povede je nekonečná procedura, ale o co je složitější zabít thread v db než zabít proces v OS?

Samozřejmě, mít rozdělenej kód v DB a v aplikaci je problém. Chce to dobrou analýzu a jasný kritérium, co bude v DB a co bude v aplikaci, to je asi největší problém DB programování. Mít vše v db to taky zcela neřeší.

Lazení v triggerech je sice za trest, ale ono ani PHP se nijak extra dobře neladí. Sice existují debuggery, ale vzhledem k tomu, že webové aplikace jsou typu akce - reakce, tak se stejně velmi často ladí pomocí echa. A to jdou trigerry ladit úplně stejně. Pokud máš trigerrový kód "testable", tak se testuje v podstatě stejně dobře jako v db a ladění není tak strašné. Problém psaní v databázi spočívá hlavně v tom, udržet štábní kulturu.

[VM]

Materializované pohledy jsou buď triviální SELECT, a pak je nahradím normálním pohledem, nebo jsou výsledkem komplikované operace, a pak typicky nechci aby se ta operace prováděla při každé změně rodičovských tabulek. Samozřejmě by šlo najít nějaký protipříklad, ale zatím jsem to potřeboval jednou (statistika nad 10M+ řádky), a tam jsem použil tabulku co se jednou za čas přepočítá. A i tam by to šlo řešit v aplikaci stejně dobře jako v triggeru, kdybych chtěl. Je to tím že do dané tabulky zapisuje jediná funkce, kde se dají dělat i tyhle výpočty.

NoSQL je dobrá alternativa, ale migroval bych na ni až v momentě, kdy MySQL přestane stíhat. Zatím pořád sype data rychleji než několik Firefoxů najednou stíhá renderovat..

SQL používám přímo, ale samozřejmě všechny dotazy jsou v jednom samostatném modulu. Takže redundance se nekoná a v případě změny databáze změním jeden soubor.

Když chci logovat změny, prostě zavolám logovací funkci z funkce co mění data. Dá se namítnout, že člověk co si pustí SQL prompt může mazat bez logování, ale to mě zatím netrápilo. Takhle můžu logovat co chci a kde chci, nejen to co proteče až do konkrétního triggeru. Jaké jsou ty další problémy?

Zachytávání vyjímek se možná neliší od toho v aplikaci, ale proč to dělat na dvou místech? Dá mi to něco podstatného, když to udělám i v databázi?

To že rozumný kód nezpůsobí deadlock je pěkná teorie, jen bych rád viděl jak dlouho člověku vydrží v praxi. A nemusí být ani prase - stačí zapomenout explicitní lock na některé z tabulek na začátku transakce, a pak si naběhnout na deadlock přes implicitní zámky. Zabít thread se sice dá, ale uživatelé nejsou moc rádi, když kvůli deadlocku lehne celý systém.

S nutností štábní kultury se nedá než souhlasit. PHP taky ladím přes echo a print_r.

[Michal Kubeček]

Většina argumentů, které uvádíte, dává smysl, ale pouze v případě, že s databází pracuje jen jedna aplikace. Jakmile nad stejnou databází pracuje víc různých aplikací, začne právě argument udržovatelnosti kódu velice výrazně vyznívat ve prospěch přenesení co největší části logiky do databáze (nebo přechodu na třívrstvý model).

[dustin]

Dobrý argument. Takže zase záleží na konkrétní situaci :)

[VM]

To si nemyslím, můžete uvést nějaké argumenty?

Osobně bych v takovém případě preferoval minimalistickou databázi plus knihovnu sdílených funkcí pro práci s databází.

[pavlix]

Například SQLite.

[VM]

Nerozumím - SQLite je pokud vím pro paralelní práci nepoužitelná.

[pavlix]

Zaprvé, co asi znamená následující Michalova věta?

Většina argumentů, které uvádíte, dává smysl, ale pouze v případě, že s databází pracuje jen jedna aplikace.

Zadruhé, kategorická tvrzení tohoto typu bývají nesmyslná. Konkrétně v případě SQLite je to co píšeš nesmysl.

[l0gik]

V drtivé většině s Tebou souhlasím, ale teď to chápu jako VM, byť s jeho řešením nesouhlasím. Kubeček psal, že v případě více klientů je výhodnější silná databáze, popř. multitier.

VM psal, že radši než toto řešení by měl minimalistickou databázi + klientskou knihovnu. Na to ale lze co vím SQLite použít, pouze pokud by zapisoval v daném čase pouze jeden člověk, což moc časté u takovýchto aplikací nebývá.... Ale SQLite moc neznám, možná se pletu...

[pavlix]

Ono nejde o to, jestli souhlasit nebo nesouhlasit. Možná si jen nerozumíme. Já to chápal tak, že se vlákno odvíjí od Michalem nadhozené možnosti, kdy s databází pracuje pouze jedna aplikace (či převážně pouze jedna aplikace).

Ale SQLite moc neznám, možná se pletu...

SQLite při zápisu zamyká celý databázový soubor. To znamená, že je vhodná pro použití, kde probíhají krátké (rychlé) zápisy a navíc v nepříliš velkém souběžném množstvím. Aneb pár malých zápisů na sebe holt počká. Souběžné čtení funguje bez problémů.

MySQL se velmi často používá právě na takové různé malé databáze, kde těch masivních zápisů moc není, takže by SQLite fungovalo stejně dobře a daleko jednodušeji. U hodně malých databází (typicky třeba malá webová aplikace) je navíc u SQLite minimalizována režie. Většina operací pak může fungovat jako bleskové čtení pomocí knihovny z diskové cache v RAM.

Ale týká se to právě jen toho specifického použití bez souběžných velkých zápisů.

[l0gik]

- Třeba deployment změn. Když udělám změnu v databázi, vím, že nikdo tam se starší knihovnou nepoleze. Když udělám změnu v aplikační knihovně, tak musím řešit to, že tam někdo poleze se starší knihovnou a bude dělat binec.

- Další problém může být v tom, že přistupující aplikace nemusí sdílet stejný programovací jazyk či platformu, takže knihoven musí být více.

atd..

Pokud bych nechtěl jít cestou silné databáze, tak jako stejně dobrou alternativu bych viděl třívrstvou aplikaci (jednoduchá databáze, midleware poskytující api a klienti). To má své výhody (snažší vývoj) i nevýhody - api odstíní databázi a tím často zneefektivní dotazy do ní.

[VM]

Deployment změn bude problém i v případě kódu v databázi (staré dotazy přestanou s novým kódem fungovat), a v obou případech to bude problém řešitelný (člověk prostě dohledá a opraví ta místa, která nejsou kompatibilní s novou verzí.

Ano, v případě více jazyků bude sdílená knihovna problém. Tedy ony existují způsoby, jak některé jazyky integrovat do některých jiných, ale je to dost divoké. Oddělením sdíleného kódu a přidáním vhodného API pro jiné jazyky fakticky vznikne ten middleware, který uvádíte jako třetí možnost.

[l0gik]

Pokud najdu v aplikaci chybu, tak když je v databázi, tak opravím databázi. Když je v aplikační knihovně, musím oběhat všechny, co tu knihovnu používají, dát jim novou, vysvětlit proč, zajistit, že opravdu všichni použijí tu novou knihovnu.

Když změním schéma databáze, tak pokud je kód v DB, tak připravím migrační skripty včetně úpravy procedur a pohledů, v noci zastavím na pět minut db a provedu upgrade. Po upgradu vše chodí, protože aplikace přistupují k definovanému API, které většinou není třeba změnit, popř. lze deprecated fce namapovat na novou implementaci.

Pokud mám klientské aplikace, tak opět obíhám všechny stanice, navíc než je oběhnu, musí být vystavena aplikacím stará i nová struktura tabulek, což v podstatě bez mezivrstvy v dfatabázi ani dobře nejde, takže starší aplikace musím odříznout (což znamená, že v aplikaci nějak musím hlídat verzi databáze, aby nepadaly v prostředku když zjistí, že nějaká tabulka je jinak atd...).

---

Dát knihovně api pro jiné jazyky. Hmmm... To už radši napíšu plnej middleware. Ladit mezijazykovou komunikaci je daleko složitější a znamená to pro každej jazyk spešl práci, navíc tu zůstávají ostatní nevýhody (viz výše) oproti centrálnímu api na serveru.

Jakmile je více různých klientů, je multivrstvá aplikace podle mě jediným rozumným řešením.

[VM]

Aplikace (alespoň ty webové) obvykle běží na stejném stroji jako databáze, takže oběhávání odpadá. Jinak oba problémy jsou stejné - buď se změny dotknou jen DB kódu / knihovny a pak se nic jiné neaktualizuje, nebo se změní (i) API pro aplikace a ty se musí také přizpůsobit. Pokud máte klasické těžké klienty, tak je druhý případ stejný a v prvním máte výhodu že měněný kód je pouze na jednom místě, typicky ale použijete nějakou centrální aktualizaci nebo automatický update a vyřešíte oba případy.

Ano, kombinovat více jazyků a pouštět to nad stejnou databázovou instancí je dost divoké a nestojí za tu práci.

[Michal Kubeček]

Aplikace (alespoň ty webové) obvykle běží na stejném stroji jako databáze

Klasická logika "já to tak dělám, tak to tak určitě dělají všichni (nebo aspoň většina)".

Ano, kombinovat více jazyků a pouštět to nad stejnou databázovou instancí je dost divoké a nestojí za tu práci.

Proč? To, že data z databáze prezentuje web napsaný v PHP, znamená podle vás, že se má v PHP napsat všechno, co k té databázi přistupuje?

[Michal Kubeček]

Jak už zmínil kolega, aplikace nemusejí být ve stejném jazyce a na stejné platformě. Celkem běžné je, že se stejnou databází pracuje veřejný web, webové aplikace uživatelů, windowsové aplikace, linuxové aplikace atd. A i kdyby to tak nebylo hned na začátku, pravděpodobnost, že k tomu časem dojde, bývá - aspoň u těch aplikací, kterými se zabývám - podstatně vyšší než pravděpodobnost, že to budu chtít migrovat na jinou databázi.

[okbob]

Můžete mi říci, jak kód v db zvyšuje možnost deadlocků?

Navíc slušná db má dneska identifikaci deadlocku, tudíž pravý deadlock je obvykle ten nejmenší problém.

U toho ladění - záleží s jakou db pracujete - je extrémní rozdíl mezi MySQL a třeba PostgreSQL - jak v diagnostice, tak v logování.

Malá poznámka - špatný názor na procedury může být i dán stupidními DB adminy v kterých řada lidí storovky píše. V tom se fakt psát nedají. Ale není důvod, proč procedury nepsat v libovolném programátorském editoru a pak jednoduše importovat do db.

[dad]

pane Kubecek, diky.

Ta Vase poznamka nekde v tech komentarich, (...nebo vicevrsttva aplikace ...) me konecne otevrela oci. Celou dobu jsem zde a na jinych diskuzich nechapal, to (i v teto diskuzi) tak rozsirene mineni , ze ma byt vse v databazi.

Ano mate pravdu, jestlize nekdo dotazuje databazi pres PHP z webu, nejaky klient ve Windows ma v sobe zamontovane SQL statements a nejaka aplikace na linuxu se pta pres DBI v perlu te same databaze na nejaka data, tak pak to asi musi byt nejak reseno v te databazi.

Muj problem byl tu celou donu, ze ja jsem si myslel, ze takovy styl programovani je jakesi bastleni a ze kdo ma o sobe aspon trochu slusne mineni, tak by se stydel o necem takovem otevrene mluvit.

Jak je videt, clovek se neprestane nikdy ucit.

[l0gik]

Z databáze se dá vybudovat vcelku rozumné API. Samozřejmě, pak se do databáze nedotazuješ do tabulek, ale používáš stored procedures. Proč by to mělo bejt horší než jinej middleware?

Ano, multitier uspořádání má svý výhody. Bezpečnost, udržovatelnost, pořádek. Jenže pak zjistíš, že je třeba vytvořit statistiku, na kterou api nemyslí a člověk je někde, protože skládat ji z elementárních "dotazů" zpřístupněnejch pomocí API je to na tejden.

API v databázi má svý velký nevýhody, ale i velký výhody. Jde o to o nich vědět a na danou aplikaci zvolit správnou architekturu. Člověk, co prohlašuje, že je jedna správná architektura.... většinou akorát ostatní neumí použít

[cronin]

Jak je videt, clovek se neprestane nikdy ucit.

Odporúčam túto knihu, a to bez ohľadu na to, s akou databázou pracujete. Je skvelá: mnohé prístupy sa na metaúrovni dajú použiť aj mimo databáz, pri návrhu a implementácii softvéru ako takého. Kniha okrem iného poukazuje na niektoré mýty spojené s databázami a vyvracia ich; zo všetkých spomeniem len mýtus "prenositeľnosti databázovej aplikácie".

[trekker.dk]

a navíc InnoDb tabulky se narozdíl od MyISAM nesypají (při výpadku proudu apod., doufám, že máte UPS)

Co mám zkušenost, tak je to právě naopak. Jasně, MyISAM tabulky po výpadku napájení potřebují opravit, což ale většinou klapne. Na druhou stranu jsme měli případ, kdy se při výpadku napájení rozsypalo InnoDB na celém databázovém stroji.

[nyan]

Pouzivame cizi klice, nevypeklo se to (zatim) :)

Nicmene sem mel nedavno slusnej WTF moment, kdyz sem ladil jeden neprilis slozity dotaz. Funguje skvele, pokud pracuje nad 10 radky. Nad 10k radku mysql smazi CPU pul minuty, kdezto postgresql to same da za 30ms :)

Takze pokud budete pouzivat select * from .. where id= .. a pripadne select x.* from x join y where x.id=y.id tak mysql funguje bajecne. Cokoli slozitejsiho funguje skvele do 10 radku dat :)

Nicmene admini u nas preferuji mysql kvuli replikaci, a tim je postgres vyrizenej.

[dustin]

Zřejmě jsi neměl klíče s vhodnou kombinací sloupců. Explain by poradil. Na docela velké DB (viz níže) pouštíme dost složité dotazy (bez vnořených selectů) přes spoustu tabulek a OK. Samozřejmě chvíli trvalo, než jsme doladili klíče.

[nyan]

Problem byl prave v tom, ze jsem pouzival vnoreny select. A pokud jsem spravne cetl manualy, MySQL nema naprosto zadnou optimalizaci vnorenych selectu - proste to materializuje tabulku nad kterou to pak dela zakazdym full scan.

Ano, manual rika "prepiste subselect na join". To se hezky rika kdyz je ten subselect jednoduchej.

Prozatim sem to vyresil vytvarenim temporary table pred selectem, nicmene je to vopruz.

[nyan]

Konkretne

http://dev.mysql.com/doc/refman/5.1/en/subquery-restrictions.html

Rika

"Possible future optimization: A subquery in the FROM clause is evaluated by materializing the result into a temporary table, and this table does not use indexes. This does not allow the use of indexes in comparison with other tables in the query, although that might be useful."

[dustin]

Tak to pak jo. Joinujeme běžně přes 10+ obludných tabulek a jde to, subselecty nepoužíváme. Je pravda, že pro časově kritické věci v onlinu udržujeme index v compassu, který je pak řádově rychlejší.

[dustin]

Na innodb máme běžně tabulky s desítkami miliónů řádků, největší tabulka myisam má 300 mil. řádků. Na produkčním stroji má soubor ibdata 30GB, mysql celkem 66GB. Na vývojovém serveru, kde má svou db každý z vývojářů, má soubor ibdata 140GB, mysql celkem 270GB. Na serverech má mysql nastaveno něco přes 10GB paměti. Kolega své lokální mysql (60GB) nastavil pouze 500MB paměti a fungoval úplně v pohodě, ani si toho nevšiml :)

Ta DB bobtná v ostrém provozu už od r. 2002 a nikdy žádný problém (ťuk ťuk ). Samozřejmě používáme transakce a referenční integritu.

[dad]

...Samozřejmě používáme transakce a referenční integritu. ...

co ma tohle znamenat?

[dustin]

Že samozřejmě na innodb používáme transakce a referenční integritu. Vidíš nějaký jiný význam?

[dad]

to samozrejme prinasi do hry radu moznych interpretaci. Jako informace staci zcela 'používáme transakce a referenční integritu'

[cronin]

Niekto by mohol mat dojem, ze v pripade niektorej zo zmienenych databaz je celkom bezne navrhovat aplikacie, kde tomu tak nie je. Take tie prevazne-read-only weby.

[dustin]

Nechápu. Když někdo použije innodb, tak považuji za samozřejmost, že pro dané tabulky využívá transakce a referenční integritu. U tabulek, kde to nepotřebuje, zůstane u rychlejší myisam.

Odpovídal jsem na dotaz autora. Mysql používáme v docela náročném systému s rozumným datovým zabezpečením (transakce, ref. int.) skoro deset let a nesetkali jsme se (zatím :) ) se ztrátou dat ani s poklesem výkonu.

Kdo si chce hrát se slovíčky, vždycky si důvod najde.

[dad]

nekdo pouziva innodb, protoze to vedeni naridilo. Kolega pouziva innodb plugin s handlersocketem - tam je ref. integrita k nicemu.

Na svete je rada aplikaci, ktere byly napsany pro myisam, ted to bezi s innodb.

Mozna to nekomu pripada jako slovickareni , ale ja to proste nemam rad, kdyz nekdo v technicke oblasti prohlasi sve myslenky za samozrejme. Myslim si, ze povinnosti nas techniku je na toto zvracene chovani upozornit.

[dustin]

Nemám chuť se s tebou hádat o nesmyslech.

[Petr Ježek]

Spíš nemáte chuť přiznat se k většímu podílu technické odpovědnosti... Taky informace... Zkuste to přece jen ještě promyslet a dada trochu následovat

[dustin]

"povinnosti nas techniku je na toto zvracene chovani upozornit. ", "přiznat se k technické zodpovědnosti" - vážně nemáte nic lepšího na práci než psát takové blafy v reakci na jedno slovo, navíc za kterým si stojím, protože použití transakcí a referenční integrity na innodb já osobně považuji za samozřejmost?

[rpajik]

Postgresql je vyborna databaze, ale vyzaduje mnohem hlubsi znalosti nez mysql. Pokud nemate nikoho kdo takove zkusenosti a znalosti ma, zustante u mysql.

MySQL: Innodb je stabilni, neni ceho se bat

[l0gik]

Proč postgresql vyžaduje daleko hlubší znalosti? To, že toho umí daleko víc přeci neznamená, že to člověk musí používat. Psát se v ní dá úplně stejně blbě, jako v mysql. Spíš teda líp, protože je daleko konzistentnější a zároveň nemá hloupý omezení, např.:

Proč jsou všechny datový typy defaultně null a timestamp not null? Proč nejde udělat víc sloupců default current timestamp? Proč jde fulltext jen nad některým typem tabulky a transakce zas nad jiným? Proč varchar sloupec je ořezanej zprava o mezery, který tam jsou explicitně uvedený. atd...

To, že je postgresql složitější než mysql se možná zdá člověku, kterej zná mysql. V porovnání s mysql je ale postgresql daleko intuitivnější a nehází člověku klacky pod nohy. Zároveň se s postgresql člověk naučí standard, kterej respektují všechny databáze. S mysql se naučí hromadu často nesmyslných výjimek (který se navíc verzi od verze měněj).

[Heron]

Ještě bych možná doplnil, postgres má daleko více datových typů a funkcí k nim. Zatímco v MySQL se to bohužel bastlí (a začínající programátor si na to zvykne a pak má problém programovat normálně -- "vždyť přece ani php datové typy neřeší", zní často odpovědi) stylem například IPv4 = VARCHAR(15) (což je teda špatně i z jiných důvodů), tak v psql je na internetovou adresu přímo datový typ. Nehledě na to, že je snadné si vytvořit vlastní typy.

Jinými slovy, psql poskytuje programátorovi daleko více prostředků a je jen na něm, jestli je použije. V MySQL nemá jinou možnost, než to nějak nabastlit.

[dad]

to co pisete povazuji za problem. Vim, ze i pan Stehule a jini radi, ze aplikace se ma psat pro urcitou databazi, ze ta prenositelnost nefunguje. Ten vas priklad s tim datovym typem = ipv4-adresa je pekna ukazka, jak se udelat na nejake databazi zavislym.

Ale dotaz prece ukazuje, ze neni mozne, aby byly vsechny aplikace jiz napsany pro pgsql. Pred 10 lety by takova aplikace nikde nefungovala. Proto je legitimni, ze se rada lidi pta, jakym smerem jit. A pro takove lidi mam je jedno reseni - napis to nejak tak vseobecne, bez zavislosti na nejakou databazi. A pro tuto skupinu uzivatelu jsou vase argumenty k nicemu.

Jeste k tomu datovemu typu. Databaze tu sama neni ve vzduchoprazdnu. Casto je to skloubeno s nejakym IDE, clientskym prostredim. Ktery z techto prostredku ovlada datovy typ=ipv4 adresa?

[Heron]

Tu cestu si musí zvolit každý sám. Buď chci plně využívat prostředky nějaké knihovny, os, db a potom se daný program na té platformě stane závislým. Vývoj je velmi rychlý, využívá maximální počet externích (již napsaných) komponent.

Nebo se dám cestou maximální nezávislosti a nebudu používat žádnou hotovou DB (protože průnik schopností všech možných DB je tak na úrovni jednoduché tabulky s key-value funkcionalitou) a budu si to vše psát sám a ten program nebude závislý ani na glibc, ani nebude vyžadovat posix. Ovšem jak dlouho to bude trvat a s jakým výsledkem?

Jistě, tohle jsou extrémy, reálná situace je někde mezi. Ad ten příklad s tou ip adresou. To jsem si nevymyslel jen tak pro srandu. Tady na abc se někdo ptal, jak má do DB uložit IPv4. A bylo mu doporučeno mimo jiné také varchar(15). Považujete to za správné řešení? Asi ne, že. Kdyby se nad tím daný programátor alespoň trochu zamyslel, tak to uloží jako 32b integer. A nejen na základě této zkušenosti bych skutečně doporučovat používat přímo konkrétní datový typ (i s ryzikem, že bude nekompatibilní). Výsledek bude rychlejší a v případě použití funkcí db i správný a bude mu to automaticky fungovat i pro IPv6. To o ip adrese ve stringu(15) a vlastních funkcích v php říct nelze.

Pred 10 lety by takova aplikace nikde nefungovala.

Ano, ta aplikace by před 10 lety na psql nefungovala (což ale nelze říct s jistotou, jelikož před 10 lety to byla zcela jiná app), jenže ona by nefungovala ani z mnoha dalších důvodů. Verze php, externí knihovny (už jenom vůbec jejich existence v novém systému je často problém) apod. Je jen velmi málo větších aplikací, které lze bez problémů provozovat takhle dlouho beze změn.

[Filip Jirsák]

Otázka ale je, zda pro to, co popisujete, je vhodné použít relační databázi. Vy směřujete spíše k úložišti nepříliš strukturovaných dat, a na to se spíše hodí nějaká NoSQL databáze nebo něco takového.

[l0gik]

Postgresql se drží dosti silně standardu, takže aplikace v ní je vcelku snadno portovatelná např na Oracle (stejně jako na většinu rozumnej db). Takže vendor lock i postgresql moc nehrozí. A zbavovat se poloviny vymožeností databáze jen proto, abych moh aplikaci downgradovat na Mysql?

S psaním aplikace tak, aby běžela všude rozhodně nesouhlasím. Zrovna třeba napsat aplikaci pro mysql znamená udělat spešl SQL skript, anžto nepodporuje spoustu věcí, z těch nevyhnutelně nutných např. sekvence. Takže chtě nechtě člověk při portaci mezi databázema úpravy dělat bude, něco jako společný jmenovatel všech databází v podstatě neexistuje.

Ale hlavně: pokud člověk 100% nezprasí analýzu, tak předem ví, za jakejch podmínek bude aplikace běžet. Takže výhledově změna db nehrozí. A co bude s aplikací za deset let, to opravdu rozumnej člověk neřeší, protože rozumnej člověk neví ani, jestli bude za deset let živej, natož co se v IT za těch deset let stane

[Šangala]

Důležité je vždy znát nástroj, s kterým pracujete. Je jedno jestli je to MySQL ne PostgreSQL - obě fungují, obě mají referenční integritu, transakce a triggery. Nelíbí se mi když se shazuje MySQL a příklad s IPv4 adresou mě tedy moc nebere…, proto „protiútok “ :

• „MySql má unsigned (8/16/24/32/64 bit) INT-y.“
• „MySql má 24 bit INT.“
• „MySql obvykle zabere na disku méně místa.“

což PostgreSQL bohužel ne, a mohou to být zrovna důvody proč si vybrat MySQL…

[trekker.dk]

což PostgreSQL bohužel ne, a mohou to být zrovna důvody proč si vybrat MySQL…

Tak nějak si nedovedu představit, pro koho by nepřítomnost 8 a 24 bit intu byla rozhodujícím důvodem pro použití MySQL.

[pavlix]

Jsem na tom úplně stejně.

[Heron]

A já se také přidám

+1

[Šangala]

Né, že bych takové reakce nečekal… .
Tak si představte, že máte zpracovávat stovky milionů záznamů kde lze využít efektivně rozsah 0-255 a 0-16777215 a nasadím na to 2byte a 4byte nebo 1 byte a 3byte to je při jednom a jednom sloupci při 100mil záznamů 200MiB navíc.
A to mě, a třeba i někoho jiného, opravdu na spustu aplikací zajímá.
A to nemluvím o rozsahu unsigned int, kde pokud je platný rozsah přes 2GiB musím nasadit 8byte místo 4byte (což je docela častý případ oproti velmi specifickému 24bit int-u).
To, že to není rozhodující na informační systém či e-shop ještě neznamená, že to nemůže být rozhodujícím důvodem pro jiné využití.

[okbob]

To je právě na PostgreSQL hezké, že pokud bych opravdu chtěl, tak si takovéto číselné typy můžu dostat jako vlastní datové typy. Pak už můžete velice efektivně pracovat s velkými daty - i když ještě efektivnější je použít pole a pokud zrovna nepracujete s nekomprimovatelným šumem, tak by se měla projevit komprimace.

[Heron]

Nechápu to špatně. Jen si nejsem jist (neznám přesně danou aplikaci a její účel), jestli je zrovna relační sql databáze (jakákoliv) to pravé řešení pro zrovna toto využití. Pro uložení a zpracovaní takto dlouhých polí čísel jsou vhodnější systémy.

A 200MB navíc není nic, čím bych se měl zabývat, obzvláště za stavu, pokud je výkon (který je obvykle až na prvním místě) databáze stejný.

Pavel Stěhule se zmínil o možnosti použít pole (PostgreSQL má pole) pro datové řady (já jej (zatím) nepoužívám). Data na disku (pokud o to jde) by mohla být o dost menší.

Ale nakonec, pokud ti to funguje a jsi s tím spokojený, tak není co řešit.

[trekker.dk]

Tak si představte, že máte zpracovávat stovky milionů záznamů ... to je při jednom a jednom sloupci při 100mil záznamů 200MiB navíc.

No to si klidně představím, ale na druhou stranu si taky představím, že v každém řádku budou další data a proti celkové velikosti tabulky můžu nějakých pár set mega s klidem zanedbat... Tím chci říct, že pokud bude Postgres se stejnými daty rychlejší, to místo na disku rád obětuju a rozhodně mu nebudu přikládat takovou váhu.

[Michal Kubeček]

Jak už bylo řečeno, tam, kde se pracuje se stovkami milionů záznamů, obvykle 200 MB nikoho příliš netrápí (jsou i výjimky, ale jsou to jen výjimky). Naopak, existují platformy, kde - aspoň v paměti - neušetříte nic, protože procesor buď s nezarovnanými hodnotami pracovat neumí vůbec nebo to znamená takovou výkonovou penalizaci, že si to každý rozmyslí.

A to nemluvím o rozsahu unsigned int, kde pokud je platný rozsah přes 2GiB musím nasadit 8byte místo 4byte (což je docela častý případ oproti velmi specifickému 24bit int-u).

V takovém případě nechápu, v čem by mi pomohl 24-bitový integer.

[Šangala]

Nijak, ale unsigned 32bit int ano :), psal jsem o dvou věcech o 24bit integeru, který je velmi chytlavý, protože je to něco neobvyklého, a o unsigned typech, což by mohlo být pochopitelnější/akceptovatelnější uznat výhodu :o). Možná jsem to měl napsat obráceně a „vyzdvihnout“ unsigned typy.
Většina z Vás co se Vám nezdá nasazení 8,24bit integerů či unsigned typů (čti „píšící v tomto vlákně :)“) vychází z předpokladu, že se databáze používají jen na vyhrazeném serveru s optimalizovaným hardware. Databáze lze používat i lokálně na běžném hardware nebo na hardware „obyčejném“, který slouží jako spousta dalších věcí. A 200MiB může být hodně (a kdyby to byl rozsah 0-4294967295 jen jednoho sloupce, tak je to 400Mib, a to je jen jeden a jen 100mil záznamů…).
Uvedu jiný příklad příklad (protože na předchozí lze argumentovat, „je lepší zainvestovat protože,…“ - což ale nemusí být tak jednoduché):
Představte si, že realizujete měření ze spoustou hodnot a záznamů a potřebujete je analyzovat (tabulkový procesor už na to dávno nestačí) a většina senzorů dává hodnoty normalizované do rozsahů běžných datových typů (a to plně, tedy 2^8, 2^16, 2^32) a MySQL v tomto případě vychází vstříc, není třeba nasazovat „vyšší“ datový typ na rozdíl od PostgreSQL (či Javy :)).
PS: a jsou tam i jiné údaje, vazby reporty, které ospravedlňují nasazení databáze.
Znovu zdůrazním, že neříkám, že PostgreSQL je horší (nebo lepší), jen poukazuji na argumenty, kde může být MySQL vhodnější volbou díky vlastnostem, které PostgreSQL nemá (ano i takové jsou ).

[Filip Jirsák]

To už ale zase nepopisujete relační databázi, ale spíš nějaké skladiště ne příliš strukturovaných dat. Mezi SQL databázemi je na takovéhle využití asi nejvhodnější MySQL, ale podle mne jsou lepší způsoby, jak s takovými daty pracovat, než je jakákoli SQL databáze.

[Šangala]

To je zaklínadlo?, nezapadá to do mé škatulky, je na to vhodnější jiný způsob…

[Filip Jirsák]

Jaké zaklínadlo? To je prostě fakt, že existuje na počítači spousta činností, pro které MySQL není tím nejvhodnějším nástrojem.

[Šangala]

Jo jako textový editor to není nejlepší…
„Zaklínadlo“ - jsem použil proto, že jsem to viděl psáno (tady někde kol a kolem) už několikrát.
To, že nějaká část informací není „dostatečně“ strukturovaná neznamená, že zbytek informací už není „dostatečně“ strukturovaných.
To jakoby jste řekl, že třeba statistiky nepatří do databáze - patří je tam spousta strukturovaných informací, ale mimo jiné je možné se dopracovat až na vstupní data, pokud se jde do detailu. A i kdyby to byli jen „jednotabulková data“ a má ně mít přístup online přístup více uživatelů a má s nimi pracovat a je komplikované je načíst celé do paměti, tak je databáze docela vhodná, protože je to za zlomek času připravené a poskytuje to maximální flexibilitu byť třeba jen se „70%“ výkonem.

[Filip Jirsák]

Jenže pokud mám nějaká strukturovaná data, chci je mít v databázi, která jejich strukturu co nejlépe ochrání a využije. Ta méně strukturovaná data pak dám do stejné databáze, i když třeba nebudou uložena tak efektivně v 3bajtových sloupečcích. Opačný postup – vybrat databázi pro ta méně strukturovaná data a pak se divit, že ta strukturovaná se v ní degradují, mi nepřipadá jako dobrý nápad.

[dustin]

Myslím, že těch kritérií je v reálu vždycky více. Vedle čistoty návrhu je to i rychlost/výkon, náklady na provoz (spotřebovaný prostor na disku, který je potřeba mirrorovat na záložní slave server, příp. pravidelně zálohovat), spotřeba paměti (např. jsem na limitu RAM serveru a nechci kupovat jiný), atd. Vždycky jde v nějaké míře o kompromis.

[Šangala]

Nenapsal bych to lépe :)

[Šangala]

Soustředil bych se raději na 4bajtové a 8bajtové (to je znatelnější a ne tak diskutabilní).
Tedy říkáte, že strukturovaná data v MySql degradují?

[dad]

ja porad presne nechapu, co myslite tim 'strukturovana data'. Je mozno oznacit datouvou skladbu beznych IS (ERP systemy, systemy pro rizeni vyroby) jako strukturovanou? Minite tim 'strukturovany' prave ty vsechny mozne i nemozne zavislosti tech dat a jejich provazanost?

[Filip Jirsák]

Ano, strukturovanými daty myslím jejich provázanost, logická omezení atd. To, co se v SQL databázích implementuje pomocí referenční integrity, cizích klíčů, omezení, triggerů, uložených procedur apod.

V databázi, která tohle nepodporuje, se tahle strukturovanost bude postupně rozpadat – najednou zjistíte, že o některých smazaných záznamech chybí záznam v logu, některé řádky obsahují logicky nesmyslné hodnoty atd.

[Šangala]

Obecně ano, ale tady je řeč o PostgreSQL a MySQL, kterou s vypsaných vlastností některá z nich neumožňuje.

[pavlix]

Spíš se mi nelíbí, jak moc vždy MySQL umožňovala prasit. Mohlo by se zdát, že tím „umí něco navíc“, ale v praxi to spíš znamená, že to vždycky někdo sprasí a já už s tím nic neudělám.

Takže ono má sice MySQL dodatečně dolepenou i hromadu schopností, které předtím mělo jen PostgreSQL, ale už jen to, že jsou dolepené dodatečně může být problém. A nemám čas ani chuť zjišťovat, jestli jsou dolepené dobře.

[Filip Jirsák]

Akorát MySQL ty vlastnosti právě jen umožňuje – můžete ten příkaz napsat, neskončí chybou, ale je otázka, co to udělá. Na to pak musíte jít do dokumentace a zjišťovat, zda váš případ není jedním z mnoha, kdy to zatím nefunguje. Je pravda, že MySQL neustále přidává nové vlastnosti, ale jak dlouho bude trvat, než dožene jiné databáze? A má se o to vůbec snažit? A pokud chcete něco konkrétního – cizí klíče v MySQL někdy fungují a někdy ne (záleží na použitém enginu), triggery se někdy nespouští (třeba při kaskádových operacích). Pro další si stačí pročíst sekci E dokumentace – Restrictions and Limits.

[dustin]

Engine je součástí definice tabulky, takže nevidím důvod, proč by to někdy mělo fungovat a někdy ne. Když chci jinou instanci, dumpnu vše nebo zkopírují přímo datový adresář. V obou případech zůstane engine tabulky zachován.

Tím neříkám, že mysql je nějaký zázrak, ale pro spoustu aplikací se to dobrá volba. My jsme se pro mysql/innodb rozhodli v době, kdy testy stejných pravda jednoduchých query na postgresu dávaly řádově delší časy. Tehdy by nám postgres požadovanou odezvu neposkytl. Možná už je to dnes lepší (asi určitě), ale nemáme důvod z mysql odcházet. Třeba jednou se ten důvod objeví a pak zainvestujeme čas = finance do přechodu. Ale zase je to o konkrétních potřebách v konkrétním čase, kdy taková investice bude dávat smysl.

[l0gik]

No např. constraints nefungují vůbec. Trigerry zas nefungují přes referenční integritu - u nich to je opravdu někdy a někdy ne. Deffered foreign key v mysql také není. Samozřejmě, to všechno jsou věci, které lze vyřešit jinak (byť složitěji) a pokud už je aplikace hotová, tak přejití stojí peníze. To ale neznamená, že mysql je na daný účel vhodnější, pouze je to historická limitace.

btw. na tomdle příkladu je hezky vidět, že se postgresql vyplatilo se vykašlat na optimalizaci a nejdřív udělat pořádně střeva. Protože jak je vidět, optimalizace (u dobře navržené architektury) se dožene, ale architektura se jen tak jednoduše neopraví....

[dustin]

Nikde netvrdím, že výše uvedené umí. Nepoužíváme to. Deferred foreign key - v transakci používáme logické pořadí zápisů, takže to chybu nehodí. A při příp. nalévání celé db z dumpu cizí klíče na začátku vypneme a na konci zase zapneme. Používáme to tak roky a nikdy s tím problém nebyl. Prostě nám to nechybí. Samozřejmě tím neříkám, že to pro někoho jiného nemůže být zásadní požadavek.

Mysql byla pro náš účel vhodnější, protože je (minimálně tehdy byla) výrazně rychlejší a to je zásadní kritérium. Historická limitace vlastností v našem případě není problém. Takže zase platí, že vždy záleží na konkrétní situaci a potřebách.

Nejsem si vůbec jist, že postgres již rychlostně dohnal mysql na jednodušších dotazech bez poddotazů, které používáme. A dávat část byznys logiky do aplikace a část do db - možná je to technicko-teoreticky správné, ale to minimálně v dohledné době opravdu nebudeme. Potřebujeme rychlý a spolehlivý vývoj s kvalitním IDE (intellij) a zapracování nových lidí na náš systém v rámci měsíců a ne roků. To všechno stojí peníze

[l0gik]

Logické pořádí zápisů Ti nepomůže, pokud máš cirkular references. A ty jsou někdy potřeba. Samozřejmě, jde se bez nich obejít, nebo to udělat dvojím zápisem, ale obojí je zbytečná práce navíc.

Zbytek tvé argumentace je je: "běžíme na mysql a tak nechceme přecházet, stojí to peníze", což samozřejmě je argument, ale naprosto nevypovídající nic o kvalitě mysql či postgresql.

[dustin]

ad A) - jistě, cyklické závislosti nemáme a nikdy jsme na ně za deset let v DB se 690 tabulkami nenarazili. Samozřejmě někdo je může potřebovat, pak ale nezvolí mysql.

ad B) - jistě, nikdy jsem netvrdil, že je mysql obecně kvalitnější než postgres. My potřebujeme rychlost, kterou nám mysql dlouhodobě dává (všimni si toho "dlouhodobě" :) ), s pro nás dostačujícími featurami pro konzistenci DB. Takže pro nás je mysql vhodnější (viz tvé "To ale neznamená, že mysql je na daný účel vhodnější, pouze je to historická limitace. "). Až/jestli bude vhodnější postgres o tolik, aby to ospravedlnilo přechod, tak přejdeme. Nic jiného netvrdím. Netvrdím (narozdíl od jiných příspěvatelů), že je obecně X lepší než Y, ale že vždycky záleží na konkrétní situaci a potřebách.

[l0gik]

Ad A) Cyklické závislosti jsou dosti běžné. Např. člověk má více telefonů (tzn telefon má cizí klíč na osobu) ale osoba má jeden prefereovaný telefon (tzn. ta osoba má cizí klíč na telefon). Atd... Jestli v datové struktuře nakonec budou nebo ne by samozřejmě člověk měl z analýzy zjistit, ale málokdy dopadne vždy všechno dle analýzy. A měnit DB v prostřed projektu bych nechtěl.

Ad B) Čo bolo, to bolo. Pokud teď vybírám databázi, tak mě s nezajímá, jaký měla výkon před pěti lety, ale jaké má vlastnosti teď.

Samozřejmě, že vždy závisí na potřebách. Dovolím si ale trdit, že vlastností, ve kterých je MySQL objektivně lepší než postgresql (mezi to bude např. patřit rychlost čtení z netransakčních tabulek při málo klientech) je daleko méně než těch, ve kterých je horší a proto bude postgresql pro většinu případů vhodnější. Nevylučuje to samozřejmě, že se najdou případy opačné.

[dustin]

Proč si nemohu jenom jeden z těch telefonů označit nějakým příznakem, že je preferovaný?

Jak jsem říkal, nikde není napsané, že by dnes výkon postgresu pro naši aplikaci byl již dostatečný. To je jenom neověřená domněnka. Je docela pravděpodobné, že po úvodních testech bychom zase volili mysql. Šance je nižší než před cca deseti lety, ale bez testů bych se v žádném případě nerozhodoval. Aspoň já to tak silně ve prospěch postgresu nevidím.

[pavlix]

Proč si nemohu jenom jeden z těch telefonů označit nějakým příznakem, že je preferovaný?

Proč bys nemohl, tady se ale bavíme o vztazích, ne o tom, když se snažíš db zneužít k jinému uložení (pozor na integritní omezení, že jen jeden telefon je preferovaný).

[dustin]

Tu db nijak nezneužívám, prostě někdo má několik telefonních čísel a u některých (nebo jednoho) řeknu, že je preferovaný. Co je na tom za zneužití? A víš proč bych to tak uložil? Protože takové umělé omezení na jedno preferované číslo už za měsíc nemusí platit, protože bude potřeba třeba dva/tři preferované telefony - např. přes různé operátory. Aspoň tak to funguje v našem byznysu. A s původním možná teoreticky dokonalým řešením budu namydlenej.

Fixní zadání jsou dobrá tak leda pro datové schránky specifikované zákonem a ani tam to není navždy. Ale to už je opravdu úplně jiná diskuse...

[pavlix]

A s původním možná teoreticky dokonalým řešením budu namydlenej.

Budeš úplně stejně namydlenej v obou případech :). Protože ono se ti třeba změní zadání a budeš muset preferenci řešit úplně jinak (třeba vícestupňově). Ale přiznej si bez mučení, že teď už se snažíš jenom v diskuzi vyhrát a nic jiného. A to je nuda.

[dustin]

Můj úplně offtopic - toto řešíme tak, že používáme objektovou databázi (pravda mapovanou na relace) a do db vůbec neukládáme realitu. Takže db model jsme neměnili už spoustu let, zatímco objektový model rozšiřujeme a upravujeme každý den. Nemám rád klasické aplikace na relační db, to je skutečná nuda :)

Ale beru, že toto už je úplně mimo mísu.

Nemám problém souhlasit, že přesné znění původního zadání v mysql/innodb uložit nejde. To je nezpochybnitelný fakt, proč bych se měl hádat? Jen bych to tak nikdy neřešil, protože viz výše :)

[l0gik]

Když už OT: Moh bys prosím rozvíst tu objektovou databázi? Docela by mě to zajímalo. Je to jen že databázi používáte jako "hloupej sklad objektů": tzn. rozložíte objekty na souhrn vlastnost: hodnota (nebo nějak chytřejc). Nebo používáte nějakou spešl nadstavbu nad mysql nebo ještě něco jinýho?

Todle téma mě dost zajímá, nějakou objektovou databázi bych bral, ale ještě jsem se nepotkal s tím, že by ji někdo používal v praxi (aniž by se nezbavil výhod databází, jako např. joinování apod.).

[dustin]

Zase to není žádná velká věda, docela selský rozum. Návrh pochází z roku 2002, kdy už byly zárodky objektových databází i mapování objektů na relace, ale nikdo v nich neřešil přístupová práva (aspoň jsme je neznali). Objekty mají atributy a vazby mezi objekty. Každý typ atributu má svou tabulku, value je konkrétní datový typ kvůli optimalizaci. Všechny objekty jsou v jedné tabulce, která obsahuje rovnou i atributy společné pro všechny objekty a pá optimalizačních hacků (název, typ, datum vytvoření, právo na čtení, zda je smazaný, zda je platný a pár drobností). Práva jsou klasická ACLka na autorizační entity (read, write, delete, link), ale uložené tak, aby se to dalo dobře joinovat. Vazby jsou v jedné tabulce - typ vazby, od, do, priorita. Priorita je číselná hodnota, která se používá např. při určování pořadí výpisu objektu mezi sourozenci ve stromové struktuře (obecně tématické okruhy, menu, atd.)

Objektová DB v javě definuje obecné chování jednotlivých typů objektů (dokument, téma ve stromu, uživatel, firma, nějaký master+slave, atd.) a vazeb (typicky požadavky na práva na obou stranách), kešuje objekty a poskytuje společné služby (cache pro snadný průchod stromem s ohledem práva aktuální sešny, logování, atd.). Vyhledává se definicí požadavků, objektová vrstva sama vyrobí potřebná query s joiny/left joiny a zajištěním práv. Bohužel neumí joiny na úrovni objektů, to je asi to, co tě nejvíce zajímá.

Realita je taková, že pro stávající objem dat cca 70GB (přes milión objektů, 400 typů atributů (tedy attr. tabulek)) už DB nestíhá provádět složité joiny v řádech desítek milisekund, abychom se dostávali s natažením poměrně komplikovaných stránek řádově do stovek milisekund. To je o onlinu, ve spoustě offline aplikací tak rychlé odezvy nejsou potřeba. Proto kešujeme, co jde, a hlavně klíčová data indexujeme do compassu, nad kterým provádíme vlastní dotazy. Je to jenom sekundární index, primární data jsou v DB. A ta objektová vrstva se sama rozhoduje, zda má pro dotaz dostatečná data v kompasu, aby se zeptala jej, nebo hodí klasický ale pomalejší join do databáze. V kompasu se dostáváme na odezvy v řádech milisekund, ten index je mnohem menší. Takže když to někde začne váznout, jenom přiindexujeme další atributy do kompasu a samo se to přepne.

Kdybych to měl řešit dnes, asi bych neřešil mysql vs. postgres, ale slq vs. nosql :)

[dustin]

Jen dodám, že to je především dílo mých kolegů, kteří sem také chodí, já jim do toho jenom kecám :)

[l0gik]

Určitě je to krásnej kus kódu, ale ukazuje to ten problém, který maj všechny takovýdle ORM (jestli jsem to dobře pochopil, tak jde v podstatě o ORM se specifickým mapováním do databáze, a tím je naprostá rezignace na využití databáze. Na to co píšeš by v podstatě sxtačil jakýkoli key-value systém, kterej umí transakce, např. couchDb. V podstatě jste akorát trochu předběhli NoSQL databáze. Nebo něco takovýdleho: http://blogs.innodb.com/wp/2011/04/nosql-to-innodb-with-memcached/

V podstatě ale bych už u Vás ani nemluvil o databázový aplikaci...

[Ladicek]

CouchDB neumí transakce. Jinak ano, jde v zásadě o svého druhu dokumentovou databázi – osobně jsem přesvědčený, že k obdobnému řešení došlo mnoho firem, které se zabývají systémy pro správu dokumentů (ostatně viz Java Content Repository, to je vlastně taky NoSQL databáze).

[l0gik]

No, neumí transakce, ale umí verzování, pomocí kterejch jde dost vlastností transakcí používat. Ale pravda, nikdy jsem se nezajímal o to, jak je na tom ta emulace s výkonem.

[Ladicek]

Momentálně asi největší problém CouchDB je ten, že MVCC token se jmenuje rev. Svádí to k myšlence, že CouchDB umí nějaké verzování, což není pravda a zjistíte to okamžitě, jakmile pustíte první compaction nebo použijete replikaci.

[l0gik]

Jo, máš pravdu, to jsem tvrdil moc silně, emulovat to jde tak napůl.

[Heron]

Transkakce jako BEGIN prikaz1 ... prikazN COMMIT to sice neumí, ale každá operace (vložení záznamu, editace) je atomická a záznam je tak buď v pořádku vložen, nebo ne.

Je to tak?

[Ladicek]

Jest tak. Pokud se vypnou odložené commity, tak je každá operace plně ACID.

[l0gik]

Jenže na IS ti nestačí atomicita jedný operace...

[Ladicek]

Proto taky, viz o pár řádek výše, upozorňuju na to, že CouchDB neumí transakce.

Ostatně s tímhle tvrzením by se dalo polemizovat, viz např. Transactionless

[dad]

rad bych upozornil zastance toho 'jedineho spravneho databazoveho umeni', aby ten clanek radsi necetli. Aby je nahodou netrefil šlak.

Ref. integrita v codu,, zadne transakce, jen zcela vyjimecne trigerry a ulozene procedury.

Kacirstvi.

[l0gik]

No, v případě ebay je to pochopitelný, protože to je v podstatě úplně jednoduchá aplikace - její schéma si defakto vystačí s pár tabulkama - která jen potřebuje enormní výkon a hlavně rozložení zátěže. A tak zatímco jednu z největších výhod DB: optimalizaci složitých dotazů, skoro nepoužije, rozložení zátěže je pro klasický koncept databáze jedno z nejslabších míst.

Co je špatně na tom udržovat ref. integritu v kódu? Ano, pro ěžné aplikace je výhodnější si to nechat dělat od databáze. Pokud je ale důvod si to řešit sám, proč ne...

[okbob]

Proč by je měl trefit šlak?

Je přirozené, že postupy, které dobře fungují pro aplikace na národní úrovni, tak selhávají u globálně dostupných aplikací - resp. se dostáváte do situací, ke kterým je nutné přistupovat originálně - nicméně vždy bude platit, že buďto máte garantovaná data a pomalejší zápis nebo nemáte garantovaná data v db a máte rychlejší zápis. Pokud se všechna související data nacpou do jednoho objektu, tak se bez transakcí obejdete (a z velké části i bez referenční integrity)- ale přijdete o variabilitu v dotazech - kterou ovšem v řadě případů nepotřebujete nebo nedokážete využít.

Navíc - hodně www aplikací potřebuje jen pro menší část dat databázový systém - z velké části tyto aplikace potřebují spíše částečně persistentní strukturovanou cache, kde není nutné za každou cenu garantovat data. V cloudu se pracuje s jiným hw, kdy samotný hw (paměť, procesor) je extrémně levný - a disk je buďto nejištěný nebo pomalý - v tom případě se vyplatí se jistit nikoliv transakčním logem, ale zrcadlením - což je právě transactionless přístup.

[dustin]

Jo, kdyby byla výkonná objektová db s transakcemi, přístupovými právy (ACLs) na jednotlivé objekty a rozumnou replikací, tak bychom se pro objektový model časem mysql bez nostalgie zbavili. A určitě bychom nebyli sami :)

[l0gik]

Ale to už je jiné zadání. Jeden absolutně preferovaný telefon je něco jiného než deset telefonů preferovaných pro různé operátory, nebo pro různé skupiny atd.

Může být třeba požadováno, aby daný člověk na "preferovaném telefonu" byl vždy a rychle k zastižení a proto to prostě musí být právě jeden telefon. Tvůj případ je prostě jiné zadání, které by se řešilo jinak.

A případů, kdy je vazba 1:n a zpětná 1:1 je spousta, namátkou mě napadá server má doménová jména ale právě jedno vrátí jako reverzní záznam, člověk má v systému více rolí, ale právě pracuje jako daná role a při přihlášení je jedna role nastavená standardně, okno prohlížeče má mnoho záložek a jen jedna je na vrchu atd...

Mohu to vyřešit jako 1:N závislost a ošetřit triggerama, že tam bude jedinečnost, ale proč bych to dělal. Je to daleko více práce, než to udělat 1:1 - a kdyby se náhodou jedinečnost přestala požadovat, tak doplnit možnost 1:m.

[dustin]

Toto už jsou dobré příklady :) Samozřejmě že tak jsou jsou nejdou přímo uložit do mysql/innodb.

Naštěstí jsem nikdy neměl potřebu do relační db zachycovat přesně aktuální realitu - viz výše

[dad]

mohl byste to nejak rozvest, to s timi telefony. Nejak tak intuitivne tusim, ze se dostavame k jadru problemu. Ze totiz ti analytici, kteri to delaji 'spravne', potrebuji pgsql. A ti ostatni, ti si vystaci s trochu plossi strukturou a mysql

Jak je to tedy s temi telefony?

[pavlix]

Ze totiz ti analytici, kteri to delaji 'spravne', potrebuji pgsql. A ti ostatni, ti si vystaci s trochu plossi strukturou a mysql

Nemám ponětí, kde jsi k tomuhle kecu přišel.

[l0gik]

Ne, to tušíš špatně. Princip je ten, že postgresql nabízí širší škálu vyjadřovacích prostředků a tak to, co v ní člověk chce vyjádřit musí méně přizpůsobovat databázi, než u mysql. A to s sebou nese méně práce a menší riziko chyb.

Jak je to s telefony jsem odpovídal výš: buď chci jeden a vím, že chci jeden, nebo jich chci víc... anebo chci jeden a potenciálně víc. To jsou tři různé případy a není důvod je řešit stejně. Pokud mě k tomu databáze nutí, pokládám to za její chybu.

[l0gik]

Viz Tiger: protože to nezaručuje integritu dat, jak budeš vynucovat právě jeden preferovaný telefon? Ne teda že by to nešlo...

Co se týče výkonu, tak postgresql rozhodně není řádově horší než mysql. A málokterá aplikace je natolik výkonově kritická, že by byl primárním požadavkem rychlost (pokud se nejedná o rozdíl rychlosti v řádech). Daleko větším nákladem než druhý procesor je dneska práce programátora a troufám si tvrdit, že v postgresql je díky dodržování standardů a větší škále podporovaných operací vývoj rychlejší.

Ano, je možné, že Tvoje aplikace je stejně vhodnější na MySQL. Takový případ ale dnes není příliš častý.

[dustin]

Dovolím si tvrdit, že u webových aplikací je a stále bude jedním z klíčových kritérií rychlost odezvy. A tehdy byl rozdíl rozhodně více než řád.

Jiná DB by nám určitě neuspořila čas vývojářů. Ti se věnují byznys vrstvě, úpravám i opravám stávajících funkcionalit dle požadavků klientů, vývojem nových funkcí aplikací, které si vyžaduje stále se měnící trh. Vlastní db backend (konverze relační struktury db na objektový model, přístupová práva plus pomocné služby) prostě roky funguje a není potřeba se v tom pořád vrtat. A nemyslím si, že v tomto bychom byli mezi webovými firmami nějak specifičtí a těch není zrovna málo.

[Filip Jirsák]

Engine je součástí definice tabulky, takže nevidím důvod, proč by to někdy mělo fungovat a někdy ne.

Když si zvolím na začátku určitý engine, tak to fungovat nebude. Takže obecně v MySQL to někdy funguje a někdy ne.

[dustin]

A proč bych si na začátku volil engine, který to neumí?? Nechápu smysl té argumentace, pokud nemá jít jen o hru se slovíčky.

[pavlix]

Popravdě řečeno, až MySQL nemám z podobných důvodů rád, tak Jirsákově argumentaci taky moc nerozumím.

[Filip Jirsák]

Jste mimo téma. Prostě tvrzení, že MySQL vždy a za všech okolností podporuje cizí klíče, není pravdivé. Tečka. Nic na tom nemění fakt, že existují způsoby, jak takové omezení obejít.

[dustin]

?? To tu někdo tvrdil? Ba dokonce to bylo tématem, že jsem mimo téma? Sorry, ale hra se slovíčky ničemu nepřispívá, to je pak planá diskuse pro diskusi.

[Filip Jirsák]

Na začátku byl dotaz, které věci MySQL plně podporuje. A někoho zdá se stále udivuje, že v MySQL cizí klíče v některých případech nefungují.

[dustin]

?? A koho konkrétně? Nikoho jsem v této diskusi nezaregistroval, že by tvrdil takovou blbost, "že MySQL vždy a za všech okolností podporuje cizí klíče".

[Filip Jirsák]

Byl to dotaz Šangala, který se ptal, kterou ze jmenovaných věcí MySQL neumožňuje. Takže jsem napsal, že třeba cizí klíče jsou jednou z vlastností, která v MySQL nefunguje za všech okolností. Nevím, co vás na tom pořád tak udivuje.

[dustin]

Hmm, takže jenom hra se slovíčky "za všech okolností", které sis tam navíc přidal sám. Neznám praktickou situaci, která by byla postavená na "za všech okolností". Taková debata je o ničem.

[Filip Jirsák]

Za všech okolností není žádná hra. Vlastnost, která funguje jenom někdy, a musím kvůli jejímu použití hledat přesné podmínky v dokumentaci a pak na ně pořád myslet, se nepoužívá zrovna snadno a bývá zdrojem mnoha problémů. A tady se bavíme právě o praktickém využití, ne o tom, co která databáze za nějakých specifických podmínek také ještě ustojí.

[Šangala]

To je ale přece vlastnost MySQL, můžete si zvolit typ tabulky, to je právě o tom, že to co používáte musíte znát.
To, že má PostgreSQL jen jeden, může být naopak plus pro MySQL.

[pavlix]

To, že má PostgreSQL jen jeden, může být naopak plus pro MySQL. To, že má PostgreSQL jen jeden, může být naopak plus pro MySQL.

Teoreticky to může být plus, ale v praxi bych řekl, že není. Naopak bych řekl, že je to velký plus pro PostgreSQL, kde všechny vlastnosti fungují. Na MySQL fungují některé vlastnosti v jenom engine, jiné v jiném.

Takovýhle zmatek musí mít hodně velké opodstatnění a musí být vyvážen nějakou klíčovou výhodou. Já o žádné takové nevím.

[Filip Jirsák]

To se hodí tak maximálně do srovnávacích tabulek. Pro každou vlastnost má MySQL nějaký engine, který při správné konstelaci hvězd danou vlastnost nějak podporuje. V praxi se ale pro jednu databázi použije jeden engine, a pak se ta omezení najednou objeví.

[dustin]

Právě proto, že se engine definuje přímo v create table, není problém míchat innodb a myisam. Na datový model používáme innodb, na tabulky s desítkami/stovkami miliónů řádků - statistiky, logy atd, kde nechceme referenční integritu (naopak potřebujeme zachovat kompletní historii) používáme myisam. Důvod je jednoduchý - innodb je jeden soubor a není důvod jej dále nafukovat, když to není nutné. I tak má desítky gigabytů, na devel stroji s více databázemi vývojářů měl i stovky (nedávno jsme pro každého vývojáře vytvořili vlastní instanci mysql).

Neříkám, že se to tak běžně dělá, ale praxe bývá rozmanitá.

[Heron]

Jen poznámka, innodb nemusí být nutně jeden soubor. Může to být podobně jako pro MyISAM co tabulka to soubor. Ale má to své ale.

[Filip Jirsák]

Jak při kombinování enginů fungují optimalizace, indexy atd.? Nechová se to pak spíš jako dvě oddělené databáze?

[dustin]

Jen pro upřesnění, na začátku byl dotaz:

Používáte cizí klíče na MySQL a nikdy vás to nevypeklo, nebo jste raději přešli na Postgres a tam jde realizovat (samozřejmě s malými úpravami) všechno jako na MySQL stejně rychle?

To je topic, tazateli naprosto jeho otázku rozumím, je zcela ze života a snažím se mu na ni dát naše konkrétní zkušenosti. Teoretické debaty a hry se slovíčky tazateli nijak nepomůžou. Tak asi tak

[l0gik]

Zas tak silně bych to netvrdil, všechno todle jde zajistit nějak v mysql, byť třeba na aplikační úrovni. Jen v postgresql to jde jednodušeji a s menším rizikem chyby.

[Filip Jirsák]

Na aplikační úrovni ale není v MySQL.

[l0gik]

Ale ta implikace, že použití mysql vede k degradaci dat neplatí, konzistenci lze zajistit i při použití mysql (byť ne za pomocí mysql). Vždy se musí hodnit použité technologie jako celek, vytrhnout jen mysql nemá smysl. S postgresql by sis taky moc neškrtnul, kdybys používal jen psql klienta (byť narozdíl od mysql bych si i dokázal představit aplikaci nad ním postavenou).

[Filip Jirsák]

Tady se ale řeší databáze. Takže argumenty o tom, co jde udělat mimo databázi, jsou mimo. Pokud chci do úložiště ukládat strukturovaná data, použiju úložiště, které umí ukládat strukturovaná data. Když budu chtít použít úložiště pro nestrukturovaná data, použiju to. Ale říkat, že chci použít úložiště pro strukturovaná data, tak použiju to pro nestrukturovaná a strukturovanost zařídím v aplikaci je trochu zvláštní.

[l0gik]

To bys pak mohl říkat, že stored procdures v postgresql také není databáze, také to jsou externí jazykové moduly do postgresql přidané. Stejně tak fulltext a hromada dalších věcí. Nehledě o samotnejch datech, který tam vždycky leje někdo zvenku.

Samzořejmě, můžeš si honit triko a řešit, co ještě je a není databáze a dělat nějaký umělý rozdělení, ale člověka při výběru technologie nezajímá, jestli se tomudle ještě říká nebo neříká databáze, ale jak je to použitelný. Tento spor začal u toho, že někdo tvrdil, že použití Mysql znamená ztrátu konzistence dat. Což je lapidárně řečeno blbina. V MySQL se konzistence udržuje hůře, ale jde to.

[Filip Jirsák]

To samé můžete říct o textových souborech. Přesto podle mne má smysl uvažovat o tom, jestli chci data ukládat do textového souboru, MySQL nebo jiné SQL databáze – protože „jde to“ ve všech případech, ale pokaždé jinak.

[pavlix]

Vždyť on taky nic jiného netvrdí.

[l0gik]

Pokud píšu takovoudle specializovanou aplikaci, u postgresql není problém si dopsat i jedno či dvoubajtový integer, klidně unsigned či naopak celý záporný Takže vyšší datový typ dopisovat netřeba, jen je třeba znát postgresql .

Jinak ano, na některé věci se hodí MySQL lépe. Jsou to většinou ale netypické nasazení databáze a nejsou tedy ani příliš časté.

[Šangala]

„u postgresql není problém si dopsat i jedno či dvoubajtový integer“

Jak? (seriózní otázka)

PS: pro někoho „specializovaná“ pro někoho „běžná“ aplikace

[l0gik]

http://www.postgresql.org/docs/8.2/static/sql-createtype.html

[Šangala]

A to vyřeší problém unsigned int-ů?

[l0gik]

Proč by nevyřešilo? Můžu si napsat jakej chci typ, proč bych si nenapsal unsigned integer. Pokud budu chtít, můžu si nad nima nadefinovat i operátory a všechno ostatní....

[okbob]

on uz takovy modul existuje - staci je jen prelozit

http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/uint/uint/

[Šangala]

No to už je zajímavější o to jsem se kdysi dávno snažil a dokonce i částečně s úspěchem, ale to mělo PostgreSql ještě 7 na začátku a dělalo se to trochu jinak (nebo aspoň já jsem to děla jinak, už je to dávno a možná bych někde vyhrabal zdrojáky pro uint32).
A skončil jsem s tím, že já to mám používat a když chci aby to fungovalo neměl bych se v tom vrtat , ale jinak, že je to super, že lze specializované typy takto vytvořit.
Každopádně je to pro mně dobrá zpráva, mám ve výhledu něco kde by se mě uint16 a uint32 vyplatil - škoda, že to tam není ve std. instalaci.

[Heron]

„MySql má unsigned (8/16/24/32/64 bit) INT-y.“

A má k tomu i příslušné funkce a operátory?

„MySql obvykle zabere na disku méně místa.“

Toto je z části pravda a silně to záleží na verzi PostgreSQL se kterou se to srovnává. Nejdřív se komprimovala komprimovatelná data (tuples) nad 2kB, potom se komprimovala všechna data nad 2kB a v dnešní verzi (9.0) už je transparentní komprimace všech datových souborů. Takže výsledná data mohou být na disku menší. Ale toto bych řekl u výběru databázového stroje hraje dost minoritní roli.

[okbob]

Pokud se používají typy s fixní délkou, tak MySQL s MyISAM zabere vždy méně - InnoDB naopak může zabrat více - tam už je to o dost složitější.

TOAST - komprimace se vztahuje vždy na konkrétní položky, nikdy ne na celý řádek a navíc je navázána pouze na typy s variabilní délkou. K tomu má PostgreSQL ještě režii 24 byte na řádek. Tudíž nejhorší možný případ pro Pg jsou úzké (3-sloupcové) dlouhé tabulky - časové řady klasicky uložené. Tam má pg jednak velkou režii a jednak se nepoužije TOAST.

Časové řady se ovšem mohou implementovat pomocí pole - kde se poměrově minimalizuje režie hlavičky a kde se velice dobře chytá TOAST. Tam pak mohou být data v pg řádově kratší. Transparentní komprimaci datových souborů v PostgreSQL určitě nenajdete a to ani v 9.0 :).

Pavel

[Heron]

Pokud se používají typy s fixní délkou, tak MySQL s MyISAM zabere vždy méně - InnoDB naopak může zabrat více - tam už je to o dost složitější.

Jenže u MyISAM zase člověk přijde o další funkcionalitu. Mělo by se srovnávat srovnatelné (což je dost těžké).

Jsem ještě přemýšlel -- a tady si fakt nejsem jistý jestli šlo o PostgreSQL nebo o něco jiného -- nešlo by také poladit něco jako "page fill ratio", tedy parametr, nakolik se má daná stránka zaplnit a kolik nechat volného místa? Při modifikaci by se musela alokovat nová stránka, ale při použití jako archiv (řádky se nebudou měnit) by to mohlo něco uspořit.

Transparentní komprimaci datových souborů v PostgreSQL určitě nenajdete a to ani v 9.0 :).

Díky za opravu, až moc jsem si to zjednodušil, tou transparentní komprimací jsem myslel komprimaci toustovaných položek.

[okbob]

Jasne, ze to neni porovnatelne, navic velikost db neni dneska ten nejdulezitejsi faktor - minimalne u zakazniku a uzivatelu, s kterymi se bezne setkavam - kde jsou db do 200,300G - a pokud jsou vetsi, tak je to diky blobum - kde pg muze trochu pomoci diky kompresi.

Jinak neco jako page fill ratio tam je (fillfactor), ale funguje to trochu jinak - muzete nastavit vyuziti stranky pro INSERTY - zbytek se pouzije pro UPDATE viz http://www.postgresql.org/docs/9.0/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS

v podstate, kdyby se melo usporit misto, tak by bylo vyhodnejsi prevest tabulku na pole kompozitnich typu - trochu by se tim dal i resit partitioning. Ale pokud vim, tak se to moc nedela.

[Šangala]

Ano má k tomu operátory, jak jinak by se s tím pracovalo?…

Nemám otestované nejnovější MySQL ani PostgreSql ale s PostgeSql 8.4 jsem měl i více než dvojnásobná data ze stejným výkonem jako MySQL s InnoDB.
Nechápejte to špatně, já jen poukazuji na to, že se můžete setkat i s jinými kritérii pro výběr DB, než s kterými se se setkáváte při využití v IS apod.

[razor]

Né že bych považoval MySQL za super DB ale s něčím nesouhlasím:

• varchar neořezává explicitně uvedený mezery
• defaultní hodnota timestamp - pravda, ale to je právě vlastnost, proč ten datový typ existuje. Pokud to nechceš, používej DATETIME, který má defaultní hodnotu null
• fulltext - pravda. Ale zastávám názor, že fulltext je lepší dělat pomocí specializovanýho SW. S MySQL se dobře doplňuje třeba SPHINX, který může sloužit i jako mysql storage engine.

[l0gik]

- s varcharem máš pravdu, to už opravili. - ad DATETIME - ale tam zas nemám možnost nastavit defaultní hodnotu DEFAULT CURRENT TIMESTAMP. Typická mysqlovina: de všechno, ale ne všechno najednou. - ad fulltext, jak na co. Na malej ti integrovanej stačí. Externí - aspoň co vím - např. nemaj podporu transakcí.

[pavlix]

Postgresql je vyborna databaze, ale vyzaduje mnohem hlubsi znalosti nez mysql. Pokud nemate nikoho kdo takove zkusenosti a znalosti ma, zustante u mysql.

Moje zkušenost s potřebou znalostí a zkušeností je opačná. Na PostgreSQL je spousta věcí samozřejmostí, co se na MySQL musejí těžce vylaďovat.

Jeden triviální příklad za všechny jsou transakce, základní schopnost všech slušných relačních databází. Na MySQL by default nefungují, na PostgreSQL ano.

[Senior Database Programmer]

Mne v MySQL transakcie defaultne funguju, asi mas v distribucii nejaku staru verziu MySQL.

[stativ]

MySQL AFAIK stále defaultně používá MyISAM engine, který transakce nepodporuje. Pokud chceš transakce, musíš explicitně říct, že chceš InnoDB.

[Senior Database Programmer]

Nie, od verzie 5.5 defaultne pouziva InnoDB:

InnoDB as the Default MySQL Storage Engine

[stativ]

Že bylo na čase…

[Heron]

Také záleží na distribuci MySQL. Balíček pro Windows má InnoDB jako default už hodně dlouho. A Linuxové distribuce to mohou nastavovat různě (i když jsem se setkal výhradně s default MyISAM).

[pavlix]

Mne v MySQL transakcie defaultne funguju, asi mas v distribucii nejaku staru verziu MySQL.

Spíš jsem MySQL přestal používat několik let předtím, než toto dotáhli. Fajn, že se tak stalo, ale (nadšeného) uživatele MySQL už ze mě asi neudělají.

Mimochodem, už MySQL umí autentizovat aplikace jinak než heslem napsaným přímo do zdrojáků? To by byl taky adept na vylepšení MySQL.

Každopádně díky za (pro mě) novou informaci.

[Senior Database Programmer]

Pozor na to! Mozno sa tym nadsenym uzivatelom stanete. InnoDB engine (to je vyhoda MySQL ze moze pouzivat rozne enginy, to postgresql nema!) docela dost vylepsuje Google. Co som videl nejake benchmarky tak vykon uz bol porovnatelny s PostgreSQL takze uz neplati ani oblubena fraza ze postgresql je vykonnejsia v zlozitejsich dotazoch.

[okbob]

V PostgreSQL je sice jenom jeden engine, ale zato udelany poradne a integrovany do systemu. V MySQL jich existuje cca do 20, ale cast jich jsou prototypy nebo vysoce specializovane. Kdyz se podivate na zmeny v 5.6, tak jsou to z velke casti zmeny k klasictejsimu pojeti db - persistentni podrobnejsi statistiky, optimalizace poddotazu, atd. .. ale stale tam napr. chybi hashjoin, hashagg - takze v rade dotazu dostane MySQL na frak jeste hodne dlouho.

Je pravdepodobne, ze rychlost obou db bude konvergovat v necem a na nekterych platformach. Brzdou je disk a pamet. V kazdem pripade ale PostgreSQL bude nabizet vetsi komfort - o ktery ovsem kazdy nemusi stat.

[pavlix]

Pozor na to! Mozno sa tym nadsenym uzivatelom stanete.

Málokdy se vracím k software, který jsem kvůli jeho nedostatečnosti opustil. Takže velmi pochybuju.

to je vyhoda MySQL ze moze pouzivat rozne enginy, to postgresql nema!

Já v tom žádnou výhodu nevidím.