PBXT storage engine pro MySQL server

Na dev.mysql.com vyšel článek o PBXT storage engine pro MySQL server. Jedná se o ACID transakční engine s podporou MVCC, referenční integrity, neomezeného row-level zamykání a dalších vlastností.

9.3.2007 08:41 | razor | Zajímavý článek

Komentáře

[Penguin_007]

Tak si říkám, jestli by jim neprospělo soustředit se na jeden storage engine a ten mít opravdu ma špičkové úrovni (viz. PostgreSQL), než mít 20 různých z nichž každý umí něco.

[razor]

Jenom bych to upřesnil. MySQL AB se na ten engine "nesoustředí". Pro své účely ho vyvíjí jiná firma a poskytuje ho pod GPL.

[Abraxis]

Naprosty souhlas - SQL server, u ktereho se musim zajimat o volbu backendu pro mne neni "opravdovy" SQL server... Natoz, aby u nej "inzerovali" ACID a podporu transakci - to je snad dneska naprosta samozrejmost!

Pochopitelne jsou vyjimky z pravidla hl. pro embedded zarizeni (SQLite apod.)

[Filip Jirsák]

Co je na tom špatně, že můžete k několika backendům přistupovat přes jedno rozhraní?

[ivan]

Treba to, ze nemuzete implementovat integritni omezeni mezi jednotlivymi enginy. Anebo ze nemuzete snadno zalohovat databazi za behu. Podle me je jeden funkcni, stabilni engine pro relacni databaze tak akorat.

[Filip Jirsák]

A co vás nutí používat víc enginů najednou? Já jsem tu otázku schválně položil tak, jak jsem jí položil. Psal jsem o tom, že je několik enginů, které mají shodou okolností společné klientské API, společné funkce atd. Tedy místo toho, aby si každý backend musel tyhle věci naprogramovat sám, použije to, co je už hotové.

To je to stejné, jako byste tvrdil, že Linux není pořádný operační systém, protože podporuje více souborových systémů. Mezi nimi nejdou dělat hardlinky atd. Jakoby vás někdo nutil těch možností využívat.

[Michal Vyskočil]

To znamená, že je teď MySQL ve skutečnosti API pro různé databázové enginy? (to není rýpání, jenom mi tvůj příspěvek takto vyzněl)

[alkoholik]

To neni jen API. Je tam SQL parser, optimalizator.. Parodii na clustery to taky pry umi..
;)
BTW tvoje "teď" nedava smysl. Jestli se nepletu, tak uz ve 3.x sis mohl vybrat z nekolika backendu.

[Filip Jirsák]

Nejen API, ale všechny možné "podpůrné" funkce pro databázové jádro – parser, logování, správa přístupových práv, SQL funkce, možná něco z optimalizátoru dotazů, klientské API, dump/restore… Alespoň já mám pocit, že MySQL v poslední době jde tímto směrem, vždyť jenom kolik databázových enginů pro MySQL přibylo za poslední dva roky. A připadal by mi takový postup i celkem logický, tyhle věci „okolo“ databázového jádra byly vždy silnou stránkou MySQL. Ostatně snadná implementace nových databázových backendů je v dokumentaci k MySQL vyzdvihována jako jedna z důležitých vlastností.

[Abraxis]

Porad ale nikdo nepisete PROC by nekdo mel chtit vyuzivat backend A namisto backendu B. Jedinym duvodem muze byt, ze A nema nekterou funkci B. Pak to je ale o kompromisu a o tom, ze autori A by meli tuto funkci implementovat...

Krome MySQL myslim (!) nikdo z velkych hracu nema moznost volby vice backendu - myslim tim DB2, Oracle, PostgreSQL, Firebird, Sybase...

[Filip Jirsák]

Píšu pořád o opačném přístupu. Mám backend A a backend B atd. a jeden z nich si vyberu. Jenže samotný backend nestačí, aby to byla databáze, je potřeba ještě docela dost věcí okolo. Autoři některých backendů to vyřešili tak, že backend vložili do MySQL, a celou tu „omáčku“ okolo backendu mají takříkajíc zadarmo. Vím, že ve skutečnosti spousta těch backendů byla do MySQL „jen“ přenesena, ale asi to nebylo z pouhého rozmaru vývojářů.

Z pohledu uživatele databáze to je taky jinak: potřebuji rychlé skladiště dat bez velkých nároků na relační zpracování – zvolím si backend MyISAM, takže databázi MySQL. Pak dělám jiný projekt, potřebuju už více relační databázi s transakcemi, zvolím InnoDB – a najednou zjistím, že můžu zase použít jako „Database Management System“ zase MySQL, nemusím se učit nový dialekt SQL, nemusím se učit používat nové administrátorské nástroje, nemusím shánět nové drivery…

