Porovnání SQLite vs. MySQL

[Filip Jirsák]

Aha. Tohle je ovšem nahrávka na smeč. Jinými slovy říkáte, že v MySQL není atomární a zaručený ani primitivní update, že té databázi pro to chybí některé vlastnosti.

MySQL umožňuje používat různé databázové enginy – např. MyISAM transakce nepodporuje, InnoDB je podporuje. Nevidím jediný důvod pro použití MyISAM.

[Reklama]

[javaman ((]

Aha. Tohle je ovšem nahrávka na smeč. Jinými slovy říkáte, že v MySQL není atomární a zaručený ani primitivní update, že té databázi pro to chybí některé vlastnosti.

MySQL umožňuje používat různé databázové enginy – např. MyISAM transakce nepodporuje, InnoDB je podporuje. Nevidím jediný důvod pro použití MyISAM.

Nejsem odborník na DB, protože je fakt nepoužívám, ale když je MyISAM nefunkční, tak by ho snad nikdo nepoužíval, ne? Není to celé trochu jinak?

[pb.]

Aha. Tohle je ovšem nahrávka na smeč. Jinými slovy říkáte, že v MySQL není atomární a zaručený ani primitivní update, že té databázi pro to chybí některé vlastnosti.

MySQL umožňuje používat různé databázové enginy – např. MyISAM transakce nepodporuje, InnoDB je podporuje. Nevidím jediný důvod pro použití MyISAM.

Nevím, jaký měl autor aplikace důvod pro použití myisam. Zaráží mě ale, že v té databázi je komponenta, u které se nelze spolehnout, že se provede update. Hlásil tu chybu někdo autorům? Pokud ano, proč je tam ta chyba pořád?

[Kit]

Aha. Tohle je ovšem nahrávka na smeč. Jinými slovy říkáte, že v MySQL není atomární a zaručený ani primitivní update, že té databázi pro to chybí některé vlastnosti.

MySQL umožňuje používat různé databázové enginy – např. MyISAM transakce nepodporuje, InnoDB je podporuje. Nevidím jediný důvod pro použití MyISAM.

Nevím, jaký měl autor aplikace důvod pro použití myisam. Zaráží mě ale, že v té databázi je komponenta, u které se nelze spolehnout, že se provede update. Hlásil tu chybu někdo autorům? Pokud ano, proč je tam ta chyba pořád?

MyISAM je v MySQL default. Pokud chceš jiný engine, musíš to té databázi říct. Autor aplikace to neudělal.

MyISAM má transakce. Faktem však je, že fungují jen v některých případech. Jako kdyby nefungovaly.

MyISAM se hodí například pro ukládání webových článků, příspěvků a podobných dat. Je rychlejší než InnoDB.

Autoři MyISAM nám maximálně doporučí, abychom přešli na InnoDB, protože se tím už nechtějí zabývat. Ostatně tohle doporučení zde bylo zmíněno již mnohokrát.

[pb.]

MySQL umožňuje používat různé databázové enginy – např. MyISAM transakce nepodporuje, InnoDB je podporuje. Nevidím jediný důvod pro použití MyISAM.

Nevím, jaký měl autor aplikace důvod pro použití myisam. Zaráží mě ale, že v té databázi je komponenta, u které se nelze spolehnout, že se provede update. Hlásil tu chybu někdo autorům? Pokud ano, proč je tam ta chyba pořád?

MyISAM je v MySQL default. Pokud chceš jiný engine, musíš to té databázi říct. Autor aplikace to neudělal.
...
Autoři MyISAM nám maximálně doporučí, abychom přešli na InnoDB, protože se tím už nechtějí zabývat. Ostatně tohle doporučení zde bylo zmíněno již mnohokrát.

Je tam více enginů, jako výchozí je nastavený ten s chybami a autoři už se tím nechtějí zabývat? Ale fuj! Nechce se mi věřit, že je na tom MySQL skutečně až tak špatně. Pořád bych byl ochotný věřit, že šlo o nějaké špatné sestavení v Debianu, že byl špatný driver v Perlu, ale proč by někdo nastavoval jako výchozí engine takový, který funguje špatně?

[Reklama]

[javaman ((]

Pořád bych byl ochotný věřit, že šlo o nějaké špatné sestavení v Debianu, že byl špatný driver v Perlu, ale proč by někdo nastavoval jako výchozí engine takový, který funguje špatně?

+1

[Kit]

Nevím, jaký měl autor aplikace důvod pro použití myisam. Zaráží mě ale, že v té databázi je komponenta, u které se nelze spolehnout, že se provede update. Hlásil tu chybu někdo autorům? Pokud ano, proč je tam ta chyba pořád?

MyISAM je v MySQL default. Pokud chceš jiný engine, musíš to té databázi říct. Autor aplikace to neudělal.
...
Autoři MyISAM nám maximálně doporučí, abychom přešli na InnoDB, protože se tím už nechtějí zabývat. Ostatně tohle doporučení zde bylo zmíněno již mnohokrát.

Je tam více enginů, jako výchozí je nastavený ten s chybami a autoři už se tím nechtějí zabývat? Ale fuj! Nechce se mi věřit, že je na tom MySQL skutečně až tak špatně. Pořád bych byl ochotný věřit, že šlo o nějaké špatné sestavení v Debianu, že byl špatný driver v Perlu, ale proč by někdo nastavoval jako výchozí engine takový, který funguje špatně?

To se dá snadno změnit v konfiguraci po instalaci MySQL. Jenže to dělá jen pár adminů. Je možné, že autor programu to měl u sebe v InnoDB, ale instalace u vás se provedla s tabulkami v MyISAM. V konfiguraci je také možné nastavit explicitní potvrzování transakcí, takže pokud za UPDATE chybí COMMIT, neprovede se nic. Jak je vidět, v konfiguraci se toho dá rozbít docela dost.

[Pavel Stěhule]

MySQL umožňuje používat různé databázové enginy – např. MyISAM transakce nepodporuje, InnoDB je podporuje. Nevidím jediný důvod pro použití MyISAM.

Nevím, jaký měl autor aplikace důvod pro použití myisam. Zaráží mě ale, že v té databázi je komponenta, u které se nelze spolehnout, že se provede update. Hlásil tu chybu někdo autorům? Pokud ano, proč je tam ta chyba pořád?

MyISAM je v MySQL default. Pokud chceš jiný engine, musíš to té databázi říct. Autor aplikace to neudělal.
...
Autoři MyISAM nám maximálně doporučí, abychom přešli na InnoDB, protože se tím už nechtějí zabývat. Ostatně tohle doporučení zde bylo zmíněno již mnohokrát.

Je tam více enginů, jako výchozí je nastavený ten s chybami a autoři už se tím nechtějí zabývat? Ale fuj! Nechce se mi věřit, že je na tom MySQL skutečně až tak špatně. Pořád bych byl ochotný věřit, že šlo o nějaké špatné sestavení v Debianu, že byl špatný driver v Perlu, ale proč by někdo nastavoval jako výchozí engine takový, který funguje špatně?

To, že MyISAM nepodporuje transakce není chybou - tak byl navržen - a díky tomu řada operací byla rychlá i na slabých 386kách a 486kach (taky důvod, proč se MySQL začal tak masivně používat a důvod, proč jsou některé operace na MySQL rychlé). InnoDB je snad od MySQL 4.0 ?? cca 15 let. Tuším, že posledních 5 let je i default. Tady MySQL šlo na ruku vývojářům, kteří chtěli něco rychlého. To, že nezmigrovali na InnoDB, to fakt není vina MySQL.

Tady měl a má Postgres velkou výhodu - nikdy se až tak moc nepodbízel (nikdy nebyl komerční), a mantrou nikdy nebyla rychlost, ale spolehlivost. Takže Postgres si oblíbili uživatelé, kteří upředňostňovali spolehlivost (a nepotřebovali hosting), pro ostatní webaře tu pak byl MySQL - hlavní bylo, že běží na hostinzích - a od samotné db se snažili, co nejvíc, se izolovat.

[Filip Jirsák]

Zaráží mě ale, že v té databázi je komponenta, u které se nelze spolehnout, že se provede update.

Takováhle komponenta je v každé databázi. Proto se musí kontrolovat návratové hodnoty, proto se používají transakce a proto se musí kontrolovat, zda databáze potvrdila commit. Pokud někdo použije MyISAM a neví proč, pokud někdo nepoužívá transakce, protože neví, co to je, neměl by psát databázové aplikace.

[javaman ((]

Tak jak s ní pracovat, aby to fungovalo? Nebo jak to dělali ti PHP mágové, že to šlapalo?

[pb.]

Zaráží mě ale, že v té databázi je komponenta, u které se nelze spolehnout, že se provede update.

Takováhle komponenta je v každé databázi. Proto se musí kontrolovat návratové hodnoty, proto se používají transakce a proto se musí kontrolovat, zda databáze potvrdila commit. Pokud někdo použije MyISAM a neví proč, pokud někdo nepoužívá transakce, protože neví, co to je, neměl by psát databázové aplikace.

Aplikace pracovala následovně:
- Provedla měření.
- Hodnotu insertem zapsala do jedné tabulky. Tato operace vždy prošla.
- Hodnotu pomocí update nebo insertem (poprvé, pokud byla tabulka prázdná) zapsala do jiné tabulky se statutem měřeného zařízení.
- postup se opakoval sekvenčně pro všechna zařízení.
- žádný konkurenční přístup
- přístup odjinud pouze čtení

Pokud se vyskytla chyba, bylo to vždy při update. I na povelové řádce to vypadalo asi takto:

update abc set jmeno = 'petr' where klic = 1;
Query OK, 1 row affected (0.08sec)....
select jmeno from abc where klic = 1;
Vrátilo to řetězec 'alena'.

Otázka už zde padla. Jakým způsobem používat MySQL správně tak, aby update proběhl a následný select vrátil řetězec 'petr'?

[Filip Jirsák]

Aplikace pracovala následovně:

V to popisu si protiřečíte. Píšete tam o několika zapisujících operacích, že přístup odjinud byl pouze pro čtení, a pak že tam nebyl konkurenční přístup. Pokud se tam četlo i zapisovalo, nebo se tam provádělo víc operací zápisu, byl tam konkurenční přístup.

Otázka už zde padla. Jakým způsobem používat MySQL správně tak, aby update proběhl a následný select vrátil řetězec 'petr'?

Já bych si podle toho, co zde bylo napsáno, tipnul, že se ta tabulka někdy nabořila (např. nečekaným ukončením databáze), nikdo nikdy ji pak nezkontroloval a zápisy do poškozených částí pak selhávaly.

Používat správně – použít InnoDB nebo jiný transakční engine, kontrolovat, že update proběhl, že byl potvrzen commit. Podle izolace transakcí provádět select v takové transakci, která vidí změny provedené v updatovací transakci. Monitorovat stav databáze a reagovat na případné chyby.

A pokud je to možné, použil bych spíš PostgreSQL, přeci jen je to na rozdíl od MySQL plnohodnotná databáze. Ale chápu, že pokud to má být nějaká aplikace provozovaná na levném webhostingu, je jediná možnost MySQL – platí se za to tím, že nemáte k dispozici spoustu vlastností plnohodnotných databází (i když i do MySQL se takové vlastnosti pomalu doplňují).

[javaman ((]

Tak jak jim to fungovalo? Přece nebyly všechny weby každý druhý den rozbité

[Kit]

Aplikace pracovala následovně:
- Provedla měření.
- Hodnotu insertem zapsala do jedné tabulky. Tato operace vždy prošla.
- Hodnotu pomocí update nebo insertem (poprvé, pokud byla tabulka prázdná) zapsala do jiné tabulky se statutem měřeného zařízení.
- postup se opakoval sekvenčně pro všechna zařízení.
- žádný konkurenční přístup
- přístup odjinud pouze čtení

Otázka už zde padla. Jakým způsobem používat MySQL správně tak, aby update proběhl a následný select vrátil řetězec 'petr'?

Především zde měl být použit trigger, který by po INSERTu do první tabulky provedl i modifikaci ve druhé tabulce.

Pokud programátor dal za INSERT něco jako "or die()", tak se ten UPDATE vůbec nemusel provést.

Někteří programátoři neuváženě používají slovo IMMEDIATE a vůbec netuší, že to může být zdrojem chyb.

Tyto dva příkazy (nebo tři?) měly být v transakci.

Pokud nějaký blázen při čtení zvyšuje prioritu (chce to mít rychle), tak se při souběhu vstupní data běžně ztrácejí.

[pb.]

V to popisu si protiřečíte. Píšete tam o několika zapisujících operacích, že přístup odjinud byl pouze pro čtení, a pak že tam nebyl konkurenční přístup. Pokud se tam četlo i zapisovalo, nebo se tam provádělo víc operací zápisu, byl tam konkurenční přístup.

Zápisy šly jeden po druhém, nekonkurovaly si, kadence zhruba jeden zápis za 10 sekund. Čtení bylo asynchronní zhruba jednou za pět minut, tam se čtení mohlo setkat se zápisem. Omlouvám se za špatnou formulaci.
 

Já bych si podle toho, co zde bylo napsáno, tipnul, že se ta tabulka někdy nabořila (např. nečekaným ukončením databáze), nikdo nikdy ji pak nezkontroloval a zápisy do poškozených částí pak selhávaly.

Považoval bych to za velmi pravděpodobné. Výpadky napájení byly poměrně časté. K problémům však docházelo i s docela velkým časovým odstupem (týdny od startu MySQL) a repair table či restart MySQL nepomohli.

A pokud je to možné, použil bych spíš PostgreSQL, přeci jen je to na rozdíl od MySQL plnohodnotná databáze. Ale chápu, že pokud to má být nějaká aplikace provozovaná na levném webhostingu, je jediná možnost MySQL – platí se za to tím, že nemáte k dispozici spoustu vlastností plnohodnotných databází (i když i do MySQL se takové vlastnosti pomalu doplňují).

Mě by nikdy nenapadlo použít MySQL, protože s PostgreSQL jsem jedna ruka. Nebylo to provozováno na webhostingu, ale v měřící aparatuře se záznamem do databáze na PC. Zhruba po roce byla ta aplikace přepsaná na monolitickou binárku s vlastním embedded www serverem a databází SQLite bez nutnosti nastavovat www server, databázi či jinou systémovou věc.