Porovnání SQLite vs. MySQL

[pb.]

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

Příliš často se to nestávalo. Ale při tom množství instalací (několik desítek) bylo něco rozbité tak dvakrát - třikrát do měsíce.

[Reklama]

[pb.]

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

Pro toho exota, co to psal, byl "trigger" jen cizí termit. Navíc to bylo celkem zbytečné. Používal ty tabulky naprosto nezávisle na sobě.

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

Nic takového tam nebylo a nefungovalo to ani z povelové řádky.

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

Není to tam.

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

Já bych hlavně vytvořil tabulku pouze jednu a aktuální stav tahal z posledního vloženého záznamu. Autor zvolil jiný postup - prozradil na sebe, že vazby mezi tabulkami mu nic neříkají a neumí ani vybrat z tabulky poslední vložený záznam každého měřeného zařízení. Ačkoliv zvolil jiný přístup, nepovažoval bych to za zásadní závadu a s ohledem na charakter aplikace nevadila ani absence transakcí.

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í.

Tohle opravdu nevím, ale nepředpokládal bych to. Kdyby se ztratilo jedno měření, asi by se na to nikdy nepřišlo. Problém byl v tom, že od jistého okamžiku se ztrácela všechna měření pro některé zařízení.

[Filip Jirsák]

Zápisy šly jeden po druhém

To je právě u engine, který nepodporuje transakce, dost ošemetné tvrzení. V případě transakcí je „jeden po druhém“ pro všechny možné případy jasně definováno. Ale když tam transakce nemáte, „jeden po druhém“ asi znamená, že to bylo v příslušném programu za sebou – z hlediska databáze to ale může znamenat cokoli. Ono kdyby šlo „jeden po druhém“ zařídit bez transakcí, tak se s transakcemi nikdo nebude obtěžovat…

[Kit]

Já bych hlavně vytvořil tabulku pouze jednu a aktuální stav tahal z posledního vloženého záznamu. Autor zvolil jiný postup - prozradil na sebe, že vazby mezi tabulkami mu nic neříkají a neumí ani vybrat z tabulky poslední vložený záznam každého měřeného zařízení.

Mám z tohoto vlákna pocit, že jsem na podobné aplikaci dělal ze strany čtení, tedy z PHP. Na dotaz, jak se ta databáze plní, mi bylo odpovězeno, že se o to stará někdo jiný a hlavně ta data nesmím poškodit.

Aktuální stav z posledního záznamu se samozřejmě dá zjistit poměrně snadno.

[pb.]

Zápisy šly jeden po druhém

To je právě u engine, který nepodporuje transakce, dost ošemetné tvrzení. V případě transakcí je „jeden po druhém“ pro všechny možné případy jasně definováno. Ale když tam transakce nemáte, „jeden po druhém“ asi znamená, že to bylo v příslušném programu za sebou – z hlediska databáze to ale může znamenat cokoli. Ono kdyby šlo „jeden po druhém“ zařídit bez transakcí, tak se s transakcemi nikdo nebude obtěžovat…

Ano, "jeden o druhém" znamená, že to tak bylo napsané v programu. Teď zapsala program do databáze měření zařízení číslo jedna, za deset vteřin se zapsalo měření zařízení číslo dva a tak dál. Jestli to databáze zapisovala pozpátku nebo na přeskáčku, jestli si to napsala do keší, rovnou na disk nebo do svého notýsku, je myslím interní záležitostí té databáze a programu to může být naprosto ukradené. Považoval bych ale i u myisam za celkem samozřejmé, že jedna změna jednoho záznamu (update tabulka set něco where primarni_klic=1, kde klíč se vyskytuje v tabulce pouze jednou) bude atomární (tj. bude fungovat jako by byl zapnutý autocommit) a po návratu z "úspěšně" provedené operace update budu schopný přečíst naposledy zapsanou hodnotu. Při absenci transakcí nebo při autocommit odkudkoliv, při použití transakce, spolehlivého databázového stroje a vhodně nastavené isolation level pak alespoň uvnitř probíhající transakce.

[Reklama]

[pb.]

Aktuální stav z posledního záznamu se samozřejmě dá zjistit poměrně snadno.

Vyloučeno.

Důvodem pak není databáze samotná, ale lidé, kteří po MySQL sáhnou:
...
- Jak to myslíš, spojit joinem dvě tabulky?

Kód: [Vybrat]

select t1.zarizeni, t1.datum, t2.hodnota
   from (select zarizeni, max(datum) as datum
        from hodnoty
        group by zarizeni) t1, hodnoty t2
    where t1.zarizeni = t2.zarizeni and t1.datum = t2.datum;

Vidíte to? Jsou tam spojené dvě tabulky. A to dokonce tak zákeřným způsobem, že to nejsou dvě tabulky, ale jedna tabulka dvakrát.

[Pavel Stěhule]

Zápisy šly jeden po druhém

To je právě u engine, který nepodporuje transakce, dost ošemetné tvrzení. V případě transakcí je „jeden po druhém“ pro všechny možné případy jasně definováno. Ale když tam transakce nemáte, „jeden po druhém“ asi znamená, že to bylo v příslušném programu za sebou – z hlediska databáze to ale může znamenat cokoli. Ono kdyby šlo „jeden po druhém“ zařídit bez transakcí, tak se s transakcemi nikdo nebude obtěžovat…