Tedy nevolím nejprve MySQL a pak některých z backendů, ale zvolím backend, přičemž některý backend má tu přidanou hodnotu, že může být provozován v MySQL. (Já tedy ve skutečnosti zvolím backend PostgreSQL a oželím tu chybějící „přidanou hodnotu“ v podobě možnosti běžet v MySQL, ale to je trochu něco jiného.)

[okbob]

Doinstalujte si plperlu, a pripojte se k MySQL . Je to sice berlicka, ale funguje. Mit dva engines neni nijak elegantni, ale obcas je to nutnost. Ted si dovedu predstavit celkem dost vyhod i nevyhod. Zaroven si nemyslim, ze by nekdo vybiral engine objektivne. Spis to budou srdecni zalezitosti typu ext3 nebo raiser ...

[Abraxis]

Sorry, ale musim se zeptat znovu - PROOOOC by si nekdo instaloval backend A a B?

Opet - nebavme se o embedded (a research) pouziti.

[Filip Jirsák]

Odpovím znovu: chci udělat redakční systém – zvolím backend A, který je hodně rychlý na SELECT * FROM tab WHERE id = x, nevadí mi, že neumí transakce, složité JOINy nebo bůhvíco jiného. Pak chci udělat účetnictví, tam už bych transakce rád použil, zase nebudu mít x přístupů za sekundu, tak můžu použít něco pomalejšího ale „víc SQL“ – backend B. Jeden zákazník (ten co chtěl redakční systém) si nainstaluje backend A, druhý zákazník (ten co chtěl účetnictví) si nainstaluje backend B. Ale já jako vývojář a správce nemusím znát dva dialekty SQL, nemusím znát dva způsoby práce s konfiguračními utilitami, dva způsoby nastavování přístupových práv, nemusím si pamatovat, která databáze má které funkce, nemusím používat dva různé ovladače databáze. Nemusí mi na serveru běžet dva samostatní správci databází. Tohle všechno mám jen jednou – MySQL. Ty dva backendy nemusí být dva projekty pro dva zákazníky, mohou to být klidně dva projekty v jedné společnosti – třeba pro školní intranet budu chtít hlavně rychlost, transakce nepotřebuju, naopak pro evidenci informací o studiu, známkách apod. se spokojím s pomalejším backendem, ale s plnou podporou transakcí. Ale programovat to může jeden tým, spravovat to může jeden správce.

[Abraxis]

A neni proste lepsi jeden backend, ktery bud jen nakonfigurujes a nebo proste transakce nepouzijes? Kdyz to takhle zvladaji vsechny ostatni SQL servery, tak proc to nemuze zvladnout MySQL?

[Jiří (BoodOk) Kadeřávek]

Ne není to lepší. Je to jako kombinace offroadu a formule. Nebo to nejlepší ani v tom, ani v tom, protože to jak máš seskládaná data determinuje i nejvodnější scénář použití.

[Jiří (BoodOk) Kadeřávek]

s|Nebo|Nebude|

[Abraxis]

Opet - proc zadny jiny SQL server nema moznost vice backendu? MySQL proste je spatne navrzeny (vsak taky pry zacinal jako "SQL rozsireni nad textovymi soubory").

Neslysel jsem, ze by si nekdo v podsledni dobe stezoval na rychlost PostgreSQL/Firebirdu/Oraclu...

[Filip Jirsák]

Opet - proc zadny jiny SQL server nema moznost vice backendu? MySQL proste je spatne navrzeny (vsak taky pry zacinal jako "SQL rozsireni nad textovymi soubory").

Linux je taky špatně navržený, protože potřebuje spoustu různých filesystémů. Některé operační systémy si vystačí s jedním nebo se dvěma. Že se na paměťové karty do mobilů a foťáků používá FAT, to je taky hloupost výrobců, mají použít ext3, akorát nepoužívat žurnálování. A PostgreSQL, Firebird a Oracle by se taky měly zrušit, protože ke všem můžete přistupovat z některých programovacích jazyků přes jednotné rozhraní (JDBC v Javě, ODBC ve Windows, DBM v PHP atd.), takže stačí jedna datanáze, která se jednou nakonfiguruje jako PostgreSQL, podruhé jako Firebird a pak třeba jako MS SQL.

Možná by stálo za to přestat míchat hrušky z jablkama. MySQL není SQL server na stejné úrovni jako PostgreSQL nebo Firebird. PostgreSQL o sobě tvrdí „relational database system“, Firebird „relational database“, MySQL „database management system“. Tedy PostgreSQL nebo Firebird jsou databázové systémy, MySQL je systém pro správu (několika) databázových systémů. Tedy jeden backend (třeba MyISAM) stojí na úrovni PostgreSQL. Akorát PostgreSQL k tomu backendu dodává vlastní obálku, MyISAM má obálku, která je shodou okolností stejná, jako obálka několika dalších backendů.

