Drizzle: könnyedebb MySQL

 ( trey | 2008. július 23., szerda - 19:46 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

vissza a kőkorba??

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.

Lefordítom:

  1. 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.

  2. elsősorban weboldalak alá szánják

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

  3. 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.

  4. 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.

Idézet:
Web 2.0: you make the content, they make the money.

miert, a "give us the money, we make the content" jobban tetszett?

Nekem tovabbra is "i make the content, give me the money" a filozofiam.
Tul sokat dolgoztam ingye' vagy egy marek foldimogyoroert.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Adi írta:
elsősorban weboldalak alá szánják
Miért, eddig mire használták?

Azért van jó néhány, nem csak weboldalakat készítő cég, illetve egy nem kisebb, mint maga a Google.

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

Nana, azert emiatt a google besertodne.. ? :)

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...

Mivel Webes alkalmazásoknál az SQL-ek úgyis lokálisan futnak talán nem olyan nagy veszteség a tárolt eljárások, de ami igazán kihathat a sebességre az a tranzakció kezelés, azzal mi lesz?

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.

:DDDDDDDDDDDDDDDDDDDDDD

hozok popcornt

#toy like ppl make me boy like

clr integration, managed stored procedures

ennek speciel van értelme

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

Ha a tárolt eljárás interpretált, a helyette kiadott SQL utasítások sora, amely ráadásul a kódban van, kliens oldalon nem az?
Illetve javában, perlben, pythonban, C-ben, akármiben nem lehet tárolt eljárást írni?

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.

"Oracle forditja a tarolt eljarasokat."

Csak kontextusváltásoknál lassul be, de a gondolkodás azon is segít :)

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

"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 --

szerintem csak a smiley maradt le...

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

--
xterm

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.

Ha kipróbáltad volna már pár millió oldalletöltést kiszolgáló oldalon, tudnád, mi a baj a PostgreSQL-lel...

Mesélj.


Andi, really. Take it from me. If I tell you something, I'm usually right.

Én már próbáltam...
A mysql 5.x nehezebben bírta :-)

Debianon? :D
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Nem, suse volt.
A mysqlt és a postgresql-t is tuningoltam. A mysql 1 konkurens kérésre jobban teljesített, de amikor 10 konkurens kérés volt másodpercenként, a pgsql volt lett a jobb. A szerver load is jóval alacsonyabb volt pgsql alatt mint mysql alatt.

Tudnál erről vmi részletesebbet írni, ha van időd?

Igazándiból az érdekelne, hogy hogyan tesztelted?
Vam vmi benchmark cucc, ami mysql-t, és postgresql-t is tud tesztelni?

Itt a hupon a blogjaim között van erről leírás.
A lényeg:
- pgsql-en volt eredetileg.
- localban teszteltem a mysql-t, gyorsabb volt a lekérdezés
- felraktam szerverre a mysqlt + tuningoltam
- nagyobb lett a szerver load - lassabbak lettek az oldalak - visszaraktam a postgres-t

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.

Nem tudom mi lenne a hiteles teszt. Amit csináltam, select *, insert egy sor, select *, update egy sor, select *, delete egy sor, select *. Százszor. Ugyanazon a gépen több mint tízes nagyságrendű különbség van MySQL és PostgreSQL között.

Hát láttam már mit tud. Nem ugatok csak úgy bele a nagyvilágba.

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

Ja, éhen halnak a hardware gyártók.

Már a 8.2 is köröket fut a kurrens MySQL körül,

8.3 meg gyorsabb a 8.2-nél is.

Hát, az oktatas.origo.hu is Pg-t használ... :) KÉP

Mert annyira stabil, es osszeszedett hogy egyszeruen a kutyanak nem kell.

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.

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

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

Ez ütött :D

--
Keep it simple, stupid.

Nekem is, főleg mert igaza van. A MySQL kezd végre kipofásodni (tárolt eljárások, view-k, tranzakciókezelés stb), erre le akarják itten cserélni a lebutított verziójával.


Andi, really. Take it from me. If I tell you something, I'm usually right.

lehet felületesen olvastam, de a csere szó hol van?

--
xterm

Sehol, de attól tartok, hogy be fog következni :(


Andi, really. Take it from me. If I tell you something, I'm usually right.

nem kell temetni, ameddig nincs sír...

--
xterm

Szerintem sem, a MySQL jó termék, a Sun meg nem bolond. Lesz egy ultra-lightweight adatbázis pluszban. És akkor mi van, nem olyan rossz dolog az.

--
Keep it simple, stupid.

Hamvasztás? Ahhoz nem ásnak sírt.

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

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

Én csak nagyon nem szeretném, ha elterjedne annyira, hogy felkerülne azokra a helyekre (ingyenes/olcsó hostingok), ahol most már MySQL 5 van.


Andi, really. Take it from me. If I tell you something, I'm usually right.

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.

Olyan jo kis osszeeskuveselmelet kezdett kibontakozni, te meg itt meggyujtod a villanyt, szegyelld magad :-D
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

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

Erre mondtam, hogy a nyíltforrású project-ek élőlények, nem termékek.
A Gugli már rájött erre. Meg talán a Motorola is. Az előlényeket nem megvásárolják, hanem magukhoz édesgetik.

> Az előlényeket nem megvásárolják, hanem magukhoz édesgetik.

Különben "megdöglik", vagy beteg lesz és csak alig alig mozog.

Azaz a nyílt forrású projektek tulajdonképpen tamagocsik? :)

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

Nem, vannak még akik megértették. :)

--
trey @ gépház

Akkor ezek most írnak egy sqlite-t? Minek?

--
http://internode.hu

mondjuk, hogy a solaris 11-ben mar ne sqlite-ot kelljen hasznalni nehany helyen. vagy mert csak. es?

Te pénzedből csinálják? Akkor meg?

De most tényleg, nem rohadt mindegy, hogy ő a saját idejét és pénzét mire szánja? Ha meg tetszik használod, ha nem tetszik, akkor továbblépsz.

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.

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.

Például?

Vicc:
Saját, turbopascal-os, spec., igényre szabott adatfájlos, btree-s, qsortos csoda viszi villannyossann tutti. ;))

te ezzel viccelsz, ellenben ha kidobot a pascalt alola, es irsz egy distributed cachet pl javaban.. ;)

Assemblyben már akkor az nagyságrendekkel gyorsabb lesz :-)

--
Elméletileg nincs különbség elmélet és gyakorlat között. Gyakorlatilag van.

memcached-re gondolsz? :-)

azt miota irtak javaban cicavirag?

ehcachere inkabb

horkantva röhögök...

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

De distributed cache aranyom ;)