MySQL kompatibilitást fejlesztenek a PostgreSQL-hez

Azt nem értem csak, hogy ha valaki csak select, insert, delete esetleg update utasításokat akar használni, semmi bonyolultabbat, akkor miért kell elköteleznie magát akármelyik adatbázismotor mellett?

Fogjon egy általános SQL csatoló akármit, lehet ODBC, vagy az amúgy is használt libekben ha talál valamit (QT-ben van, gondolom másokban is) akkor azt, és aztán ennyi.

A felhasználó meg majd azt rak alá, amit akar, vagy ami már úgyis van a gépén.

Én pl. utálom azt, hogy Postgresem van, Oracle-öm van, és Linux alatt valami csomag mysql-t tesz fel, vagy win alatt valami m$ program m$ sql szervert tesz fel. Minek? Már van másik, hozzon létre benne új adatbázist, új sémát, aztán onnan dolgozzon.

G

Ha ugy erted megfeleloen elszalltat, akkor oke...

De ez ugye mas model nagygep vs. cluster vitakhoz hasonlo beszelgeteseink lehetnenek ezzel az oracle dologgal kapcsolatosan.

Ez nem a terhelesrol szol

Jellemzoen akarmi, 200q/s nem "annyira" sok. Memoria legyen, de pl 2 proci sem kell.. a terheles most nezem egy 242q/s el rendelkezo gepen .6 mas nem futkos rajta 1GB ram 1.4 P4 1 cpu ext3 query log none (ez fos sokat a nyakadba ennel a mennyisegnel ) binlog on

Mivel ugye a q/s nem sokat mond a terhelesrol (azaz a outer join kezdetu q az picit mas mint a select valami .... egy feltetellel (itt query allott de emiatt szopatott valami biztonsagi modul..) ha az a tabla meg indexelve is vagyon, szoval ez nem kerdes, sot dba-kent ugye sokszor utkozol abba, hogy a programozo kihagyta a relacios adatbazisok temat es dugni jart a malnasba (ezt onnan tom mert a feje piros mikor jon, es nem erti elb@szott valamit es lassu) persze ekkor mar dobalja el a kapcsolatokat 30 perce a szerver...

a terhelesre a slow q szama talan jobban utal, foleg ha ez szazalekosan jellemzo (valoszinuleg a fenti kollega altal programozott cucc nem bir magaval)

A kerdes nem ezen van, hanem azon hogy gyerekenek valo e vagy sem.

Nem tartom magam sysdba-nak korulbelul 70 DB-t adminisztralhatok e kozt van 8 ami oracle. Ebbol 6 helyen nem kellene oracle, de az megiscsak sql... 2 helyen kellhetne, de pl az egyiken a programozas szintjen megalltak a select -nel szoval eselyem nyilt megmutatni, hogy ennel barmi mas gyorsabb(es lass csodat), az utolso helyen meg tenyleg nemtudom miert tartanak 4 ev alatt semmi gondjuk nem volt..

Es a fenti minta abszolutmertekben nem lehet reprezentativ, de nagyon is el tudom kepzelni, hogy ehhez hasonlatos a vilagkep.

Willy wrote:
> En dolgoztam, dolgozok, csak rohogni tudok botor kijelenteseden..
>

Akkor lehet, hogy félreértettél, nem azt akartam kihozni ebből, hogy a
MySQl is meg a Postgresql is sz.r, hanem hogy egy postgresql sokkal
jobban kézre áll annak, aki Oracle-hez van szokva.

Nem lehet inkább rossz marketing?

A postgresql már a kezdetektől egy komplex műveleteket, megoldásokat támogató eszköz volt. És kezdetben (6-8 verzióval ezelőtt) valóban igaz volt: ha ezeket a komplex műveleteket nem használod ki, akkor lassabb, mint a mysql. Nemrég, talán a 7-es verzió megjelenésénél ez már nem volt igaz, viszont "ráragadt", hogy lassabb...

Ezen kívül rettentő lassan, és esetlen módon fejlődött hozzá a grafikus admin interfész, fogalmam sincs, hogy hogy áll most, de azt hiszem, az is rengeteget fejlődött.

Én annak idején, amikor elkezdtem velük foglalkozni, mind a kettőt nagyon alaposan megnéztem, és egyértelműen a postgres mellett tettem le a voksom. Véleményem szerint megéri egy adatbáziskezelőt "rendesen" használni és kihasználni a program tervezésekor, nem pedig a kliensben leimplementálni mindent, ami valójában az adatbázisrétegbe való...

Azt is meg kell hagyni, hogy az 5-ös mysql __rengeteget__ fejlődött feature-ök szintjén. Azt már nem néztem át alaposan, mert mostanra már eléggé benne vagyok a postgresben ahhoz, hogy a fejlesztéseimet azon csináljam, de el tudom képzelni, hogy most már a mysql is elég jó. De filozófiájában biztos, hogy nem tudott postgressé válni... :)

