Porovnání SQLite vs. MySQL

[pb.]

Ano. Zhruba před čtrnácti dny až dvěma měsíci. Nejméně jednou denně MySql chcípla a bylo ji třeba restartovat. V logu našel kolega rozbitou tabulku - po opravě se databáze na čas umoudřila a spadla až po několika dalších dnech. Opět pomohla oprava tabulky, než se to zase rozbilo. Takhle se to táhlo zhruba zmíněné dva měsíce. Teď je to za posledních zhruba čtrnáct dní v pořádku.

[Reklama]

[Jan Forman]

No já vám do toho nechci moc kecat, ale chcípající DB je rozhodně podivná věc.
Fakt bych někde hledal chybu a v DB enginu ať je to jakýkoliv to zrovna často nebývá.
To bude buď hardware a nebo rukama.

Ano. Zhruba před čtrnácti dny až dvěma měsíci. Nejméně jednou denně MySql chcípla a bylo ji třeba restartovat. V logu našel kolega rozbitou tabulku - po opravě se databáze na čas umoudřila a spadla až po několika dalších dnech. Opět pomohla oprava tabulky, než se to zase rozbilo. Takhle se to táhlo zhruba zmíněné dva měsíce. Teď je to za posledních zhruba čtrnáct dní v pořádku.

[Kit]

Já na SQLite oceňuji především spolehlivost a nerozbitnost. Tlačím tu databázi do různých embedded řešení, tam jsou tyhle vlastnosti k nezaplacení. Měl jsem tu smůlu kdysi používat v "krabičkách" pro sběr dat databázi MySql a při tom množství instalací to bylo prakticky furt rozbité. LAMP programátor dostal kopanec do zádele, protože neuměl nic jiného, a předělalo se to na cosi úplně jiného.

S rychlostí bych už tak spokojený nebyl. Pokud je databáze větší (stovky MB až jednotky GB), může být oživení po pádu aplikace na delší dobu. Ale to se stává poměrně zřídka.

Ještě k té rychlosti: SQLite mívá nastavenu defaultní velikost bloku na 1 KB. Zkus to změnit na velikost shodnou s velikostí clusteru v úložišti. Typicky to bývá 4 KB.

[pb.]

No já vám do toho nechci moc kecat, ale chcípající DB je rozhodně podivná věc.
Fakt bych někde hledal chybu a v DB enginu ať je to jakýkoliv to zrovna často nebývá.
To bude buď hardware a nebo rukama.

Hardware to není zcela určitě. Je to rukama. Já nesnáším tu databázi a ona nesnáší mě.

[dustin]

Mysql používáme velice intenzivně cca 15 let a nepamatuju si, že by padla. Ano, po tvrdém záseku serveru (HW) bývaly poškozené myisam tabulky (tedy následný repair table), ale ty již spoustu let nemá smysl používat. Rovněž jsem se nikdy nesetkal s nekorektním výsledkem selectu. Zvolili jsme ji, protože pgsql nám tehdy v našich benchmarcích vyšlo cca 10x pomalejší a bývalo by naše požadavky nestíhalo. Od začátku se jelo na innodb, takže klíčový požadavek referenční integrity a transakcí nabídla už tehdy. Za těch 15 let se pořád vyvíjela (např. GTIDs v replikaci, file per table, innobackupex) a nikdy nás zásadně nevypekla. Občas obnovujeme starší dumpy na testovací stroje kvůli analýze problému a např. integritní omezení vždy sedí OK. DB postupně rostla, dnes má 1000 tabulek cca 100GB. Samozřejmě se snažíme průběžně upgradovat na novější verze (MariaDB 10.X)

Mysql + innodb/xtradb má jistě své nedostatky (např. chybějící kvalitní fulltextový index), ale rozhodně není nestabilní. Samozřejmě je třeba používat enginy, které mají vývojovou prioritu a budoucnost, tedy ne myisam.

[Reklama]

[pb.]

... jsem se nikdy nesetkal s nekorektním výsledkem selectu...

create table abc (klic integer, jmeno text, hodnota integer);
insert into table abc (klic, jmeno, hodnota) values (1, 'A', 1);
insert into table abc (klic, jmeno, hodnota) values (1, 'B', 2);
select klic, jmeno, sum(hodnota) from abc group by klic;

Kterou hodnotu ve sloupci jmeno vrací náhodně vaše databáze?

[Kit]

... jsem se nikdy nesetkal s nekorektním výsledkem selectu...

create table abc (klic integer, jmeno text, hodnota integer);
insert into table abc (klic, jmeno, hodnota) values (1, 'A', 1);
insert into table abc (klic, jmeno, hodnota) values (1, 'B', 2);
select klic, jmeno, sum(hodnota) from abc group by klic;

Kterou hodnotu ve sloupci jmeno vrací náhodně vaše databáze?

Tohle je chybně napsaný dotaz, který v MySQL projde, ale jiné databáze ho prohlásí za nesmyslný. Na nekorektní dotaz je místo ohlášení chyby nekorektní výsledek.

[pb.]

MySQL jsem většinou v nějakém projektu zdědil. Jednou to byl sběr dat na několika desítkách PC (dvě malé tabulky, myisam). Nabourané tabulky byly většinou způsobené výpadkem (SQLite, která je tam teď, tím netrpí). Projevovala se mi tam ale občas ještě jiná chyba, která s výpadkem nesouvisela:

