MariaDB 5.1 RC - fork MySQL s enginem XtraDB (diskuse)

[multi]

tak snad ted uz to bude OK

[prandtlova trubice]

MariaDB obsahuje zejmena Maria storage, ktera je transakcni a ma nahradit myisam.

P.S. 'MariaDB je konecna pro postgresql'

[xm]

Maria zatím ještě není transakční, pouze crash-safe a atomická (nejde udělat rollback). Nicméně v budoucnu by měla být rozšířena na plně transakční.

[xm]

Nicméně kažopádně oproti staré MyISAM je hodně vylepšená

[okbob]

Nikde jsem neslyšel, že by Maria engine měl být transakční - od toho měli Falcon. Maria je pouze crash safe.

[xm]

Viz FAQ:

Why do you use the TRANSACTIONAL keyword now when Maria is not yet transactional?

In the current development phase Maria tables created with TRANSACTIONAL=1 are crashsafe and atomic but not transactional because changes in Maria tables can't be rolled back with the ROLLBACK command. As we will make Maria tables fully transactional in a relatively short time frame we think it's better to use the TRANSACTIONAL keyword now so that applications don't need to be changed later.

Tables marked with TRANSACTIONAL=1 will gain more transactional features with each Maria release. We expect these tables to be fully transactional (in the traditional sense) when we reach Maria 2.0.

Takže ano, v budoucnu by Maria opravdu měla podporovat transakce.

[okbob]

ok

[Lord]

Současná verze je 1.0.6-9 a transakční verze je plánována pro 2.0? A za kolik let tedy budou ty transakce k dispozici?

[JoHnY2]

To zalezi jen na tom, kolik sezenou lidi a jak budou cislovat.

[student007]

ja vim, ze se tu tu diskutovalo (a nejen na abclinuxu) jiz milionkrat, ale presto mam pocit, ze se to s temi transakcemi u aplikaci stavicich na databazich mino tu velkou trojku (mssql, oracle, db2) trochu prehani.

Myslim si, ze by to bylo dobre tema pro tu konferenci co ted brzo bude v Praze. Jako tema by se podle me hodilo:

- jak transakce nepomohou pri soubehu (viz root clanek)

- jak nikdo neprogramuje opakovani transakci v programech

- cirkus v male firme pri vypadku a nasledne recovery

- rozdily ve skladove inventure pri pouzivane a nebo nepouzivani transakci

[Filip Jirsák]

Transakce jsou důležité pro zachování konzistence dat. K tomu nepotřebujete v programech transakce opakovat, stačí „jen“ správně označovat začátky a konce transakcí. Ono asi ani u pouhého webového diskusního fóra by uživatelé nebyli zrovna nadšeni, kdyby systém ztrácel komentář jenom proto, že dva uživatelé vloží komentář ve stejnou dobu – a už jenom k takovéhle prkotině potřebujete nějakou formu transakcí.

[xm]

Na klasické vkládání komentářů třeba zrovna transakce (v SQLkovém smyslu START TRANSACTION / COMMIT) rozhodně potřeba nejsou, minimálně tedy v MyISAM tabulkách ne.

[Heron]

Obávám se, že aby se toto dalo tvrdit, muselo by se znát konkrétní schéma. Ne vždy je nový komentář otázkou jednoho insertu s autocommitem.

[xm]

Tak samozřejmě dovedu si představit schémata kdy by byly transakce potřeba i na blbé přidání komentáře, ale něco takového rozhodně není na webu obvyklé.

[Filip Jirsák]

Typicky pro komentáře budete potřebovat jednoznačné identifikátory, to je první stupeň. Pak by bylo dobré pohlídat si, aby při smazání objektu nebo uživatele se smazaly i související komentáře, a aby nešlo vkládat komentáře k neexistujícím objektům nebo uživatelům. K tomu transakce potřebujete – a nezáleží na tom, zda explicitně programátorem řízené, nebo zda si je databáze spravuje interně sama.