Ano, "jeden o druhém" znamená, že to tak bylo napsané v programu. Teď zapsala program do databáze měření zařízení číslo jedna, za deset vteřin se zapsalo měření zařízení číslo dva a tak dál. Jestli to databáze zapisovala pozpátku nebo na přeskáčku, jestli si to napsala do keší, rovnou na disk nebo do svého notýsku, je myslím interní záležitostí té databáze a programu to může být naprosto ukradené. Považoval bych ale i u myisam za celkem samozřejmé, že jedna změna jednoho záznamu (update tabulka set něco where primarni_klic=1, kde klíč se vyskytuje v tabulce pouze jednou) bude atomární (tj. bude fungovat jako by byl zapnutý autocommit) a po návratu z "úspěšně" provedené operace update budu schopný přečíst naposledy zapsanou hodnotu. Při absenci transakcí nebo při autocommit odkudkoliv, při použití transakce, spolehlivého databázového stroje a vhodně nastavené isolation level pak alespoň uvnitř probíhající transakce.

To platí, že se změny povede zapsat na disk - MyISAM ale používá file systémovou cache, a v případě havárie se změny vůbec nemusí promítnout do datových souborů, nemusí se stihnout zapsat nic nebo jen něco - to už je záležitost operačního systému. Transakční systém není jen atomičnost a izolace, ale také Durabiilty -- garance, že jsou změny bezpečně zapsané - a to MyISAM také nemá.

[javaman ((]

Vy se mi snad zdáte Takže funguje to jako DB? Fakt nevím, nikdy jsem to nepotřeboval a použivali to jen webaři, které jsem potkal. Ale kdyby to nebyla DB, tak to přece nikdo nemůže vydat a ani používat, ne?

Případ havárie samozřejmě chápu, ale ten tady nikoho nezajímá.

[pb.]

To platí, že se změny povede zapsat na disk - MyISAM ale používá file systémovou cache, a v případě havárie se změny vůbec nemusí promítnout do datových souborů, nemusí se stihnout zapsat nic nebo jen něco - to už je záležitost operačního systému. Transakční systém není jen atomičnost a izolace, ale také Durabiilty -- garance, že jsou změny bezpečně zapsané - a to MyISAM také nemá.

Ano, princip ACID znám. Ta databáze ale nehavarovala. Navíc garanci, že jsou změny bezpečně zapsané, po databázi nikdo nutné nepotřeboval - nepřehazovali jsme vidlema peníze. Bohatě by stačilo, kdyby databáze fungovala dle očekávání alespoň v rámci jednoho spuštění.

[pb.]

...Takže funguje to jako DB?...

Ve statisticky významném počtu případů to o mě jako databáze fungovalo.

[javaman ((]

...Takže funguje to jako DB?...

Ve statisticky významném počtu případů to o mě jako databáze fungovalo.

Když vemu, jak málo se tam toho dělalo, tak i tak je to dost velký problém. Podle mě není možné, aby někdo vydal engine, který nefunguje. K čemu by pak byl?

[dustin]

Samozřejmě že když v jedné konexi/sešně do myisam zapíšu a příkaz proběhne v pořádku, následující čtení toho řádku už vrátí nově změněnou hodnotu. Na to samozřejmě není potřeba transakce, žádná změna pořadí příkazů neprobíhá.

[pb.]

...Takže funguje to jako DB?...

Ve statisticky významném počtu případů to o mě jako databáze fungovalo.

Když vemu, jak málo se tam toho dělalo, tak i tak je to dost velký problém. Podle mě není možné, aby někdo vydal engine, který nefunguje. K čemu by pak byl?

Nevím. Aby dal databázi MySQL punc nejrychlejší databáze?

[dustin]

Jsem naprosto přesvědčený, že pokud k tomu docházelo, bylo to jinak, než pb. popisuje.

[pb.]

Jsem naprosto přesvědčený, že pokud k tomu docházelo, bylo to jinak, než pb. popisuje.

Je možné, že to bylo v detailech jinak. Je to už asi pět let. K dispozici mám ale pořád ty zdrojáky, původní databázový server a nějaké stručné poznámky. Když k tomu došlo poprvé, byl jsem překvapený, jak je něco takového možné. Věnovat tomu nějak moc času nebylo možné, bylo potřeba především rychle oživit proud dat. Navíc to nebyla moje aplikace. Přihodilo se mi to možná desetkrát (pak mi nesedí frekvence dvakrát za měsíc - častější byly výpadky proudu a případný repair table) a i když jsem ze začátku nějaké úsilí k nalezení příčiny věnoval, rychle jsem se takové závady zbavil jednoduchým skriptem, který zrušil databázi a vytvořil ji znovu.

Incident si pamatuji díky tomu, že se několikrát zopakoval, býval jsem za něj pravidelně jebán, a taky díky tomu, že takové chování databáze mi naprosto vyrazilo dech.

Celá aplikace byla velmi špatně napsaná a nemělo smysl se jí více zabývat. Od autora jsem se dozvěděl, že jemu to funguje a vzhledem k jeho zkušenostem nebylo možné předpokládat, že by s tím byl schopný něco udělat. Celé se to přepsalo.