insert into abc (klic, status) values (1, 'OK');
update abc set status = 'ERROR' where klic = 1;
select status from abc where klic = 1;
Výsledek 'OK'.

Nejjdednodušší bylo databázi smazat a vytvořit znovu. Nedokázal jsem zjistit, proč to databáze dělala. Nestávalo se to často, ale při tom množství instalací bylo každou chvíli něco rozbitého.

Podruhé nějaký "redakční" systém, problémy už jsem popisoval.

Zajímavé je, že ve spoustě jiných případů o té databázi nevím, jede celé roky úplně bez problémů.

[Filip Jirsák]

insert into abc (klic, status) values (1, 'OK');
update abc set status = 'ERROR' where klic = 1;
select status from abc where klic = 1;
Výsledek 'OK'.

Nejjdednodušší bylo databázi smazat a vytvořit znovu. Nedokázal jsem zjistit, proč to databáze dělala. Nestávalo se to často, ale při tom množství instalací bylo každou chvíli něco rozbitého.

V tomhle je ale dost podstatné, jak to bylo s transakcemi, které z toho vašeho příkladu nejsou vidět. Pokud UPDATE byla jedna transakce a SELECT jiná, která běžela ještě před potvrzením té první, je to správný výsledek.

[pb.]

Tohle je chybně napsaný dotaz, který v MySQL projde, ale jiné databáze ho prohlásí za nesmyslný. Na nekorektní dotaz je místo ohlášení chyby nekorektní výsledek.

Já vím, že to je nekorektní dotaz, ale vyskytuje se dost často. Poprvé jsem to řešil v CMS made simple. Autor si nedal říct a jak debil trval na tom, že to je dobře, protože u něj to vrací data správně a s hotovým patchem mě poslal kamsi.

Po téhle frustrující zkušenosti jsem občas před instalací prolezl grepem nějaký open source projekt a nestačil se divit, jak je tato konstrukce oblíbená.

Vím, že tohle není chyba databáze, ale nebudí to ve mě přílišnou důvěru v lidi, kteří MySQL používají.

[pb.]

V tomhle je ale dost podstatné, jak to bylo s transakcemi, které z toho vašeho příkladu nejsou vidět. Pokud UPDATE byla jedna transakce a SELECT jiná, která běžela ještě před potvrzením té první, je to správný výsledek.

Žádné transakce, aplikace byla naprosto primitivní. V tabulce byla zhruba stovka záznamů, projevovalo se to pouze u některých, většinou ve skupince, třeba záznam s klíčem 45 až 49. Zbytek fungoval normálně.

[dustin]

První příklad je plně zdokumentovaná a zcela záměrná feature mysql, která jde samozřejmě vypnout https://dev.mysql.com/doc/refman/5.5/en/group-by-handling.html

S druhým příkladem jsem se nikdy nesetkal a upřímně mu moc nevěřím. Buď tam byly transakce (původní tabulka byla innodb, po nalití už byla myisam bez transakcí a rázem to začalo "fungovat"), nebo to bylo všechno úplně jinak... Mám zkušenost, že se v IT takto jednoduché záhady nevyskytují (a už vůbec ne "db mě nemá ráda"), ale vše má svůj důvod, který nemusí být na první pohled zřejmý.

[dustin]

Mimochodem ty transakce by vysvětlovaly i tu "náhodnost" - někdy se ty dva dotazy z různých stránek časově potkaly, někdy ne.

[Kit]

Kód: [Vybrat]

insert into abc (klic, status) values (1, 'OK');
update abc set status = 'ERROR' where klic = 1;
select status from abc where klic = 1;
Výsledek 'OK'.

Tady bych to viděl na neprovedený UPDATE. Je nutné po něm zjistit status a počet provedených změn. Může to být způsobeno třeba kolizí názvu s nějakým vyhrazeným slovem apod.

[pb.]

Tady bych to viděl na neprovedený UPDATE. Je nutné po něm zjistit status a počet provedených změn. Může to být způsobeno třeba kolizí názvu s nějakým vyhrazeným slovem apod.

Ten update nebyl nepovedený, databáze nehlásila vůbec žádnou chybu. Jako status se zapisovaly číselné hodnoty. Kolize názvu s vyhrazeným slovem můžu vyloučit. Ta databáze to dělala, i když jsem to zkusil přímo z povelové řádky. Transakce tam žádné nebyly, v celé databázi byly jen dvě tabulky, které spolu nesouvisely, aplikace byla velmi primitivní a nevěřím, že programátor kdy o transakcích slyšel.

Je opravdu nutné databázi kontrolovat po každé provedené změně? Zjišťovat, co se do databáze skutečně zapsalo? Nemělo by stačit zkontrolovat v aplikaci návratový kód?

Je možné, že to bylo jinak. Nikdy před tím jsem nic takového neviděl, nikdy potom taky ne. Tady se to nepravidelně objevovalo na několika desítkách instalací. Zopakovat jsem to nedokázal, opravit taky ne, jenom smazat a znovu vytvořit databázi.

Debian 6.0, i386, možná verze mysql 5.1.61.