baldvin wrote:
> Véleményem szerint megéri egy adatbáziskezelőt "rendesen" használni és
> kihasználni a program tervezésekor, nem pedig a kliensben leimplementálni
> mindent, ami valójában az adatbázisrétegbe való...

ilyen howtokat egyszeru jozskapistak altal is megertheto szinten nehez
talalni. es amig a kulonbozo mysql for dummies valoban jol bemutatja a
select,insert,update,delete +1 nehany alapparancsot, ra fognak szokni
ezutan a fejlesztok, hogy kliens oldalon parsoljak ki pl. egy tobbezres
select queryjet.

meg aztan a triggerek is csak az 5-os mysqlben jelentek meg, amik
szinten igencsak megkonnyithetik egy db tervezeset, kivitelezest,
konzisztensen tartasat.

addig nincs is baj, amig a jozskapistak a sajat kis osszeeszkabalt
honlapjuk elkeszitesehez hasznaljak a rossz beidegzodeseiket, am amikor
elkezdenek dolgozni a nagybetus eletben, netan olyan kornyezetben, ahol
hasonlo tudasu emberek veszik korul, meg osztoznes sem lesz arra, hogy
jobb/szebb/biztonsagosabb/karbantarhatobb kodot irjanak.

bocsanat, ez mar regen nem a pgsqlrol szol.

Valamennyi biztos hogy kell, ha nem tudok rola hogy igy halad az Ubuntu project, akkor magamban elkonyvelem egy ujabb Debian variansnak, es sose probalom ki.

Aki valaha is dolgozott Oracle-vel, annak meg sem fog fordulni a fejében olyan kérdés, hogy akkor most MySql vagy Postgresql? :)

Ezen kívül rettentő lassan, és esetlen módon fejlődött hozzá a grafikus admin interfész, fogalmam sincs, hogy hogy áll most, de azt hiszem, az is rengeteget fejlődött.

Naponta használom, és bizton állíthatom: teljesen profi gui interfacee van. (pgAdmin). Nagyon jól kezelhető és átlátható.

Szerintem ez kicsit fejlesztoi oldalrol is hasonloan mukodik. Ha adott tobb azonos feladatra specializalt program (akar fuggvenykonyvtar, vagy pont az adatbaziskezelo), akkor amirol tobbet hall az adott pillanatban a fejleszto, amikor a feladatat elkezdi megvalositani vele, arra fog specializalodni.

Egy jo marketinggel ellatott project el tudja hitetni magarol hogy hosszutavra kecsegteto fejlesztesi utemet tud tartani, es terveket tud felmutatni, akkor lehet hogy inkabb az lesz a nyero valasztas, mint egy jo funkcionalitasu, de lassan halado project.

Nyilvan az aktualis pillanatban meglevo dokumentacio minosege es mennyisege is szerepet jatszhat a dontesben, de ez mar inkabb a technikai resz mint a marketing.

A pontosság kedvéért: a Dupal gyárilag telepíthető postgresql-re. (Bár én néha tapsztaltam bugokat.)

Esetleg contributed modulok lehetnek olyanok, ahol a fejlesztő nem vette a fáradtságot a postgresql dump-ot is legyártani.

Mivel a MySql-nél létezik olyan táblatípus,ahol nincs se tranzakciókezelés, se constraint se FK, szóval ezen fogalomkörben jóval gyorsabb, mint bárki. Ezen tr. nélküli "üzemmódjában" bármely opensource cucc mögé rakva a maga egyszerű installjával és hipergyors sebességével, kicsi erőforrás-igényével logikus választás.

Ám amikor már tranzakciókezelés, triggerek, FK, Constraintek is vannak a dologban, belső select-ek (ezt nem szereti szegény), szóval ekkor már 3-5-ször lomhább, mint a pg, bár itt lehetne beszélni a tuningról, meg ne a default teepítés meg ilyesmi, lényeg, hogy régen jó volt "csak" az, amit tudott, de jóval gyorsabban.

Most, hogy a feature-k hozzák a lomhaságot (és a bugokat), jóval inkább kihozzák az egyik nagy öreget, ráadásul még a dialéktust is érti és még gyorsabb, stabilabb is lesz. Az új PGAdmin egyébként már okos, de a mySQL tény ebben előrébb van. Kérdés, hogy ezen a fronton mi a csábítás ereje. Sztem nem feltétlenül a mellé adott GUI-toolok.

Szerintem a legtöbb nyílt forrású projekt fejlesztője azt se tudja, hogy mi fán terem az SQL. Ismeri belőle a selectet az insertet és az update-et, illetve ezek legprimitívebb alkalmazásait és ebből rakja össze a DB hátteret.

Ehhez a hozzáálláshoz a mysql sokkal jobban megfelel, gyorsabban megtanulható, megérthető. A postgres még mindig kicsit "elitista", nehezebb, bonyolultabb, más.

A tudásnak és a teljesítménynek szerintem sokszor nincs köze hozzá.

mysql-hez milyen gui-t lehet hazsnalni? MyADmin -t? Mert az elegge no comment. Az arra jo, hogyha nincs shell hozzaferesed az adatbazist futtato gephez.

Van jobb gui is hozza? (ami mondjuk nem bongeszoben fut, es hasznalhato)

drupalban vanik pgsql support

en elgondolasom alapjan akik most kezdik el hasznalni sql-t, nem sajat serverre csinalnak cumokat hanem valami free helyre, ami foleg mo-n, de vilagszerte mysql van tobbsegben nem pedig pgsql, igy tehat mysqlban fejleszt mert tudja hasznalni utanna...

bar ebbol az elgondolasbol felvetheto az, hogy regebben meg nemnagyon volt sehol, akkor miert, tobben emlitettek mar hogy regebben talan mysql gyorsabb volt, es tapasztalataim alapjan dokumentaciot is lehet ahoz konnyeben szerezni, igy regen picivel tobb projekt lett, jo reklam

A MySQL ellen szól:

1. Szabad forrású ugyan (GPL-es),

de üzleti felhasználásra fizetõs.

2. Valójában 4 féle MySQL létezik:

a) A hagyományos indexszekvenciális fájlokra épülõ,

ez gyorsabb, mint a többi, de nincsenek benne tranzakciók.

b) A Sleepy Cat (pénzes Berkeley DB) motorra épülõ,

ebben vannak tranzakciók, de nem valami stabil.

c) Az Inno DB-re épülõ,

ennek a tranzakciókezelése hasonlít a legjobban az Oracle-re.

d) Végül megvették az SAP-DB-t,

ezt is elkezdték MySQL néven terjeszteni.

Ez már nekem sok volt, szerintem ez egy zavaros, zûrös ügy, itt elegem lett a MySQL-bõl.

Mege,lítem még, hogy természetesen a kölönféle szerverek funkciókészlete és a mûködés részletei kisebb-nagyobb mértékben ugyan, de eltérnek.

Az tehát hiú ábránd, hogy az egységes MySQL kliens interfész könnyû mozgást biztosít a különféle szerverek között.

A Postgres ezzel szemben egy tiszta ügy.

Lehet, hogy vannak hátrányai, de majd fejlõdni fog.

Érthetetlen, de általában a MySQL adatbázisokról nem szokták közzétenni, hogy melyik motorral mûködnek. Pedig az elõbb láttuk, hogy 4 gyökeresen különbözõ MySQL motor van. Tegyük is fel konkrétan a kérdést: Mivel mõködik a HUPWiki, a Google?

A Postgres elõbb említett egyszerûsége úgy néz ki: Kevés információ van róla, hát egyszerû. Valóban többet kellene tudni. Hogyan teljesít a Postgres nagy alkalmazásokban (osztott adatbázis, sok felhasználó sok konkurrens tranzakcióval). Jó volna tudni, mennyire korszerûek az algoritmusai, mennyire tiszta a kódja, azaz mennyi tartalék van benne. Hogy miért nem olvasom el? Mert én az adatbázisszerver felhasználója vagyok, nem pedig a fejlesztõje. Csak tájékozódni szeretnék.

A MySQL gyorsabb, de ez ma már nem minden esetben jellemző.

Ami szerintem fontosabb: a MySQL-t egyszerű adminisztrálni, és nehezen fordulhat elő, hogy "szétbarmolódik" az adatbázisod, esetleg a használhatatlanságig, akár áramszünet, akár más miatt. Pgsql-lel ez sokaknak, sokszor megtörtént (bár a 8-asra már ez sem annyira jellemző). Használni is nagyon egyszerű a MySQL-t, nem kell VACUUM, stb. Azonkívül, ha már a feature-ökről van szó, aki használt már komoly adatbáziskezelőt, tudja, hogy marketing ide vagy oda, a Pgsql jó néhány advanced funkciója háát, még nincs kész, vagy nem annyira jó. A MySQL korábbi feature-hiányosságot bőven ellensúlyozták az olyan, az átlag számára jobban értékelhető dolgok, mint a stabilitás, a sebesség, könnyű adminisztráció, világos tuningolhatóság, jó dokumentáció, perfekt karakterkészlet-kezelés, sok és jó segédeszköz, többféle táblamotor akár adatbázison belül is. Viszont azt gondolom a Postgresql 8-al és a Mysql 5-tel ezek az összehasonlítások részben értelmüket vesztették, némely funkciót, amellyel eddig a kettő közül csak a pgsql rendelkezett, jobban megcsináltak a mysql-ben, és vice versa.

"A MySQL ellen szól:

1. Szabad forrású ugyan (GPL-es),

de üzleti felhasználásra fizetõs."

Mi van?

"d) Végül megvették az SAP-DB-t,

ezt is elkezdték MySQL néven terjeszteni."

Max DB néven terjesztik.

Ez csak a layer megvalósításától függ... A PgSQL fejlesztők tudják (remélhetőleg), hogy miben jobb az adatbázis motorjuk a MySQL-nél, így készíthetnek egy olyan réteget, amely a MySQL-re írt lekéréseket úgy hajtja végre, hogy az a PgSQL-ből a legjobb teljesítményt hozza ki. A kérdés csak az, hogy ennek a layernek mennyi ideig tart kitalálni, hogy mi a legoptimálisabb lekérés amit a PgSQL enginenek kell adni, mert előfordulhat, hogy mire ezt kisakkozza, addig a MySQL "natívan" már végzett a feladattal.

Egyszeruen nem hagy a kakak kozepen, azaz nem alsz ott osszeomlott adatbazissal es szettepett idegekkel, mikozben a pg azert ezt szepen ossze tudja hozni..

En dolgoztam, dolgozok, csak rohogni tudok botor kijelenteseden..

Leirt ok letezik, sajnos ezt kell mondani, nade az ok es az okozat kozotti osszefugges nem epp eros.

En pl hasznalok MaxDB-t (imho fos mint az allat foleg dokumentacioban, es kliens tamogatasban) oracle-t (en a windowst sem szeretem mert nem latok bele, ez valamennyire megy de ugyanugy korulmenyes) firebird-ot (szerintem egy kalap ***** de ugye a win* fejlesztok szerint isten) pg-t (mostanaban jobb, de regen egy kalap ***** volt a megbizhatosag, fejreallas eseten tutko kudarc, te meg tolthetted vissza az inkonzisztens mentesedet amiert szetrugtak a picsad stb,) es hasznalok mysql-t is

meg a winyo crasht is kibirta egyszer.. ha akarom tud tranzakciot, gyors es szinte minden nyelvben nativ es jo tamogatottsaganak orvend. A szolgaltatoknak kedvezo licenc miatt elegge elterjedt. Sokan azt mondjak gyerekjatek, nekem van 6millio rekordos adatbazis tablam is stabil es gyors, de emlithetnem a 200 folotti masodpercenkenti queryvel rendelkezo szervereket is, ez nem gyerekjatek. Egy eve kezdtem hasznalni sqlite-ot, csak az a bajom vele h lassu (a fejlesztok leiirasaval ellentetben)

A harmadik ok hogy a rengeteg projekt ongerjeszto folyamatkent hozza a mysql-t az okok inkabb ezekben keresendok..

>>1. Szabad forrású ugyan (GPL-es), de üzleti felhasználásra fizetõs."

>Mi van?

Penzert kaphatsz a Mysql AB.-tol nem GPL-el licenszu verziot. uzleti felhasznalasra termeszetesen ingyenes, de ha neked a kod kell (mire?) nem GPL-el licensszel, akkor az is megoldhato.

A 8-as pg-ben már van egy külön autovacuum démon. Hangolható, mikor mennyit hogyan miért. Kávét nem főz viszont. :-D

Micskó Gábor wrote:
>>Mivel mőködik a HUPWiki
>
>
> Sima MySQL szerver 4.0.26

gondolom itt inkabb a db tipusara volt kivancsi. myisam, innodb stb. ha
nem, akkor sorry.

Hát azért ez nem olyan extra sok. Az egyik kezem alatt lévő szerver a Munin tanúsága szerint (az utóbbi egy hétben) 147,22 q/s-ot szolgált ki, de az elmúlt napban volt 160 is (persze ebben a cache hit-ek is benne vannak). A load meg olyan 0,4 és 3 között ingadozott. Duál P3/1,4 GHz, 3,5 GB RAM, hardveres SCSI RAID alatta. 2.4.31-es kernel, alap Debian-féle 4.1-es MySQL, Ext3 fölött a MySQL, mert az XFS-sel durván besz*ptam. :I

Ezt aláírom. Egyik ügyfelünknél vas-problémák miatt az utóbbi időben az irodai backend szerver többször is megdöglött. A MySQL némi mysqlcheck -r után simán folytatta a dolgait szépen.

Mikor en neztem par eve, akkor azert dontottem a mysql mellett, mert tudta, amit kell (innodb reven), es ketszer gyorsabb volt a postgres-nel. Persze nyilvan azokat a muveleteket teszteltem, amit hasznalt is a szoftverunk.

Mondjuk a mysql tenyleg strapabirobb, ha aramszunetrol van szo. Ki lehet rakni egy raw device-ra a komplett adatbazist, ami cache-letlen. A filerendszer hibai kikerulve, maris jocskan ravert a psql-re.

Nem sok

De a 200q/s kiszolgalni kepes dolgokat nem szabad gyerekjateknak tekinteni...

Legalabbis sztem:)

Pedig ugyanez a szindroma... XFS-el is az a baj mint a pgvel, amig fut, lehet szeretni, de ha megall akkorat szopsz hogy hozzadkepest a lila torkos boci az alpokban szikar oktatasi peldanak tekintheto..

Emiatt hanyagoljak sokan..

Altalaban az szokott lenni a problema, hogy sokan nem ismerik elegge a postgrest, pedig komoly adatmennyisegnel kell tunningolni a postgrest. Sot az adott vastol is fugg hogy milyen parametereket kell beallitani. Volt amikor 1 hetig bongesztem a query logokat teszteltem a query plannert, neztem a costokat, de vegeredmeny volt amikor 10x gyorsabb volt, es akkor meg az indexek helyes hasznalatarol nem is beszeltem. Szoval nem egyszeru a postgres viszont ha jol belovik akkor gyors es birja a terhelest. Talan azert nem olyan elterjedt, mert erteni kell hozza.

