Drizzle: könnyedebb MySQL

MySQL, MariaDB

Michael Widenius, a MySQL alapítója és megalkotója bejelentette a Drizzle projekt elindulását. Hogy mi az a Drizzle?

  • MySQL verzió, intenzívebb közösségi közreműködéssel a szoftver dizájn kialakításában
  • elsősorban weboldalak alá szánják
  • Brian Aker és közösségi irányítás alatt feljlesztett MySQL fork
  • kisebb, "vékonyabb" és (remélhetőleg) gyorsabb MySQL verzió (eltávolításra kerülnek/kerültek a "felesleges" dolgok: tárolt eljárások, views-ok, trigger-ek, egyes storage engines-ek, stb.)

További részletek Michael Widenius blogjában és Brian "Krow" Aker webnaplójában.

Attol felek, valaki ujra feltalalta azt, amire a csodalatos firefox csapata is rajott... Par evente csinalnak egy uj "pehelysulyu" appot, ami a tizedet tujda a reginek es hencegnek vele, hogy milyen gyors. Aztan szep lassan visszapakoljak bele az osszes funkciot csak kicsit maskepp (neha eppen rosszabbul, mint volt - pl. firefox) es kezdodik az egesz elolrol...

"tárolt eljárások, views-ok, trigger-ek, egyes storage engines-ek"

tárolt eljárást sehol sem használnak web alá, még ot tsem ahol amugy oracle van.

view speciel buziság kivenni, mert annak pont vna értelme.

trigger-t se igen használnak.

storage engines: myisam-on kívül csak az innodb fordul elő néhol

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( uid_228 | 2008. 07. 23., sze – 21:49 )

Lefordítom:

  • MySQL verzió, intenzívebb közösségi közreműködéssel a szoftver dizájn kialakításában

    Sokat látott, tapasztalt, rendszerszemléletben erősen gondolkodni képes PHP-fejlesztők jelölik ki a követendő irányt.

  • elsősorban weboldalak alá szánják

    Miért, eddig mire használták?

  • Brian Aker és közösségi irányítás alatt feljlesztett MySQL fork

    Web 2.0: you make the content, they make the money.

  • kisebb, "vékonyabb" és (remélhetőleg) gyorsabb MySQL verzió (eltávolításra kerülnek/kerültek a "felesleges" dolgok: tárolt eljárások, views-ok, trigger-ek, egyes storage engines-ek, stb.)

    Ezzel próbálják meg a Sun kurrens procijait sebességben versenyképessé tenni.

:)

--
Ruby takes the elegance and simplicity of Perl, and mixes it with the library support of Lisp.

( kikke | 2008. 07. 23., sze – 21:51 )

Ajjaj. Azért mert a drupal-kiddie-k nem tanulják meg a tárolt eljárásokat, triggereket stb.. még nem kéne kidobni. Vagy akkor már az autoincrement-et is dobjuk ki, úgyis csak a 6-os sorozattól merték használni, még nem késő visszaállni az "update-elek egy segédtáblát hogy emebben hol is tartok" típusú kókányolásra...

Pont hogy nem mindig futnak lokalisan, sot. Tanultabb emberek kulon teszik az adatbazist es kulon a webszervert, mivel mindketto eltero biztonsagi intezkedeseket, es eltero rendszeroptimalizaciot kivan. Arrol mar nem is beszelve, hogy sok lekeres eseten egy ilyen konstrukcio meg valamivel gyorsabb is tud lenni a csokkentett iowait miatt.

Amugy a tavoli eljarasok nagyon okos talalmanyok. Azert mert rengetegen felnek hasznalni, attol meg nem kell kidobni.

Tranyokezeles: Szinten eleg kevesen hasznaljak. Mondjuk ettol meg nem kell ezt se kidobni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Valószínű, nem azokat célozza a Drizzle, akik külön szerverre rakják a MySQL-t és a webszervert :)

Egyébként ahogy néztem a MediaWiki forrását, MySQL és Oracle esetében tranzakciózik (erre a kettőre emlékszem).

--
- Name ONE thing that your Linux computer can do that my MAC can't!
- Right click.

Vannak azert bajok a tarolt eljarasokkal:
1. ketfele osztja a kodbazist, ami frankon tokonrugja az osszes vcs-t es arra epulo csapatmenedzsmentet
2. teljesen mas nyelv, ergo egy projekten belul immar min. 2 nyelvet ismero emberek kellenek
3. mindegyik vacak dbms-nek mas es mas nyelve van, nem atjarhatoak
4. tetu lassu, interpretalt