[xm]

Typicky pro komentáře budete potřebovat jednoznačné identifikátory, ...

Od toho mám (nejen) v MySQL funkci AUTO_INCREMENT Snad téměř každá RDBM má na tohle nějakou funkci.

..., nebo zda si je databáze spravuje interně sama.

Proto jsem také uvedl to "v SQLkovém smyslu START TRANSACTION / COMMIT".

[Filip Jirsák]

Od toho mám (nejen) v MySQL funkci AUTO_INCREMENT

A ta funkce dělá něco jiného, než že operaci získání aktuální hodnoty, přičtení jedničky a uložení a navrácení upravené hodnoty provede buď celou nebo vůbec a bez ovlivnění jinými souběžně probíhajícími operacemi? Tedy přesně to, co dělají transakce? Transakce není jenom to, co programátor jako transakci explicitně označí.

[xm]

Tak ještě jednou:

Proto jsem také uvedl to "v SQLkovém smyslu START TRANSACTION / COMMIT".

[Filip Jirsák]

A jaký má to vaše tvrzení smysl v kontextu celého vlákna? Tvrzení, že i ty nejjednodušší aplikace potřebují transakční chování těžko můžete vyvracet tím, že ale nepotřebují jeden konkrétní typ transakcí.

[okbob]

No v MyISAM tedy rozhodně Vám jsou na ... MyISAM transakce nepodporuje - takže BEGIN, COMMIT jsou tiše ignorovány.

[xm]

Heh, tvrdím snad někde něco jiného? Jen říkám, že v klasických příkladech webových aplikací se člověk bez SQL transakcí často obejde, že i ta MyISAM na spoustu věcí bohatě stačí.

[okbob]

To už jsem slyšel tolikrát, a pak mi plakali na rameni, jak jim mizejí a objevují položky na skladě.

[xm]

Také neříkám všude, jsou věci kde jsou transakce k nezaplacení (a od toho máme v MySQL InnoDB tabulky, že ). Ale osobně jsem se ještě v praxi s případem, kde by použití MyISAM (tedy bez transakcí) vedlo k nekonzistencím v databázi, nesetkal.

[okbob]

Znám dva velké weby, které jedou na MyISAM. Jeden už je vyladěný - v podstatě do backendu se nešahá - běží to už hodně let. Druhý asi běží taky, nicméně startup byl katastrofa. Problém není v samotných technologiích, ale v rukách. Vynechme weby, kde o nic nejde - kdo může rozhodnout o tom, jestli transakční podpora je důležitá nebo nikoliv? Ten, kdo transakcím nerozumí?

[Filip Jirsák]

To tvrdíte kde? Já jsem zaznamenal jenom vaše tvrzení, že se obejde bez explicitního řízení transakcí příkazy BEGIN TRANSACTION, COMMIT a ROLLBACK.

[Heron]

K tomu nepotřebujete v programech transakce opakovat, stačí „jen“ správně označovat začátky a konce transakcí.

Tím opakováním zřejmě myslel situaci, kdy transakce na DB selže.

[Filip Jirsák]

Já taky. Jenže v normálních případech není důvod, proč by měla transakce selhat – v případě konkurenčního přístupu se prostě jen operace seřadí za sebe. Pokud dojde k neplánovanému přerušení transakce, je to chyba jako jakákoli jiná a není důvod myslet si, že se to pouhým opakováním spraví (ne vše funguje jako Windows) – takže je na místě informovat uživatele a vrátit jej do předchozího stavu (což může být třeba formulář s vyplněnými údaji, o opakování akce pak může rozhodnout sám uživatel). Pokud transakce selže plánovaně (např. kvůli souběžným úpravám více uživateli), opakování transakce také nepomůže a je opět potřeba, aby o tom rozhodl uživatel.

[xm]

