Fórum Root.cz
Hlavní témata => Server => Téma založeno: NROP 13. 09. 2016, 15:17:06
-
Zdar,
Hledám nějaký aktualní stav použití disku a velikosti databáze u SQLite a MySQL (Jejich porovnání)
např. stejná web stránka na SQLite a MySQL
-
MySQL je lepší při častém zápisu, SQLite je lepší při častém čtení.
-
nedala by se sqlite jeste urychlit ze by se nacitala z RAMdisku? jestli ano, tak nejak vyrazne?
-
nedala by se sqlite jeste urychlit ze by se nacitala z RAMdisku? jestli ano, tak nejak vyrazne?
SQLite se dá urychlit tak, že místo na disk ukládá data přímo do RAM procesu. Často je to rychlejší, než implementace vlastních datových struktur. Pokud si nad SQLite postavíš nějaký serverový engine, např. v Pythonu, může to být velmi výkonné. Ovšem pokud si vystačíš s KVS, jako většina aplikací, stačí použít kolekce.
-
Srovnáváš nesrovnatelné, jedná se o dva zcela jinak zaměřené produkty. SQLite je víceméně jen knihovna, která pracuje s "databází", která je v jednom souboru. MySQL je už plnohodnotný DB server, kde platí klasická architektura klient-server.
Oba tyto systémy mají své výhody a nevýhody, ze kterých plyne jejich typické nasazení.
Nedává smysl "porovnání na načtení jedné stránky".
-
Srovnáváš nesrovnatelné, jedná se o dva zcela jinak zaměřené produkty. SQLite je víceméně jen knihovna, která pracuje s "databází", která je v jednom souboru. MySQL je už plnohodnotný DB server, kde platí klasická architektura klient-server.
Oba tyto systémy mají své výhody a nevýhody, ze kterých plyne jejich typické nasazení.
Nedává smysl "porovnání na načtení jedné stránky".
Takže pro běžné stránky, které z databáze převážně jen čtou, také doporučuješ SQLite?
-
Srovnáváš nesrovnatelné, jedná se o dva zcela jinak zaměřené produkty. SQLite je víceméně jen knihovna, která pracuje s "databází", která je v jednom souboru. MySQL je už plnohodnotný DB server, kde platí klasická architektura klient-server.
Oba tyto systémy mají své výhody a nevýhody, ze kterých plyne jejich typické nasazení.
Nedává smysl "porovnání na načtení jedné stránky".
Takže pro běžné stránky, které z databáze převážně jen čtou, také doporučuješ SQLite?
Moje zkušenosti s oběma databázemi říkají, že je to trochu jinak: SQLite je plnohodnotná databázová knihovna a MySQL je... ehm... takové něco, co funguje v režimu klient-server a často dokonce i vrací rozumná data na základě sql dotazu.
Především se ale obě databáze skutečně nedají srovnávat. SQLite je výborná pro embedded aplikace (firefox, android), má pouze jednovláknový přístup, je omezený rozsah datových typů, neexistují triggery, pravidla, procedury atd. Použití SQLite pro webové stránky může být problematické kvůli nemožnosti přistupovat k jedné databázi z více míst najednou.
MySQL se snaží napodobit plnohodnotné databázové servery, takže je možné číst i zapisovat z více míst najednou (typické webové stránky), můžete používat různé datové typy, naučíte se příkazy jako "repair table", užijete si nesmyslná data vrácená v "select... group by..." a naučíte se používat monitorovací systémy pro restart serveru.
Doporučuji PostgreSQL.
-
Konstruktivně: Co s tím chcete dělat?
-
Především se ale obě databáze skutečně nedají srovnávat. SQLite je výborná pro embedded aplikace (firefox, android), má pouze jednovláknový přístup, je omezený rozsah datových typů, neexistují triggery, pravidla, procedury atd. Použití SQLite pro webové stránky může být problematické kvůli nemožnosti přistupovat k jedné databázi z více míst najednou.
SQLite má triggery a transakce. Procedury se v ní dají psát také, jen se píší zcela jiným způsobem - jako procedury či funkce v hostitelském jazyce a jejich injektováním. SQLite nemá problém s vícenásobným čtením z více míst najednou. V tu samou chvíli lze z jednoho místa zapisovat. Jen si programátor každé přistupující aplikace musí dát pozor, aby pro přístup používal vždy pouze jedno vlákno. Mezi různými procesy však zámky normálně fungují.
SQLite je jednoduchou databázovou knihovnou, která si skvěle poradí s uloženými články, evidencí uživatelských přístupů, diskuzním fórem a dalšími webovými záležitostmi. Tedy tam, kde se velmi často čte, ale málo zapisuje. Je rychlá.
Pro aktivnější modifikaci dat, pokročilé datové typy a náročnější transakce bych doporučil zmíněnou databázi PostgreSQL.
-
SQLite má triggery....
Fakt že jo! SQLite používám už od verze 2 a asi to nestačím sledovat. Už včera jsem si říkal "teď už umí sqlite i referenční integritu, jak to dělá bez triggerů?"
SQLite používám hodně a rád, více než jakoukoliv jinou databázi, nicméně člověku, který se ptá, jestli je načtení stránky rychlejší v SQLite nebo v MySQL bych doporučil PostgreSQL. Nevěřím, že člověk s takovým dotazem dovede domyslet do všech detailů, co to znamená "zapisovat v jednom vláknu".
-
S přechodem SQLite na verzi 3 se pár věcí změnilo. Už umí i neblokovaný zápis (současne lze číst z více procesů). V benchmarcích mi čtení SQLite vychází podstatně rychlejší, než čtení MySQL.
PostgreSQL je ještě o něco pomalejší, ale umí toho víc. U náročných dotazů je PostgreSQL nejlepší, ale jen málo webových aplikací tento potenciál dokáže využít.
-
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.
-
Ak sa pytas na velkost datovych suborov, tak to si musis odmerat. Mysql ma rozne storage enginy a odhadoval by som, ze to ma na to vplyv. Zavisi to napr aj od indexov, ale aj od nastavenia transakcneho logu, ktory tam pri mysql musis zaratat. SQLite ma vsetko v jednom subore, pri mysql je to velkost adresara (treba tam zaratat aj technicke tabulky db). Zvazil by som aj, ze mysql ma nieco ako komprimovane tabulky a dokonca aj partitioning, ale inak by som sa mysql vyhol.
-
K velikosti SQLite: databáze si může vytvářet žurnálovací soubor, takže skutečné potřebné místo na disku může být třeba dvojnásobné proti velikosti samotného databázového souboru.
-
naučíte se příkazy jako "repair table"
delal jste nekdo nekdy tohle pri InnoDB / XtraDB ?
-
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.
-
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.
-
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.
-
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ě.
-
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.
-
... 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?
-
... 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.
-
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ů.
-
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.
-
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í.
-
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ě.
-
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ý.
-
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.
-
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.
-
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.
-
njn, takze DB te nema rada protoze nekdo napsal spatne dotazy a protoze delas select pred potvrzenim zmen a divis se, ze nevidis zmeny... omg.
-
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
Díky za informaci. Já se k MySQL dostávám jen jako "zákazník", databáze bývá součástí nějakého produktu. Na koho mám ale ukázat, když programátor říká "u mě to funguje", na webových stránkách jsou nesmysly a po pár dnech hrábání se v cizím produktu zjistím, že to je databáze, kdo s klidem schroustne nesmyslný dotaz?
-
... select pred potvrzenim zmen a divis se, ze nevidis zmeny...
Nebyly tam transakce. Nepomohlo restartovat databázi, pouze zrušit a vytvořit databázi znovu. Takto postižené záznamy na update nereagovaly a vracely vždy stejná, stará data. allah akbar, bože můj
-
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?
Psal jsem "neprovedený". Pro relační databázi není vůbec žádnou chybou, když při nesplnění podmínky žádný update neprovede. Pouze nahlásí, že změnila 0 záznamů a to je vše.
-
Psal jsem "neprovedený". Pro relační databázi není vůbec žádnou chybou, když při nesplnění podmínky žádný update neprovede. Pouze nahlásí, že změnila 0 záznamů a to je vše.
Rozumím. Měl jsem to v rukách tak pět let zpátky a předpokládám, že toho bych si asi všimnul. S databázemi dělám hodně. Navíc, jak jsem uvedl - postižené záznamy bylo možné opravit jen smazáním a obnovením databáze. Restart nepomohl. Transakce by restart asi nepřežila. Když byla databáze v tomto stavu, nebylo možné udělat update ani na povelové řádce. A tam jsem v transakci nebyl zcela určitě. Napadá mě - pokud pomohlo jen smazání a obnovení databáze, bylo vůbec možné ten postižený záznam smazat? Přiznám se, že tohle už si nepamatuju.
-
Psal jsem "neprovedený". Pro relační databázi není vůbec žádnou chybou, když při nesplnění podmínky žádný update neprovede. Pouze nahlásí, že změnila 0 záznamů a to je vše.
Rozumím. Měl jsem to v rukách tak pět let zpátky a předpokládám, že toho bych si asi všimnul. S databázemi dělám hodně. Navíc, jak jsem uvedl - postižené záznamy bylo možné opravit jen smazáním a obnovením databáze. Restart nepomohl. Transakce by restart asi nepřežila. Když byla databáze v tomto stavu, nebylo možné udělat update ani na povelové řádce. A tam jsem v transakci nebyl zcela určitě. Napadá mě - pokud pomohlo jen smazání a obnovení databáze, bylo vůbec možné ten postižený záznam smazat? Přiznám se, že tohle už si nepamatuju.
Tohle rozhodně není běžné chování MySQL. Nikdo by ji nepoužíval. Zdroj chyby může být kdekoli - od chyby HW, přes chybu konfigurace až po chybu v sestavení dotazu.
Ze kterého jazyka pocházel ten SQL dotaz? Který databázový ovladač byl použit? Byla databáze na localhostu nebo mimo?
-
Tohle rozhodně není běžné chování MySQL. Nikdo by ji nepoužíval. Zdroj chyby může být kdekoli - od chyby HW, přes chybu konfigurace až po chybu v sestavení dotazu.
Ze kterého jazyka pocházel ten SQL dotaz? Který databázový ovladač byl použit? Byla databáze na localhostu nebo mimo?
Taky si myslím, že tohle není normální. Do databáze se sypala data z perlu. Databázový ovladač... nevím - je to podstatné, když nefungoval ani update z povelové řádky? Databáze na localhost. Čtení dat z php (pouze čtení). Transakce vyloučené (myisam, programátor transakcemi netknut). Hardware bych taky vyloučil, neprojevovalo by se to na tolika strojích a po kompletním přepsání aplikace ty stroje fungují dodnes. Z dnešního pohledu odhaduji, že mohlo jít o nějaké špatné sestavení nějaké speciálně vybrané prehistorické verze MySQL v Debianu. Stálo mě to jen spoustu nervů a vysvětlování, proč by se měla aplikace zahodit a pořídit jinde (aplikace byla odpad i z mnoha jiných hledisek). Každopádně tenhle incident důkladně prohloubil moji nedůvěru v MySQL.
-
Tohle rozhodně není běžné chování MySQL. Nikdo by ji nepoužíval. Zdroj chyby může být kdekoli - od chyby HW, přes chybu konfigurace až po chybu v sestavení dotazu.
Ze kterého jazyka pocházel ten SQL dotaz? Který databázový ovladač byl použit? Byla databáze na localhostu nebo mimo?
Taky si myslím, že tohle není normální. Do databáze se sypala data z perlu. Databázový ovladač... nevím - je to podstatné, když nefungoval ani update z povelové řádky? Databáze na localhost. Čtení dat z php (pouze čtení). Transakce vyloučené (myisam, programátor transakcemi netknut). Hardware bych taky vyloučil, neprojevovalo by se to na tolika strojích a po kompletním přepsání aplikace ty stroje fungují dodnes. Z dnešního pohledu odhaduji, že mohlo jít o nějaké špatné sestavení nějaké speciálně vybrané prehistorické verze MySQL v Debianu. Stálo mě to jen spoustu nervů a vysvětlování, proč by se měla aplikace zahodit a pořídit jinde (aplikace byla odpad i z mnoha jiných hledisek). Každopádně tenhle incident důkladně prohloubil moji nedůvěru v MySQL.
Tak tohle vypadá na chybné použití databázového ovladače v Perlu. Vzpomínám si, že jsem kdysi dlouho hledal, proč mi MySQL neukládá data posílaná z Pythonu. Na vině bylo chybějící volání cursor.commit(), ačkoli jsem žádnou transakci neotevíral. Teď už to vím, protože mě to vyškolilo. Také vím, že při práci s databází se toho dá hodně pokazit.
Používání MyISAM se dnes už moc nedoporučuje, de facto k tomu ani není důvod. Vždyť ani pořádně neumí transakce. InnoDB je úplně jiný level. Nijak však nevylučuji, že se pro danou úlohu může hodit jiná databáze, např. SQLite ši PostgreSQL. Často bývá potřebný větší rozbor.
-
Tohle rozhodně není běžné chování MySQL. Nikdo by ji nepoužíval. Zdroj chyby může být kdekoli - od chyby HW, přes chybu konfigurace až po chybu v sestavení dotazu.
Ze kterého jazyka pocházel ten SQL dotaz? Který databázový ovladač byl použit? Byla databáze na localhostu nebo mimo?
Taky si myslím, že tohle není normální. Do databáze se sypala data z perlu. Databázový ovladač... nevím - je to podstatné, když nefungoval ani update z povelové řádky? Databáze na localhost. Čtení dat z php (pouze čtení). Transakce vyloučené (myisam, programátor transakcemi netknut). Hardware bych taky vyloučil, neprojevovalo by se to na tolika strojích a po kompletním přepsání aplikace ty stroje fungují dodnes. Z dnešního pohledu odhaduji, že mohlo jít o nějaké špatné sestavení nějaké speciálně vybrané prehistorické verze MySQL v Debianu. Stálo mě to jen spoustu nervů a vysvětlování, proč by se měla aplikace zahodit a pořídit jinde (aplikace byla odpad i z mnoha jiných hledisek). Každopádně tenhle incident důkladně prohloubil moji nedůvěru v MySQL.
Tak tohle vypadá na chybné použití databázového ovladače v Perlu. Vzpomínám si, že jsem kdysi dlouho hledal, proč mi MySQL neukládá data posílaná z Pythonu. Na vině bylo chybějící volání cursor.commit(), ačkoli jsem žádnou transakci neotevíral. Teď už to vím, protože mě to vyškolilo. Také vím, že při práci s databází se toho dá hodně pokazit.
Používání MyISAM se dnes už moc nedoporučuje, de facto k tomu ani není důvod. Vždyť ani pořádně neumí transakce. InnoDB je úplně jiný level. Nijak však nevylučuji, že se pro danou úlohu může hodit jiná databáze, např. SQLite ši PostgreSQL. Často bývá potřebný větší rozbor.
Jestli se používal MyISAM engine, tak není co řešit - ten transakce vůbec nepodporuje! Tudíž to, že po havárii jdou data přečíst je jen příjemná (nicméně negarantovaná) vlastnost. Fakticky netransakční engine (jako je např. MyISAM) vůbec negarantuje stav dat v případě havárie. To, že to programátoři zvesela používali, jen ukazuje jejich nevelké znalosti a nulovou odpovědnost.
-
Jestli se používal MyISAM engine, tak není co řešit - ten transakce vůbec nepodporuje! Tudíž to, že po havárii jdou data přečíst je jen příjemná (nicméně negarantovaná) vlastnost. Fakticky netransakční engine (jako je např. MyISAM) vůbec negarantuje stav dat v případě havárie. To, že to programátoři zvesela používali, jen ukazuje jejich nevelké znalosti a nulovou odpovědnost.
Firebird transakce má a u nás po havárii většinou dopadne hůř než MyISAM.
-
Jestli se používal MyISAM engine, tak není co řešit - ten transakce vůbec nepodporuje! Tudíž to, že po havárii jdou data přečíst je jen příjemná (nicméně negarantovaná) vlastnost. Fakticky netransakční engine (jako je např. MyISAM) vůbec negarantuje stav dat v případě havárie. To, že to programátoři zvesela používali, jen ukazuje jejich nevelké znalosti a nulovou odpovědnost.
Pokud server padnul a databáze nefungovala, zabralo repair table. To dokážu pochopit a netroufal bych si poukazovat na databázi. Měla tam být UPS. Ale ten problém s update neměl souvislost s pádem serveru nebo databáze. Stávalo se to typicky s uptimem dny až týdny, databáze fungovala celou tu dobu.
-
Jestli se používal MyISAM engine, tak není co řešit - ten transakce vůbec nepodporuje! Tudíž to, že po havárii jdou data přečíst je jen příjemná (nicméně negarantovaná) vlastnost. Fakticky netransakční engine (jako je např. MyISAM) vůbec negarantuje stav dat v případě havárie. To, že to programátoři zvesela používali, jen ukazuje jejich nevelké znalosti a nulovou odpovědnost.
Pokud server padnul a databáze nefungovala, zabralo repair table. To dokážu pochopit a netroufal bych si poukazovat na databázi. Měla tam být UPS. Ale ten problém s update neměl souvislost s pádem serveru nebo databáze. Stávalo se to typicky s uptimem dny až týdny, databáze fungovala celou tu dobu.
A jak ta aplikace fungovala po přehození databáze na InnoDB?
-
A jak ta aplikace fungovala po přehození databáze na InnoDB?
Ta aplikace se kompletně přepsala (byl to odpad) a teď běží na SQLite. Na InnoDB to nikdo nezkoušel.
-
... 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?
Ktory expert takto uklada data do tabulky? Ak sa stlpec nastavi ako kluc, podla ktoreho sa nasledne hladaju zaznamy, ako mozu mat 2 rozne riadky rovnaky kluc? Programator, ktory takto navrhol dizajn tabulky, je debil (to je to miernejsia nadavka).
-
Ktory expert takto uklada data do tabulky? Ak sa stlpec nastavi ako kluc, podla ktoreho sa nasledne hladaju zaznamy, ako mozu mat 2 rozne riadky rovnaky kluc? Programator, ktory takto navrhol dizajn tabulky, je debil (to je to miernejsia nadavka).
Klid. To byl příklad. Ten klíč tam, to není unikátní klíč. Představte si tu tabulku třeba takto:
create table deti_zamestnance (
osobni_cislo integer not null references zamestnanci(osobni_cislo)...,
jmeno text not null,
datum_narozeni date
);
a dotazem se počítá průměrný datum narození dětí pro různé zaměstnance.
-
Ktory expert takto uklada data do tabulky? Ak sa stlpec nastavi ako kluc, podla ktoreho sa nasledne hladaju zaznamy, ako mozu mat 2 rozne riadky rovnaky kluc? Programator, ktory takto navrhol dizajn tabulky, je debil (to je to miernejsia nadavka).
Jinak souhlas. Na adresu toho člověka, který takhle zprasil CMS made simple, padaly velmi hrubé výrazy. A ještě hrubější výrazy jsme pak používali, když hotový patch odmítnul se slovy "u mě to funguje".
-
Jestli se používal MyISAM engine, tak není co řešit - ten transakce vůbec nepodporuje! Tudíž to, že po havárii jdou data přečíst je jen příjemná (nicméně negarantovaná) vlastnost. Fakticky netransakční engine (jako je např. MyISAM) vůbec negarantuje stav dat v případě havárie. To, že to programátoři zvesela používali, jen ukazuje jejich nevelké znalosti a nulovou odpovědnost.
Firebird transakce má a u nás po havárii většinou dopadne hůř než MyISAM.
A nemáte vypnutý fsync? Pokud se fsyncuje, tak zrovna Firebird měl být ok
-
... 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?
Ktory expert takto uklada data do tabulky? Ak sa stlpec nastavi ako kluc, podla ktoreho sa nasledne hladaju zaznamy, ako mozu mat 2 rozne riadky rovnaky kluc? Programator, ktory takto navrhol dizajn tabulky, je debil (to je to miernejsia nadavka).
Ta tabulka je ok, blbec ten kdo od toho dotazu očekává něco smysluplného. Jaké jméno by to podle vás mělo vracet? To není chyba mysql ale vaší neznalosti.
-
oprava:
blbec je ten kdo od toho dotazu očekává něco smysluplného
-
Ktory expert takto uklada data do tabulky? Ak sa stlpec nastavi ako kluc, podla ktoreho sa nasledne hladaju zaznamy, ako mozu mat 2 rozne riadky rovnaky kluc? Programator, ktory takto navrhol dizajn tabulky, je debil (to je to miernejsia nadavka).
Možná ten, kdo nepotřebuje mít splněnu 3NF. Takové databáze také existují a plní svůj účel.
Kromě toho si tam SQLite automaticky přidává sloupec "rowid", který funguje jako primární klíč.
-
V Inno(xtra)db nemuzete nemit transakce. To byla s nejvetsi pravdepodobnosti proste necommitnuta transakce. Kazdy command i v shellu je v transakci. Akorat v shellu nemusite psat commit, pokud predtim rucne nenapisete begin. V ruznych knihovnach pro pristup existuji ruzne nastaveni autocommitu,pripadne "rucnich" commitu knihovny po kazdem commandu, ruzne isolation levely, atd a pak se zda, ze to funguje pokazde jinak. Neni pravda. Mysql svoje nedostatky ma, ale rozhodne ne ve vyse popsanych pripadech.
-
V Inno(xtra)db nemuzete nemit transakce. To byla s nejvetsi pravdepodobnosti proste necommitnuta transakce. Kazdy command i v shellu je v transakci. Akorat v shellu nemusite psat commit, pokud predtim rucne nenapisete begin. V ruznych knihovnach pro pristup existuji ruzne nastaveni autocommitu,pripadne "rucnich" commitu knihovny po kazdem commandu, ruzne isolation levely, atd a pak se zda, ze to funguje pokazde jinak. Neni pravda. Mysql svoje nedostatky ma, ale rozhodne ne ve vyse popsanych pripadech.
To je mi celkem jasné. Dost intenzivně používám PostgreSQL (už od dob Ingres/Postquel přes Postgres95) a tam mají tyto záležitosti poněkud delší tradici. Jen by mě nenapadlo hledat tyto problémy v aplikaci, kde byly použité dohromady čtyři primitivní SQL příkazy a žádné transakce. Dnes už je to nakonec jedno. Ta aplikace je dnes přepsaná o dvě úrovně výš.
Pokud to bylo skutečně způsobené transakcemi, je to pro mě opět důvod se MySQL raději vyhýbat. Důvodem pak není databáze samotná, ale lidé, kteří po MySQL sáhnou:
- LAMP - to M je tam MySQL, kdo kdy slyšel o LAP(ostres)P nebo LAS(qlite)P
- Volbou MySQL žádnou chybu nemůžu udělat
- Proč bych tam měl dát něco jiného, když MySQL je nejpoužívanější?
- Jak zprovozním phpmyadmin?
- Innodb? Ale to by bylo pomalé!
- Nesmyslné select... group by... v aplikacích
- U mě to funguje
- Jak to myslíš, transakce?
- Jak to myslíš, spojit joinem dvě tabulky?
- Jak zprovozním MySQL na Rpi? A proč mi to žere SD karty?
MySQL bývá pro tyto lidi první a jediná volba. Mám s podobnými aplikacemi několik hodně špatných zkušeností a pokusy o nápravu (jednání s autory) bývá natolik frustrující, že použití MySQL je pro mě jedním z prvních filtrů při výběru aplikace.
Neumím pracovat s MySQL a nechce se mi v neznámém prostředí zjišťovat, co nezkušený autor v aplikaci zeslonil. Je možné, že MySQL je dobrá databáze, ale společným jmenovatelem aplikací, se kterými jsem měl nejvíce problémů a vysvětlování zákazníkům, byla právě MySQL.
-
Jen by mě nenapadlo hledat tyto problémy v aplikaci, kde byly použité dohromady čtyři primitivní SQL příkazy a žádné transakce.
Já bych naopak přesně v takovéhle aplikaci ty problémy hledal. Protože „žádné transakce“ přesně znamená „často se ta data uloží, ale nevíme proč“, z čehož právě plyne „a někdy se také neuloží, a nevíme proč“.
-
Jen by mě nenapadlo hledat tyto problémy v aplikaci, kde byly použité dohromady čtyři primitivní SQL příkazy a žádné transakce.
Já bych naopak přesně v takovéhle aplikaci ty problémy hledal. Protože „žádné transakce“ přesně znamená „často se ta data uloží, ale nevíme proč“, z čehož právě plyne „a někdy se také neuloží, a nevíme proč“.
Jestli se používal MyISAM engine, tak není co řešit - ten transakce vůbec nepodporuje!...
Proč se tady pořád řeší transakce?
-
Proč se tady pořád řeší transakce?
Protože transakce jsou způsob, jak zajistit bezpečné uložení dat. To, že ta aplikace „nepoužívala transakce“ je tedy nejpravděpodobnější příčina toho, proč se vám to chovalo divně.
-
Proč se tady pořád řeší transakce?
Protože transakce jsou způsob, jak zajistit bezpečné uložení dat. To, že ta aplikace „nepoužívala transakce“ je tedy nejpravděpodobnější příčina toho, proč se vám to chovalo divně.
Myisam transakce nepodporuje.
-
Myisam transakce nepodporuje.
Což je nejpravděpodobnější příčina toho, proč se vám to chovalo divně.
-
Myisam transakce nepodporuje.
Což je nejpravděpodobnější příčina toho, proč se vám to chovalo divně.
Rozumím. Způsobila to nepodporovaná a nepoužitá vlastnost. Prostě divná databáze. Lépe se jí obloukem vyhnout.
-
Způsobila to nepodporovaná a nepoužitá vlastnost.
Způsobila to absence té vlastnosti.
-
Způsobila to nepodporovaná a nepoužitá vlastnost.
Způsobila to absence té vlastnosti.
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.
Ani tady nebudu psát, jaký mi z toho vychází závěr.
-
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.
-
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?
-
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?
-
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.
-
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ě?
-
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
-
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.
-
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.
-
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.
-
Tak jak s ní pracovat, aby to fungovalo? Nebo jak to dělali ti PHP mágové, že to šlapalo?
-
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'?
-
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í).
-
Tak jak jim to fungovalo? Přece nebyly všechny weby každý druhý den rozbité ::)
-
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í.
-
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.
-
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.
-
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í.
-
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…
-
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.
-
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.
-
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?
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.
-
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á.
-
Vy se mi snad zdáte :D 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á.
-
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í.
-
...Takže funguje to jako DB?...
Ve statisticky významném počtu případů to o mě jako databáze fungovalo.
-
...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?
-
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á.
-
...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?
-
Jsem naprosto přesvědčený, že pokud k tomu docházelo, bylo to jinak, než pb. popisuje.
-
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.
-
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í.
Jinde píšete, že docházelo k výpadkům proudu - je úplně jedno jestli spadne db, operační systém nebo vypadne proud - prostě havárie. MyISAM může fungovat na relativně hodně stabilním systému nebo s relativně malou frekvencí změn, kdy je dost velká šance, že už data budou fyzicky zapsaná.
-
Jinde píšete, že docházelo k výpadkům proudu - je úplně jedno jestli spadne db, operační systém nebo vypadne proud - prostě havárie. MyISAM může fungovat na relativně hodně stabilním systému nebo s relativně malou frekvencí změn, kdy je dost velká šance, že už data budou fyzicky zapsaná.
Ano. K výpadkům proudu docházelo poměrně často. Databáze se pak rozjela nebo nerozjela, pokud se nerozjela, opravit se dala pomocí repair table.
Popisovaný problém s update nesouvisel časově s tím, že by to nefungovalo po obnovení dodávky proudu. Původně jsem si to myslel, ale ukázalo se, že problém se vyskytuje až nějakou delší dobu (dny, týdny) po startu databázového serveru. Jestli byla databáze opravená nebo po havárii najela sama, to už dneska nevím.
Odhaduju, že mezi instalacemi nebyla jediná, která by neabsolvovala během jednoho měsíce alespoň jeden výpadek proudu.
-
Ano. K výpadkům proudu docházelo poměrně často. Databáze se pak rozjela nebo nerozjela, pokud se nerozjela, opravit se dala pomocí repair table.
S dnešním odstupem bych to hodnotil jako ukázkově nevhodné použití MySQL.
-
Ano. K výpadkům proudu docházelo poměrně často. Databáze se pak rozjela nebo nerozjela, pokud se nerozjela, opravit se dala pomocí repair table.
S dnešním odstupem bych to hodnotil jako ukázkově nevhodné použití MySQL.
Určitě pro MyISAM naprosto nevhodné - jinak popisovanou zátěž by zvládla každá db levou zadní.
Jinak ale výpadek proudu může dostat do kolen každou databázi - pokud nemáte dražší hw jištěný vlastní baterií, tak tu vždy máte nenulové riziko poškození filesystému. Samozřejmě, že u netransakční databáze je to horší - tam můžete přijít o data, aniž by došlo k poškození filesystému. Od počítače, kde dochází k výpadkům proudu, samovolným restartům bych vůbec nic nečekal - je jen otázkou času, kdy se filesystém natolik rozpadne, že něco důležitého bude nečitelné.
-
Tohle vlakno sleduju uz nekolik dni. Ted jsem po trech pivech, tak mam odvahu se vyjadrit. V databazovem svete jsem si prosel elevska leta, ted uz se povazuji za mirne pokrocileho, pozoroval jsem elevska leta jinych, mam slabost pro zkoumani chyb svych i jinych a nemam duvod pb neverit. Proste at uz pb pise cokoliv, tak klidne to tak nejak mohlo byt. Je to blby, ale je to tak. Vzdy plati zakladni dva Murphyho zakony: (1) V kazdem SW je chyba a (2) opravenim jedne chyby vznikaji dve dalsi.
-
Určitě pro MyISAM naprosto nevhodné - jinak popisovanou zátěž by zvládla každá db levou zadní.
Jinak ale výpadek proudu může dostat do kolen každou databázi - pokud nemáte dražší hw jištěný vlastní baterií, tak tu vždy máte nenulové riziko poškození filesystému. Samozřejmě, že u netransakční databáze je to horší - tam můžete přijít o data, aniž by došlo k poškození filesystému. Od počítače, kde dochází k výpadkům proudu, samovolným restartům bych vůbec nic nečekal - je jen otázkou času, kdy se filesystém natolik rozpadne, že něco důležitého bude nečitelné.
Teď je tam SQLite. Ze začátku byly problémy s objemem dat (dlouhý start po havárii), ale při nějakých 100 MB to nehraje roli. Jinak s databází nebyl nikdy žádný problém. Více potíží je s aplikací, která je dnes tak o dva řády složitější a možná i hardwarem (místo PC malá krabička s ARM).
-
Podle mne je zásadní problém v očekávání, že bude jakákoli databáze (ale mysql nad myisam zvlášť) fungovat dlouhodobě spolehlivě, když je nainstalovaná na PC, které nemá UPS a dochází k výpadkům proudu.
Jak je někde databáze, je napájení přes UPS základ.