konkluzio (azaz 5.): ahol tarolt eljarasokat hasznalnak, ott elb*tak a szoftver design-t, es a tarolt eljarasokat egy koztes absztrakcios retegnek hasznaljak ---> fobeloves a software architect-nek.

Hory,

ez azert igy eros tulzas es demagogia...

> 1. ketfele osztja a kodbazist, ami frankon tokonrugja az osszes vcs-t es arra epulo
> csapatmenedzsmentet

Valoban ketfele osztja a kodbazist, ezzel egyutt semmi akadalya, hogy a tarolt eljarasok forrasait is tarold a VCS-ben. Egy tisztesseges helyen a deployment ugyis scriptbol megy, annak meg olyan mindegy, hogy meg tarolt eljarasokat is rak az adatbazisba, vagy sem.

> 2. teljesen mas nyelv, ergo egy projekten belul immar min. 2 nyelvet ismero emberek kellenek

Es? Nehogy mar a 'ha csak kalapacsod van, mindent szognek latsz' legyen a kovetendo fejlesztesi modszertan. Bizonyos feladatokra a tarolt eljarasnal nincs jobb eszkoz (nagy mennyisegu adat bonyolult feldolgozasa adatbazisbol azonos adatbazisba minel gyorsabban). Ezt minek megjaratni az alkalmazas szerveren keresztul?

> 3. mindegyik vacak dbms-nek mas es mas nyelve van, nem atjarhatoak

Valoban. De gyakran hasznalsz egy olyan rendszert amiben szukseg van tarolt eljarasokra, tobbfele adatbazisban?

> 4. tetu lassu, interpretalt

Mysql-nel nem tudom, Oracle forditja a tarolt eljarasokat.

"Vannak azert bajok a tarolt eljarasokkal:
1. ketfele osztja a kodbazist, ami frankon tokonrugja az osszes vcs-t es arra epulo csapatmenedzsmentet
2. teljesen mas nyelv, ergo egy projekten belul immar min. 2 nyelvet ismero emberek kellenek
3. mindegyik vacak dbms-nek mas es mas nyelve van, nem atjarhatoak
4. tetu lassu, interpretalt

konkluzio (azaz 5.): ahol tarolt eljarasokat hasznalnak, ott elb*tak a szoftver design-t, es a tarolt eljarasokat egy koztes absztrakcios retegnek hasznaljak ---> fobeloves a software architect-nek.
"

Ennek azért szaladj neki még egyszer szerintem :D

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

( Xterm v | 2008. 07. 23., sze – 23:10 )

lehet két ilyen nagy projektben érdemben alkotni tök más koncepciók mellett?

--
xterm

( gUHU | 2008. 07. 23., sze – 23:35 )

Nem értem ezt a hozzáállást. Miért nem jó a PostgreSQL? Tud mindent amit egy rdbms-nek tudnia kell és gyors is. A konzolos kezelhetőségéről meg nem is beszélve.

És mit fog tudni a drizzle? select * from tabla kurvagyors lesz, de ha már lesz benne egy where, akkor már lassú? Akkor meg minek?

Elnézést, de nekem ennek nagyon parasztvakítás szaga van.

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Tényleg parasztvakítás.

Sokáig én is gondolkoztam, hogy miért nem jó a PostgreSQL nekik és csak a MySQL dual license-ére tudok gondolni.

Könnyen lehet, hogy az a cél, hogy legyen egy buta MySQL community version és ha megveszed akkor legyenek csak meg az extra feature-ök (melyek a PostgreSQL-ben már időtlen idők óta alapból elérhető).

"hogy legyen egy buta MySQL community version" de igazábol a mysql-hez attól, hogy megvásárolta a sun még létezik community version, igaz nem butább mint az enterprise. Ellenben ez a drizzle egy mysql fork, de szeritntem más célközönségnek szánják.

subjektív: én nem használnám 1 mert a régebbi dolgokat nem fogom átdolgozni, hogy menjenek rajta, 2 mert az új dolgokból nem fogom kihagyni az eddig megszokot és bevált kényelmi funkciókat, 3 mert ha szükségem is lenne egy tudásban kisebb adatbázisra, de az nem nyújt semmi extrát a jelenlegihez képest, akkor a bevált módszerrel oldanám meg, hisz mindenhol máshol is azt használom.

Ez így van, nagy terhelé esetén elég magas load-ot csinál a mysql. Először nem hittem el,
de tényleg. Átnéztem mindent. Tök egyszerű táblák postfix-nek, apache2-nek, php-nak.

Nagyon rég óta használunk postgresql-t, lassan visszakerül a web szerverre is....

---
/dev/sda1 has gone 49710 days without being checked, check forced.

Szerintem a legtöbb script kiddie-nek, meg Php Jánosnak az a baja a pgsql-lel, hogy nem érti a működését.