Součástí MariaDB 5.1 je storage engine Maria verze 1.5, netuším jak jste došel k tomu 1.0.6. To není od té verze 2.0 zas tak daleko (a jednotlivé transakční funkce mají přibývat průběžně, 2.0 je jen vodítko kdy má být uplně vše co se týče transakcí hotovo).

[Ladicek]

Ten Falcon mě mrzí, před pár týdny jsem se snažil zjistit, jestli to pořád žije a došel jsem akorát k tomu, že poslední příspěvky na mailing listu i poslední commity v repu jsou z loňského července. Nemá někdo nějaké "insider info"?

[okbob]

Z toho co se dostalo ven, to vypadá asi následovně:

S Falconem to vypadá špatně - poté co Jim Starkey odešel, byl odejit z MySQL. Na Falconu postavená verze 6.0 byla zrušena. Řadu pokročilých featur plánovaných v 6.0 vydali v neplánované verzi 5.4 inženýři Sunu - poté co většina původních zaměstnanců MySQL odešla. Někteří z vývojářů Sunu pracující na MySQL odešli ze Sunu. Pokračuje vývoj na odlehčené verzi MySQL (drizle) - nicméně nikdo neví jak - a v Sunu se stále propouští.

[Ladicek]

Jo jo, to plus mínus vím. Taky jsem zkoušel hledat, jestli se třeba nepřipravuje začlenění Falconu do Drizzle, ale vypadalo to, že kvůli jeho "nedokončenosti" nikoliv. Teď jsem teda našel tohle, takže možná si s tím někdo pořád ještě hraje

[Hlípa]

Mel bych par upresneni. Jednak podle mych informacich Jim Starkey odesel sam, stejne tak jako Monty a Marten. Verze 5.4 vysla, neb bylo treba zafixovat radu veci a zaintegrovat patche (napr. od googlu), na ktere MySQL pred koupi SUNem kaslalo. Proto vznikla verze 5.4, ktera jeste neni GA, ale resi radu problemu. Jednoduse receno je treba uklidit binec, ktery v developmentu MySQL byl a jeste je po panovi, ktery si ted vsude stezuje.

Co se tyce odchodu, tak rada lidi z MySQL tymu odesla k Montymu, ale rada jich zustala a nadale pracuji na novych vlastnostech. Navic do tymu pribyli lide, kteri pracovali na High Avalability DB a JavaDB. Takze bych to tak drasticky nevidel.

[xm]

To vypadá velmi zajímavě. Je to přímá (plně kompatibilní) náhrada za MySQL 5.1 a XtraDB vypadá opravdu dobře (původně InnoDB s vylepšeními od Googlu a Percony).

[prandtlova trubice]

nikde jsme nenasel, zda umi XtraDB fulltext ...

[xm]

To si nemyslím, je to pořád jen vylepšená InnoDB (s InnoDB samozřejmě zpětně kompatibilní - tzn. nemělo by být potřeba provádět žádnou migraci původních InnoDB databází).

Doporučuji ještě kouknout na PBXT storage, který je v MariaDB také obsažen. Vypadá opravdu _velmi_ zajímavě. Snad má mít i online backup. Zajímalo by mě nějaké porovnání vlastností PBXT s XtraDB...

[xm]

Btw. ještě by se hodilo, kdyby někdo z adminů ve zprávičce udělal z textu "MariaDB" odkaz na stránky.

[JoHnY2]

Pokud dokazou panove spolu s s Montym udrzovat kvalitni fork, kterej vazne nema nouzi o zajimavy featury, tak nemam nejmensi problem s jeho pouzivanim nebo nasazenim. Co si budeme povidat, MySQL ma hromady nedostatku a pokud je bude fork resit s vetsi rychlosti nebo chuti, jedine dobre.

Pro mariadb je urcite nejdulezitejsi vydat ostrej release a presvedcit aspon debian, aby mel jejich baliky v hlavnim repo.