Ha eladod a programodat választhatsz:

1. GPL liszensz alatt adod ki

2. Veszel liszensz-t és azt adod a programod mellé

hogy jelentkezik az problema? (nem szeretnek meglepodni, mert a tiedhez nagyon hasonlito boxon van tobb tizmillio rekord; nem webszerver, aranyaiban sokkal tobb insert megy ra, mint select; az ext2->xfs atallas elott jo ideig stresszteszteltunk)

ext3 na

Jujujuj, most kihuztad a gyufat :-(

Mármint mivel? :) Megírtam már párszor itt is, hogy az XFS MySQL alatt *****ó, keményen. A fönt említett gép jópárszor megdöglött emiatt, olyan szinten, hogy a szervízproci watchdogja resetelte. Konzolhoz sajna nem jutottam hozzá, mert minimum fél óra, amíg taxival beérek az ISP-hez és addig nem állhat a cucc napközben, így egészen pontosan nem tudom a hiba okát.

Nagy nehezen sikerült egyébként rájönni, igen sok Kuglizás után, hogy ez a gond. Ráadásul a megvilágosodást okozó néhány listapost a 2.6-os kernelről szólt, tehát pár verzióval ezelőttig még jó eséllyel abban is benne volt ez a hiba az XFS kódjában.

Hirtelen felindulásból ezért a kérdéses partíciót átformáztam Ext3-ra, ami ugyan kissé lassabbnak tűnik talán, ellenben azóta is a cucc atomstabil. :)

Egyszerre válaszolok erre és az előző postodra: több oldal generálja a terhelést és a webszerver Munin által mért napi/heti átlagtalálata perpillanat 10,34/9,93 másodpercenként. Apache 1.3 Debian Sarge-ból, kicsit patkolva. Ergo ezen nincs igazán terhelés, egy-két site szereti tekerni a MySQL-t. :)

Ott van fönt a leírás, a probléma úgy jelentkezik, hogy a gép - valszeg - blokk I/O rétege merevre fagy. :)))) Pl. az SSH a kapcsolódásig eljut, bannert kirakja (ha telnettel nézed), de utána konyec filma. Pingre szintúgy válaszolgat a kernel, tehát a hálózati része életben marad.

Linket hirtelenjében nem tudok idézni, ami alapján rájöttem a titokra, de megpróbálok.

Gondoltam egyébként arra, hogy a MegaRAID2-es driver a gázos, de az említett postban valaki más RAID-cuccot használt, ezért csak az XFS maradhatott a húnyó.

MySQL cluster ami 4.1-től van a MqSQL-ben, pont így működik, nincs master-slave, egyenrangú (adminisztrálásához kell egy külön db egyedül).

Micskó Gábor wrote:
>> de emlithetnem a 200 folotti masodpercenkenti queryvel rendelkezo
> szervereket is, ez nem gyerekjatek.
> Hmm, ez pont 10-szer tobb, mint a HUP terhelese egy eros delutanon...
> Milyen vas van ezalatt? Mennyi ram, stb.?
Válaszolok Willy helyett: itt van egy gagyi asztali gép, webhosting fut
rajta, mindenféle elkefélt queryvel (szokás szerint), ráadásul, hogy még
rosszabb legyen a helyzet, FreeBSD-n (a mysql köztudottan Linuxra van
írva, de annyira szarul, hogy még ott is lassú :).

Átlagban 500 qps, de van, hogy 800-1800-ig is felmegy. Szerencsére a
legtöbb queryt cache-ből tudja adni.

Willy wrote:
> Nem sok
> De a 200q/s kiszolgalni kepes dolgokat nem szabad gyerekjateknak
> tekinteni...
A komolyság nem itt kezdődik. :)

Willy wrote:
> En dolgoztam, dolgozok, csak rohogni tudok botor kijelenteseden..
(no offense) én pedig már láttam igazi Oracle DBA-t is. :)