"Annak ellenére, hogy az 5.1 inkrementális kiadásnak tűnik, néhány eléggé nagy új funkciót kapott." - mondta Zack Urlocker, a Sun MySQL termékéért felelős alelnöke. "Lehetséges, hogy 6.0-nak kellene hívnunk, mert annyi új anyag került bele és [mert] néhány éve dolgozunk rajta."
Az 5.1 újdonságai közt lesz a "partitioning", "events scheduling", "row-based replication" és a "disk-based clustering".
Az újdonságok mellett több bug is javításra került: "számos, az 5.0-ban meglevő bugot javítottunk" - nyilatkozta Urlocker. "Szóval az 5.1-nek nem csak a megbízhatósága nagyobb, de 20%-kal jobb a teljesítménye is."
Részletek itt.
- A hozzászóláshoz be kell jelentkezni
- 2607 megtekintés
Hozzászólások
Az SQL szerverek a szabad szoftverek talán legnagyobb sikerágazata. Több SQL szerver is versenyzik a pályán. Hirtelen talán a három legismertebb a MySQL, a PostgreSQL és a FireBird. Egészítsetek ki, ha van még ilyen kaliberű szabad SQL szerver!
A SUN belépésével a MySQL úgy néz ki kapott egy friss lendületet, ami előbb utóbb valószínűleg a konkurenciát is megmozgatja.
--
Intelligens ember itt nem dohányzik! A többinek meg Tilos!
- A hozzászóláshoz be kell jelentkezni
Csak kár, hogy a MySQL elnyomja a többit és a csapból is csak az folyik, hogy MySQL így meg MySQL úgy, pedig van, amit a többi már rég tud.
De ez más nyílt forráskódú projektnél is megfigyelhető.
- A hozzászóláshoz be kell jelentkezni
Szerintem nem igazán van így. Sok helyen bizony a postgresql a megfelelő megoldás és ott használják is.
--------------
Sok ember hord Superman-pizsamát. Superman Chuck Norris-pizsamát hord.
- A hozzászóláshoz be kell jelentkezni
Én eddig a FireBird-ről nem is hallottam.
Java-s körökben még erősen favorizált a HSQLDB és a Derby (és ezek változatai).
- A hozzászóláshoz be kell jelentkezni
A Borland egy gyönge pillanatában az InterBase-6 kódját megnyitotta. A későbbi InterBaseket persze már zárt kóddal fejleszti. Az InterBase 6-ot forkolva készítik a FireBird SQL-t: http://www.firebirdsql.org/
--
Intelligens ember itt nem dohányzik! A többinek meg Tilos!
- A hozzászóláshoz be kell jelentkezni
SAPDB/MaxDB azt nem tudom most épp melyik a rendes neve.
Talán a SAP által támogatott az a SAPDB a másik meg a másik.
- A hozzászóláshoz be kell jelentkezni
kíváncsi vagyok, hogy a sok jáva fejlesztő aki eddig fújolt a mysql-re, az most mit csinál? tovább fújol egy sunos adatbázisra? :D
- A hozzászóláshoz be kell jelentkezni
Én is Java-s fejlesztő vagyok és egyáltalán nem "fújolok" a MySql-re, sőt mi is használjuk azt is!
Egyébként az Apache Derby még egy érdekes lehet a Javasoknak, mivel a Sun is támogatja, olyannyira, hogy a Java 6-ba be is került Java DB néven.
- A hozzászóláshoz be kell jelentkezni
miért ne fújolhatnának?
- A hozzászóláshoz be kell jelentkezni
hát egyrészt mért ne, másrészt azt írtam, hogy akik fújolnak, nem azt, hogy mindegyik. másrészt tapasztaltam én is előző munkahelyemen, hogy meglehetősen sokat fújoltak rá a java fejlesztők ...
- A hozzászóláshoz be kell jelentkezni
Én Java fejlesztő vagyok és nem fújolok rá de még a kolegáktól sem hallottam, hogy fújolták volna a MySQL-t. Amúgy Oracle-t használunk de mindig visszasírom a MySQL-es időket.
--
sirkalmi
- A hozzászóláshoz be kell jelentkezni
majd kiváncsi leszek, azért arra a 20% teljesítményjavulásra, egy kissé marketinggyanús.
- A hozzászóláshoz be kell jelentkezni
en majd arra a disk-based clusteringre...vajon mit ertenek alatta...olyat mint az Oracle RAC?
- A hozzászóláshoz be kell jelentkezni
Nem követem a MySQL-t, de nem erről van szó?
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-disk-data.html
Ha igen, a kérdésedre a válasz: nem.
- A hozzászóláshoz be kell jelentkezni
Sajnos igazad van. Csak annyi, h ki tudja tolni mar diskre a db-t, nem kell memoriaban tartania.
Marad a replikacio, s dedikalt hostok dbknek mint HA megoldas....
Mar ha nincs legalabb 5 geped, s elegendo ramod....:)
- A hozzászóláshoz be kell jelentkezni
Az NDB miért nem jó HA megoldásnak? Az indexek nem férnek el memóriában? Bánt, hogy ha az Oracle RAC alatt összeszarja a diszkeket random bitmintával valamelyik kontroller, akkor veheted elő a mentést, csak, hogy kiderüljön: rosszul volt kalibrálva a fej és használhatatlan az egész, míg itt -mivel shared nothing az egész- elintézed egy vállvonással?
(arról, hogy az NDB mennyire jó, vagy rossz nem beszélek, tisztán csak architekturális alapon összehasonlítva a kettőt)
- A hozzászóláshoz be kell jelentkezni
Hehe epp nem architekturalis peldat hoztal:) RACot altalaban normalis SAN on szokas uzemelni, ahol nem egy vinyora mentodik a cucc (igy egy kontroller nem tudja hazavagni az egeszet). (Szerk:tehat architekturalisan maskepp van kitalalva, mas vasra). Amugy meg azt is megneznem, h ha elvesztik a syncet az ndb data node-jaid akkor egy vallranditassal elintezed, ha attol fuggoen hova megy a keres mas valaszt ad:) - Legalabbis elmeletben atgondolva. Lehet h a gyakorlatban ez maskepp megy...erdekelne a dolog..
Nekem egy olyan mysql clusterre fajna fogam, ami 2 mysql gepen futna, s parhuzamosan lehet raengedni mindkettore loadbalance-olva a kereseket. Sajnos legalabbis amennyire atfutottam a cluster doksit, meg best practice-ajanlast,
azt mondja, 3 data node, es 2 management node az ajanlott kiepites (hogy rendes HA es eloszlas legyen).
Szal engem vmi NBD es replikacio kozti megdoldas izgatna. Persze mondjuk lehet 2 gepen futtani gondolom data+management node-okat, de alapban azt irtak, h ellenjavallott. Valaki probalkozott mar ilyennel?
- A hozzászóláshoz be kell jelentkezni