OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
START TRANSACTION; CREATE TABLE tabulka (ID integer primary key) ENGINE=InnoDB; INSERT INTO tabulka (ID) VALUES (5); ROLLBACK;Podle předchozích zkušeností s PostgreSQL i SQLite měla tabulka zmizet. Nezmizela. Zůstala v ní uložena všechna data. Je to chyba nebo vlastnost MySQL 5.1.37? Mám někde chybu?
Řešení dotazu:
CREATE TABLE
obsahuje i skrytý příkaz COMMIT
, který transakci ukončí. No jo, MySQL...
CREATE TABLE
nebo podobným příkazem je umístěn neviditelný COMMIT
. Víc nic.
CREATE TABLE
ukončil otevřenou transakci neviditelným příkazem COMMIT
.
To znamená, že žádná transakce pak otevřena nebyla.
Příkaz INSERT
proběhl ve vlastní lokální transakci.
Když není otevřena žádná transakce, ROLLBACK
neudělá nic. Ani nehlásí chybu.
Obecně by to snad SQL databáze měla umět.V 90letech se vypravel v IT nasledujici vtip: 'Pouzivate uz take SQL standard?' '... a ktery z nich myslite?'
db2 => update command options using c off DB20000I Příkaz UPDATE COMMAND OPTIONS byl úspěšně dokončen. db2 => create table tabulka(id integer not null primary key) DB20000I Příkaz SQL byl úspěšně dokončen. db2 => insert into tabulka(id) values(5) DB20000I Příkaz SQL byl úspěšně dokončen. db2 => rollback DB20000I Příkaz SQL byl úspěšně dokončen. db2 => select * from tabulka SQL0204N Název "MAJITEL.TABULKA" není definován. SQLSTATE=42704 db2 =>V Oracle to nejde. Tam create table udela commit.
Na druhou stranu toto je dokumentované chování.
Ač nemohu být podezírán z přehnaných sympatií k MySQL, tohle bych jí nevyčítal:
1. Transakce (předpokládám) fungují i se zapnutým autocommitem, jen se to pak chová, jako byl každý příkaz v samostatné transakci. Ono je potřeba chápat, že hlavní smysl transakcí umožnit vrátit sérii příkazů, když uděláte chybu, ale řešit kolize mezi paralelně přistupujícími klienty a umožnit i v takovém prostředí udržet integritu dat a atomicitu operací. Je potřeba si uvědomit, že ani to, co navenek vypadá jako "jeden příkaz", není obecně atomická operace, která se buď celá provede nebo celá neprovede.
2. To by mi až tak nevadilo, víc mne děsí důsledek tohoto faktu: že se transakční zpracování může týkat jen některých tabulek v databázi. Na druhou stranu, je jen na vás, jestli této možnosti využijete. Svědčí to ale o tom, že u MySQL jsou transakce pořád brány jako jakýsi bonus navíc, ne jako základní princip fungování databáze.
3. Jiné databáze (aspoň některé) umožňují necommitovat automaticky DDL příkazy, ale ani tam se nedoporučuje této možnosti systematicky využívat. Relační databáze vesměs nejsou moc stavěné na časté změny struktury a stavět aplikaci na tom, že to bude fungovat, bych se nezdráhal označit za zásadní designovou chybu.
MyISAM
částečně fungují. Když jsem otevřel transakci, vložil záznam a pak dal ROLLBACK
, záznam zmizel. Zajímavé bylo, že mezitím ten záznam byl vidět z jiných vláken, takže je to skutečně jen částečné.
Pokud dotaz není uzavřen do transakce, měl by se obalit vlastní transakcí z důvodu zachování integrity. Pokud se mi tohle chování nelíbí, mám možnost si otevřít vlastní transakci a commitovat jak to zrovna potřebuji.
2. MySQL je zajímavá různými enginy. Překvapil mě běžně podporovaný engine Archive
se svou transparentní kompresí. Na záznamy prohledávané %LIKE%
se určitě hodí lépe než ty ostatní. MyISAM
se zase hodí lépe na generování stránek, InnoDB
na transakční zpracování, Memory
na dočasné key->value tabulky.
Dokonce ten guláš může dohromady pěkně fungovat, zejména pokud vyberu pro každé použití ten správný engine. Popis zboží v e-shopu může být docela dobře v MyISAM
, ale zpracování objednávek lépe sluší InnoDB
. Transakční logy mohou být ukládány do Archive
, editování rozpracované objednávky bude rychlejší v Memory
.
Jenže, tohle nikdy nenastavíte správně.
MySQL jsem opustil po napsání této recenze dobré knihy MySQL optimalizace pro vysoký výkon.
Vysvětlím proč. Ty pluginy (engine) vypadají na první pohled jako fajn nápad. Tak jak jsi to popsal, to na papíře vypadá docela dobře. Jenže v praxi narazíš na chování typu:
- Při startu mysql serveru nenajel InnoDB (chyba v konfiguraci jeho parametrů). MySQL ovšem jede (start služby OK), do logu akorát napíše skip-innodb. Nic neindikuje chybu a co hůř, všechno funguje (zejména import obnovené zálohy). Tabulky (které jsou v záloze jako engine=innodb) se bez varování (!!!) vytvoří jako MYISAM. Příkazy jako BEGIN, COMMIT, ROLLBACK se tiše (!!!) ignorují. Data podléhají sillent corruption.
- Replikace fungují pouze s InnoDB, pouze s určitou verzí MySQL a pouze v určitém nastavení InnoDB. Jinak fungují taky, to ano. Jenže data na replice poněkud neodpovídají datům na masteru. Opět, nikde žádná chyba.
Po tomhle všem (a spoustě dalších) si řeknete, že teda dobře nastavíte InnoDB a všechno bude používat pouze tento engine. Jenže ouha, všechny diskové temporary tabulky jsou typu MYISAM. Takže fajné InnoDB, které má nastaveno 666GB paměti a jede rychle, ale jakmile se začně požadovat temporary na disku, tak je výkon zase v hajzlu. Takže začnete řešit MYISAM (kterého jste se nezbavili vs InnoDB). A to už je neřešitelné.
Takže ty engine fungují pouze tehdy, když jde o samostatné tabulky (bez referenčních vazeb, což projistotu opět umí jen InnoDB) a přistupuje k nim jeden uživatel (protože nefungují transakce a hlavně transakční izolace).
Výsledek je, že mnohem raději používám software, který dělá jen jednu věc, ale za to pořádně. To aplikační schéma, které jsi popsal, můžu krásně nahradit: *SQL jako jádro, memcached jako key-value cache a na aplikační logy třeba nějakou dokumentovou DB (podle toho, co s nimi chci dělat).
Výkon vyladím mnohem snadněji a jako bonus si můžu ty služby rozhodit na více HW.
Tiskni Sdílej: