Maria, az új MySQL storage engine

MySQL, MariaDB

Michael Widenius aka. "Monty", a MySQL eredeti fejlesztője és a MySQL AB társalapítója blogjában bejelentette, hogy publikusan elérhetővé tették a "Maria" névre hallgató, új MySQL storage engine forrását BitKeeper fában. A Maria-t Sergei Golubchik, Oleksandr (Sanja) Byelkin, Guilhem Bichot és Michael Widenius immár két éve fejleszti.

A fejlesztés másfél évig csak részidőben történt, mert a fejlesztők más projekteken is dolgoztak. Valójában az elmúlt 4 hónapban foglalkoznak a Maria-val teljes időben és jelenleg csak erre koncentrálnak. Még nem született döntés arról, hogy a Maria mikortól lesz elérhető bináris terjesztésben. Amíg nem szállítják így, addig a BitKeeper fa áll a tesztelők rendelkezésére.

A fejlesztők szerint jelenleg a Maria 1.0 körül járnak, ami azt jelenti, hogy a projekt jó állapotban, ismert bugja nincs, de további tesztelésre van szükség ahhoz, hogy az esetleges rejtett bugokra is fény derülhessen.

Bővebb információk, jellemzők, FAQ, stb. Monty blogjában.

(A linkért köszönet fp-nek!)

( ssikiss | 2008. 01. 29., k – 21:39 )

To create a new, ACID and multi-version concurrency Control (MVCC), transactional storage engine that can function as the default non-transactional an the default transactional storage engine for MySQL.

Jó reggelt!

( bra | 2008. 01. 29., k – 21:48 )

Lassan több storage engine lesz a MySQL-hez, mint ahány Linux disztribúció van. Most akkor Maria, vagy Falcon?

Ahogy látom, az egy évvel ezelőtti Falcon alfa kiadás után volt egy benchmark, ahol (röviden) leszerepelt. Azóta is alfa, de aktívan fejlesztik (Jim Starkey - mvcc, blobs és interbase atyja).
A korábbi elképzelések szerint elvileg mostanra már kellene lennie bétának vagy rc-nek.

mondjuk myisamnal nem is a konkret bugossagra erdemes gondolni, hanem a tranzakciok hianyara. furcsa bugok inkabb a clusteres reszben vannak, de biztos vagyok benne, hogy az akvizicioval egyutt javulni fog a mysql ilyen teren is (johogy, aze' a sunnak meglehetosen baratsagos a clusteres portfolioja, nem lehet rajta szegyenfolt).

adatot vesztenek

Ami elég loser dolog. Rendszeres, megbízható backup és onnan kezdve nem igazán érdekes, hogy adott DB engine vagy filesystem mennyire hajlamos az adatvesztésre.
Persze, ha az embernek magas rendelkezésreállásra van szüksége, akkor a restore ideje is veszteség, de ilyen adatbázist nem biztos hogy MySQL-re bíznék.

Ave, Saabi.

Erre csak úgy tudok reagálni mint a középkori egyszerei ember az elefánt láttán:
"ilyen azért már csak nem létezik"
Addig oké, hogy egy adatbázis file korrupttá "válik" és emiatt az adatbáziskezelő leáll. De hogy még észre se vegye... ez olyan szintű programhibára utal (sőt, tervezési hibára), amit nem tudok elképzelni még egy MySQL szintű adatbáziskezelőtől sem.

Ave, Saabi.

Benne vagyok egy csapatban, ahol egy kissebb tárhelyszolgáltatónál vannak a lapjaink és a fórummotor mysql-t használ. Ne most az adatbázistáblák néha (havonta kb 1-2x) "elromlanak" (áramszünet, újraindítás?) és addig nem hajlandó őket használni, amig (mysql)admin felületen keresztül rendbe nem rakjuk őket valami rebuild vagy repair funkció futtatásával. Na ennyit a myisam-ról. (Adatvesztés tudomásom szerint még nem volt.)

( nevergone v | 2008. 01. 30., sze – 16:04 )

És ha még nem lesz benne adat, akkor ez lesz a szűzmaria? :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."