a mysql egyszerű, mint egy faék.
pgsql-ben ott van az, hogy schema, meg egymillió adattípus, illetve mivel a db-k külön futnak, ezért dblink nélkül nem queryzhetsz más db-ből. Ráadásul olyan feature-ök, amiket a dev.mysql.com meg sem említ, így "bonyolult, tehát szar".

Gondolom a slagó(r) hosting típusú cégeknél is csak ezért van csak mysql.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( Pitta | 2008. 07. 23., sze – 23:36 )

ahahahahah

ez igy mi?
tibike behaluzta az oraclet aztan rejott h egyik ficsort se tudja implementalni utana kitalalja h akkor nem is kellenek ezek?

txt fileok miert nem jok?

sqlite miben nyujt kevesebbet?

#toy like ppl make me boy like

Le akarják cserélni? Hol olvastál te ilyet? A jelenlegi kínálat mellé hoznak egy újat. Szerintem arról van szó, hogy forkolják a GPL-es MySQL-t, kidobják belőle azt, ami nem kell az egyszerűbb feladatokhoz és kínálják Drizzle néven a _jelenlegi kínálat_ mellé. Ha neked ez nem kell, rá sem nézel.

--
trey @ gépház

( Mico v | 2008. 07. 24., cs – 01:49 )

Csak én vagyok túl fáradt, vagy tényleg olyan bonyolult átlátni ezeken a dolgokon?

Michael Widenius keresett egy rakás pénzt a cég eladásával, de ő nem kapott helyet a Sun vezetésben (talán nem is kért volna), mivel már régóta nem foglalkozott a MySQL cég dolgaival. Néhány ember (nem, illetve már nem MySQL alkalmazottak) úgy döntött, csinál egy forkot, back to mysql 3.23, ezt Monty megírta a blogjában, még tetszik is neki mert kb. akkor volt, amikor nagy része volt a projektből, ennyi, tessék mindezt a helyén kezelni, véleményem szerint nem több, mint egy huszonhatodik Linux disztribúció vagy bármi egyéb, vagy jutnak vele valamire, vagy nem, vagy érdekelni fogja az embereket, vagy nem. De az egésznek semmi köze a MySQL jövőjéhez.

Ez Monty szemszögéből dícséretre méltó, no meg azt csinál a pénzével, amit akar.

Viszont akkor megint ott tartunk, hogy a Sun megint "ügyesen" bevásárolt. Az InnoDB az Oracle-é, a volt fejlesztők egy része meg párhuzamosan kezd valami ugyanolyat fejleszteni, mint amit egy zsák pénzért vettek meg tőlük előzőleg. Én ezt nagyon úgy látom, hogy hosszú távon kétfelől kezdik majd szorongatni.

--
Ruby takes the elegance and simplicity of Perl, and mixes it with the library support of Lisp.

Ezek nem "a" volt fejlesztők. Talán egeresz írta egy másik topicban, hogy egy projektben a programozók x% -a csak bugot termel, vagy nem visz előre semmit. Ezek lennének ők. Még csak nem is beszélnek kódolásról, hanem refactoringról, kidobálnak mindent, aztán majd meglátják, mert a Sun féle "kódolni is kéne valamit nem csak a mysql levlistán osztani az eszet miközben utoljára egy patchet küldtem be 2002-ben" modellben már nincs helyük.

Üdv

Nem, az sqlite nem jó távolról (hacsak nem akarod nfs-en bemountolni...)
Felhasználók, jogok? Hogy teszed fel egy multi-(buta)-user web szerverre?

Már kacérkodtam a gondolattal, hogy kezdek valamit a picosql-el, csak jórészt C++ ban írta
olasz barátunk....

A 3.23-as mysql bőven elég a kölcsönadott DVD-k menedzseléséhez ;)

Drukkolni kell nekeik. Hadd törjenek egy kis borsot a sün orra alá :)
---
/dev/sda1 has gone 49710 days without being checked, check forced.

( turul16 v | 2008. 07. 24., cs – 09:11 )

Triggerek kellenek.

Igy 2008 -ban elvarom egy RDBMS -tol, hogy maga tudjon gondoskodni az adatok integritasanak megorzeserol is.

Ha meg sebesseg kell, magam taknyolok ossze valamit. ami nem (feltetlen) eszik SQL nyelvet, de gyors.

SQL-es dolgok nem gyorsasagrol hiresek es nem is ezert szeretik ,sok elvetemult app, ugyan azon a DB -n elehet boldogan.

Ha a sebesseg fontoss es nem multikulturalis alkalmazas halmot akarunk raultetni , akkor erdemes mas megoldasokon elgondolkozni.