Opravdu nevím, co vás pořád tak dráždí na tom, že vedle databázového backendu, který jste si vybral, může někdo jiný provozovat pod MySQL i jiné databázové backendy. Tak prostě zapomeňte, že MySQL má i jiné backendy, než ten vámi vybraný, a budete spokojený.

Neslysel jsem, ze by si nekdo v podsledni dobe stezoval na rychlost PostgreSQL/Firebirdu/Oraclu...

Jestli to nebude třeba proto, že pokud už se někdo rozhodne pro některou z vyjmenovaných databází, tak už o databázích alespoň něco ví, takže si vybere typ databáze, která mu vyhovuje.

[martyone]

Jen bych si dovolil upřesnit, že (nepletu-li se) DBMS - DataBase Management System je oficiální pojem z databázové teorie (česky také SŘBD - Systém Řízení Báze Dat), a je jím, stejně jako MySQL, také PostgreSQL a Firebird (, ...). Další oficiální pojem - relační databáze, pak označuje existující datovou strukturu, vytvořenou za použití prostředků jistého DBMS. To, jestli lze v případě některého DBMS mluvit také o front/back-endu, je interní záležitost jeho implementace, a obě tyto části tvoří celek (byť by byla některá z nich sdílená). Tedy to, co o sobě tvrdí ten, či onen z uváděných systémů, je jen více či méně nepřesný zápis jednoho pojmu.

[Filip Jirsák]

Máte pravdu. Ale třeba v knize Vytváříme relační databázové aplikace od Rebeccy M. Riordan je jako příklad DBMS uváděn MS Access a MS SQL Server, a jako databázové backendy MS Jet a SQL Server. Což je něco podobného – MS SQL Server je „vše v jednom“ – jeden systém s jedním backendem. MS Access je systém, který ale umí využívat různé backendy. Ale jaká marketingová slůvka použije kdo na svém webu, to opravdu ještě neznamená, o co se jedná ve skutečnosti.

[okbob]

MyISAM je celkem idealni pro zajisteni HTTP cache. Nadruhou stranu, nepouzil bych tento engine pro jen trochu cenna data.

[Abraxis]

Data bud jsou cenna nebo bezcenna... Neexistuji data, ktera jsou neco mezi - proste bud potrebujes jejich konzistenci nebo ne...

A na HTTP cache preci ma Squid docela slusne vlastni mechanismy, ne? Davat HTTP cache do SQL serveru mne prijde jako brutalni overkill.

[Jiří (BoodOk) Kadeřávek]

Takže cena dat je určenou mírou jejich konzistence? Znám spoustu lidí, kteří by dali já nevím co za svá ztracená data i ve značně nekonzistentní podobě.

[Abraxis]

Pockej, ted do toho michas neco uplne jineho - zalohovani.

Zkus se tech lidi zeptat, zda by pro ne mely ty data stejnou cenu konzistentni tak jako nekonzistentni - KDYBY meli na vyber...

[Jiří (BoodOk) Kadeřávek]

Protiřečíš si. Nejdřív tvrdíž, že jsou buď cenná nebo bezcenná a teď chceš o jejich ceně licitovat. Tak jako to je? Máš scénáře, kdy cena dat nemá s jejich konzistencí co dělat (např. adresář kontaktů) a kde je jejich cena na konzistenci přímo závislá (třeba datové schema podvojného účetnictví, kde musí sedět MD a DAL).

[miho]

Porad mi nikdo nepisete PROC by nekdo mel chtit vyuzivat monopost F1 namisto nakladaku. Jedinym duvodem muze byt, ze F1 nema nekterou funkci nakladaku. Pak to je ale o kompromisu a o tom, ze designeri formule 1 by meli tuto funkci implementovat...

Trosku nadsazka ale myslim ze vysvetluje podstatu problemu. Zamykani na urovni radku/stranek/tabulek - tyto pristupy napr. maji kazda svoje vyhody. A sloucit je proste nelze.

[lakatos]

No problem je ten, ze rust slozitosti nejakeho databazoveho reseni neni linearni funkce. Jako jednuduchy, ale nazorny priklad, muzeme porovnat slozitost(rychlost) konstantnich databazi (napr. CDB) a databazi,kde je potreba menit data - tam se slozitost skokove meni treba az o dva nebo nekolik radu. Chci rici, ze napr. pridanim nejake funkce (treba transakce) skokove menim slozitost designu a tim i rychlost, apod. Nekdy proste nejde jednosuse implementovat funkci, aniz bych nebyl nucen totalne rozbit dosavadni design a v dusledku toho zpusobit treba az 5-ti nasobnou degradaci vykonu (o coz jde nekdy nejvic).

[alkoholik]

Linux neni kompletni operacni system. To je treba debian. A ten umi i jadro FreeBSD, HURD..