mysql ellenérvek

Adatbázis: SQL, XML DB

Sziasztok!

Sokan fikázzák a mysql-t, hogy komolyabb dolgokat ne bízzunk rá, ha fontos a teljesítmény, akkor használjunk mást.
Valakinek van esetleg valami gyakorlati, rossz tapasztalata ezügyben?

Minap próbált valaki meggyőzni, hogy az mssql szerver tulajdonképpen mindenben jobb, mint a mysql... Gyorsaság + megbízhatóság + több gép közti megosztás, ezeket emelte ki. Szerintem nem feltétlenül volt igaza, bár a mssql szerverhez egyáltalán nem értek.

  • 7034 megtekintés

( x-daemon | 2007. 06. 26., k – 02:18 )

tapasztalataim:
sebesseg: nem mindegy melyik verziot hasonlitod ossze. nalunk egy mssql 2000 2G RAM korlatos verzio van, ennel a mysql 5.0 ugyanazon a vason - linux alatt - 1 nagysagrenddel gyorsabb. persze ennek a merteke lehet tabla fuggo is.
megbizhatosag: mssql gyakran deadlockba kerul ilyenkor ujra kell futtatni a queryt.
tobb gep kozotti megosztas: mit ertel ez alatt?

terheleselosztast meg lehet csinalni mysql alatt, akkor mukodik hatasosan ha az olvasasi muveletek szama tobbszorose az irasi muveletek szamanak. kell egy irhato master adatbazis es tobb pl. 8 olvashato replika. valodi clustert 5.0-as mysql-ben csak memoriaban tarolhato tablaval lehet csinalni :( - ndbcluster backend - ez az 5.1-ben mar olyan lesz hogy a tablakat hattertarolon tartja az indexeket memoriaban, tehat ez a resze meg valoban nem tart ott hogy "automatikusan" :) elossza a terhelest, feladatnak megfeleloen fel kell epiteni a rendszert.

( pinyo_villany | 2007. 06. 26., k – 07:54 )

ha jól tudom a google alatt is mysql van, de javítsatok ki, ha tévedek

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-rc6-wifi0 - kernel itt

( Jason v | 2007. 06. 26., k – 08:20 )

A mysql-t eloszeretettel fikazzak es foleg oracle buzik, mert kevesebb feature van benne AMDE joval gyorsabb.
Ha nagyon tranzakciozni akarsz meg plsql-ni, akkor postgresql, az oracle klon, gyorsabb is nala(marmint oracle-nel).
Ha nem kell a sok ficsor meg bloatware, csak a sebesseg, akkor mysql.
Ha a megrendelo szerveren csak oracle van, akkor oracle.

Ugye mindig feladathoz valasztod az eszkozt es hatlapcsavarhoz nem hekkelsz torx csavarhuzot.

Mire akarod hasznalni?

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

Az adatbáziskezelő kezelő használhatóságát erősen befolyásolják a hozzá renddelkezésre álló tool-ok is. Oracle-höz rengeteg tool van.

Postgresql-t használva(JDBC-vel) rengeteg bugos, meg workaroundos dolgot sikerült fellelnem. Főleg mikor BLOB-ok(fájlok) tárolása került szóba.

Ja az eredeti kérdésre: ténylg nem ártana tudni, hogy pontosan mire kell. A dolgok 90%-ára MSSQL, MySQL, Oracle, Postgres egyaránt megfelel. A többihez meg kell egy adatbázis guru is :-).

Mire használnánk?
Egy közösségi oldalon dolgozunk másfél éve...
Eddig mysql-t használtunk, majd a megrendelő szerzett még programozókat, és az egyik közüllük nagy mssql buzi: megpróbált minket meggyőzni, hogy hibás az eddigi modell, a terhelés növekedésével egyszercsak a mysql maga alá fog fosni, és akkor majd nézünk nagyokat. Mígha mssql-t használunk, akkor pusztán hardware váráslással megoldódhat a problémánk, hiszen az mssql képes elosztani (automatikusan) a gépek közti terhelést.

Egy közösségi oldalt tartunk fenn, mysql van alatta, ésszel használva nagy terhelések mellett (többmilliós napi oldalletöltés) is működik. Kis vállalati rendszerben pedig szívtam már mssql-lel, mert egy elődöm (majd a mindenható MS megold mindent alapon) ész nélkül programozta le. A tapasztalatom az, hogy a körültekintő tervezést nem pótolja semmi, legfeljebb a tervező ostobaságát képes ideig-óráig elfedni.

Mi az oldal neve (ha nem titok:P)? Terheles tesztekkel eleg gyorsan ki lehet deriteni, merre vannak esetleg problemas reszek, es egyaltalan mit bir a rendszer. Az mssql persze nem rossz, de a hangsuly a "vasarlas"-on van ;-)

Egyebkent nagyon horribilis dolgok tudnak szuletni, ha a fejlesztok csak adatbazisban tudnak gondolkodni - pl.: egy sima user-user uzenetkuldes is csak sokgepes clusteren tud kiszolgalni 1000 usert :P

nem titok.

www.mindenki.hu
nem reklámozzuk sehol még, még nincs benne user-user üzenetküldés, de készülőben van.
Jelenleg 3100 felhasználó van, napi 20-30 regisztrálóval, és kb napi 300-an lépnek be. Belső üzenetküldéssel az oldal interakítvvá vállik majd: a userek tovább bent lesznek, több időt töltenek bent, jobban megszeretik, több ismerősüknek ajánják, azaz több regisztráló is lesz, és hamar elérhetjük a mostani szerverünk kapacitásának a végét.
Jelenleg egy ubuntu 6.06 server fut, mysql 5.0-val, és php5-el. A vas egy sima pc, duál magos xeon 3.2 ghz-el, és 2 gb rammal.

Elméletileg, persze. Gyakorlatban jóval kevésbé működik, sajnos.
MSSQL-hez kell hardvert vásárolni (meg oprendszert is) dögivel. Ugyanazon a vason brutálisan gyorsabban fut a MySQL.
Én találkoztam éles projektben is MySQL-el, 100millió soros táblák, 8 cpu-s server 32GB RAM-mal. Vaddisznó gyors.
Dehát értettek hozzá akik csinálták.
Nekünk PostgreSQL-lel van tapasztalatunk. Azért szeretjük, mert kevésbé vannak korlátok, amikbe a projekt végefelé szokás belefutni.

Az okosok egy része azt mondja, hogy adatbázis-függetlenül kell csinálni a projekteket. Ez a tervezésre mondjuk igaz is, viszont ha lehet, akkor érdemes adatbázis specifikusan implementálni, mert egyrészt sok időt lehet spórolni, másrészt sokkal gyorsabb dolgot lehet csinálni.

Terheléselosztást bármilyen adatbázissal lehet csináni, ha mondjuk C-JDBC-t használ az ember. Még akár különbözőek is lehetnek a cluster adatbázisai :)

--
Gabriel Akos

Csodak nincsenek, kulonosen adatbazis teruleten nem. Sokszor hiaba van brutalis vas az adatbazisszerverhez, alkalmazashoz ha egesz egyszeruen keptelenek azt hatekonyan hasznalni a nem megfelelo megoldasok, algoritmusok miatt (ez kulonosen igaz az adatbazisrendszerekre).
Gyakori mondas, hogy a fejleszto ne azzal toltse az idejet, hogy hatekony kodot irjon, inkabb majd pakoljak az alkalmazas ala a vasat - persze azota mar sokan rajottek, hogy ez sok esetben szamarsag, mert az infrastruktura fenntartasa es uzemeltetese is igen draga tud lenni :)

A MySQL MYISAM formatuma nagyon konnyen egy lock storm kozepen talalja magat (bovebben lasd tomegkiszolgalas, sorbanallasi problema cimszo alatt), ha ugyanazon adatokat tobben is megprobaljak parhuzamosan olvasni/irni. Az InnoDB ebbol a szempontbol jobb, de a tobbprocesszoros mukodessel gondjai vannak - a buffer pool lockolasa nem az igazi (ezt talan a legutobbi verzioban mar fixaltak).

Jogos, helyzet valtogatja.

Bar, lattam en mar oracle farmot, olyan kverik futottak 25-26 orakig amik, hát ha a java kontenerben tarolt szirszar eljarasok nem ettek volna fel mind a 40 gep memoriajat, 3-4 ora alatt lementek volna.
Bolcsen kimaradtam a dologbol, oldja meg, aki akarja, bar ha lotus notes-ot adatbaziskezelonek(nem r!) hivjuk, akkor ahhoz kepest meg az oracle is egy csoda.

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

Valóban, az Oracle közel sem tuningolható annyira, mint a PostgreSQL. Az Oracle RDBMS mint olyan egyáltalán nem akkora durranás. A köré rakott egyebek között vannak szépségek (warehouse pl.)
Nem becsülöm le az Oracle-t, de egyáltalán nem vagyok hasraesve tőle. Jó cucc az, de én nem fizetnék érte, az biztos.

--
Gabriel Akos

Muhahah... PostgreSQL, mint ami jobban tuningolható... B+, ha sérvet kapok a röhögéstől, akkor te fizeted az egyágyas kórtermet!

Ja, hogy ahhoz érteni is kellene, hogy tuningolhasd? Ó, hát igen...
Tudod, ez nem Dzsunkatech és Fusitron összefogásból készül lelkesedésből, tehát nyilván nem lesz túl egyszerű tuningolni, meg úgy egyáltalán bármi komolyat csinálni vele, hiszen a cég, aki gyártja, kőkeményen profitra törekszik, és a profitját csekélyebb mértékben szerzi eladásokból, mint inkább szolgáltatásból. Az éves support díj az Oracle esetében a termék árának harmada. Ha valami bonyolultat akarsz csinálni, kihívod a szakértőt napi 1000+ $-ért. Ha hangolni kell valamit, dettó.
Ebből élnek, ezt el kell(ene) fogadni. Viszont cserébe a technológiában is élen járnak, tehát kapsz is vmit a pénzedért. Ha nem így lenne, senki nem venné.

Bevallom, hogy az Oracle tunninghoz nem nagyon ertek, csak arra tudok hagyatkozni, amit az egy Oracle DBA haverom mondott, hogy az Oracle nagyon tunningolhato. En postgressel foglalkoztam sokat, 100-200 tablas 20-30GB adatbazisokon, futott iszonyu bonyolult statisztikai lekerdezesek, es ott nagyon fontos volt az optimalizacio es tunning, ebbol a szempontbol a postgres tunning parameterek jol dokumentaltak, az ertekek megvalasztasa viszont fugg az adott vastol es a lekerdezesektol. Ilyenkor az ember eloveszi a query plannert nyomja az explaineket, finomhangolja a Generic Query Optimazert, amiben szerintem a Postgres nagyon jo. Tehat a nagy kulonbsbeg az hogy Postgresnel nem kell a kurvadraga szagertot kihivni , te is megcsinalhatod, de attol meg erteni kell hozza. Sajnos a Postgresbol hianyzik az ami az Oracleben a RAC, de mint adatbaziskezelo az esetek 90%-ban ugyanolyan jo.

Aham... És szerinted a postgres honnan "kölcsönözte" ezeket a feature-öket? :)
Tudom, nem Oracle-klón, ahogy itt már sokat kifejtették, de azért a kezdetektől úgy fejlesztették, hogy hasonlítson, ahol lehet.
Ebből, meg az általad leírtakból kicsit továbbgondolva leszögezhetjük, hogy ha el vagy ájulva a postgres tuning paramétereinek dokumentáltságától, meg a tuning hatékonyságától, akkor az Oracle hasonszőrű dolgaitól egyből eszedet vesztenéd. Amit nem értek, hogy az emberek miért olyan rohadt lusták olvasni, dokumentációt keresni... Az összes releváns dokumentáció tök szabadon hozzáférhető, de majdnem minden kis bitfaragó kiscserkész (és itt nem rád gondolok) azon rinyál, hogy "jajj, de bonyolult, jajj de nehezen kezelhető, jajj, de hát ahhoz pilótavizsga kell". Nos igen, az Oracle db egy nagyságrenddel bonyolultabb eszköz, mint pl egy postgres, nyilván bonyolultabb is bizonyos dolgokat kihasználni benne, de ez azt hiszem, egyértelmű. De ezek csak nyivákolnak, mint a bagzó macska, és istenítik a mysql-t, mert sose láttak mást.

Nem leszólni akarom a mysql-t, vagy a postgres-t, mert egy csoda, hogy egy open source közösség ilyet képes alkotni, de azért ez az összehasonlítgatósdi amit itt sokan folytatnak olyan, mintha most azt mondanánk, hogy minden, az internetet kiszolgáló gerinchálózati router-t cseréljünk linux-ra, mert az mindent tud, amire szükség lehet. Tényleg lehet, hogy sokmindent tud, de valamiért bizonyos szint fölött mégiscsak a Cisco nyer, és nem véletlenül.

A másik, hogy 20-30 gb-os adatbázis, az igencsak kicsinek számít... :)
Szóval azért mikor 100 GB fölötti adatbázisokkal kell játszadoznod, meg a fölött (netán tera fölött), ott már megnézném, mikor, kinek, hogy jön ki az, hogy gyorsabb a mysql meg a postgres, mind az oracle, vagy a db2.

a klónság egészen mást jelent. A CentOS pl. Redhat klón.
A PostgreSQL belül teljesen más mint az Oracle.
Az, hogy alternatíva kíván lenni, az érthető, elég sokan szeretnének lemászni az Oracle nevű drótkeféről :)
Egyébként amekkora respektje van, egyre kevésbé lényeges imho , hogy Oracle klón legyen, mostanára inkább a legújabb szabványok 100% követésére mennek rá.

--
Gabriel Akos

A postgresql nem oracle klón, hanem egy másik ACID adatbázisszerver, több közük nincs egymáshoz. (amúgy oracle: 1 teljes cd: db server, webes cuccok, alkalmazáskészítő, leírás; ezzel szembe postgres: ~ 10 MB; oracle indulásképp lefoglal fél gigát adatterületnek, postgres csak amennyire szüksége van, stb. Oracle megbízhatóbb és több dolgot tud, viszont sokkal drágább!)
Akinek az ACID szó nem mond semmit egy adatbáziskezelőnél, az azt se tudja, hogy mit tekintünk adatbáziskezelőnek és mit "sql fájlrendszernek". A mysql sokáig ez utóbbiba tartozott.

Nem ertem a mult idot. namindegy.

Sztem valahol meg mindig az es sosem fog tudni elszakadni igazan a multjatol (lasd: honnan, mibol indult). Bar amire mostansag hasznaljak, arra qrvajo.

Ha az oracle is sqlfs-nek indult volna akkor nem tartana itt :)
Egy alkmatos ismerosom meselte, hogy az oracle tobbek kozott azert olyan jo (meg lassu:P), mert minden funkcio matematikai modellje helyessegbizonyitott.

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

( ZebraZ | 2007. 06. 26., k – 08:50 )

Üdvelet!

Minden azon múlik, hogy mire és hogyan szeretnéd használni. Pl. ha sok adatbázisod van MySQL alatt (kb 20-30 GB felett - 200 adatbázis), valamint sok az írás különféle adatbázisokba, valamint a programozó srácok nem igazán a performanciára figyelnek és még az indexek is furák. Na akkor egyhamar bármilyen erős vas alól is kifogy az IO.

Ennek oka, hogy ha írás van az adatbázisba, akkor az megváltoztatja az adatbázisod (táblád) fájlját, valamint a hozzá tartozó indexet is újraépíti. Ez elég nagy írási és olvasási sebességet várhat el a háttértáradtól.

ÁMBÁTOR -> minden ilyen dolgot okosan ki lehet küszöbölni.

Én elég sokat dolgoztam/dolgozok MySQL szerverekkel és Oracle-el is.
A kettő más világ. És meg vagyok arról győződve, hogy mindkét oldalnak megvan a maga létjogosdultsága. Valamint arról is, hogy egy jó tervezés és a performanciára való odafigyelés minden esetben meghozza a gyümölcsét.

Hát bizony ez így van: bármilyen vasat képes szétterhelni a mySQL. 1179 - ennyi adatbázis fut egy 4 magos Xeon Woodcrest vason, másodpercenként 600-900 lekérdezés mellett. Nem a sima lekérésekkel van a baj, hanem a query-kkel. A sima lekérésekkor a load 0.6-1,5 körül van, no de amikor az ügyes kódok párhumazamosan elkezdenek műveleteket csinálni (sokszor indexálás nélkül, stb.), 10-15-re is felmegy a load.

Figyelni kell a konfigra is, mert egy terheltebb szerver "gyári" mySQL-konfiggal könnyen lehal... :-)

( sj | 2007. 06. 26., k – 10:12 )

En egy spamszuro backend-jekent hasznalom a MySQL-t, es ha valahol, hat ott fontos a teljesitmeny: sok select, valamivel kevesebb update, es ehhez kepest meg kevesebb insert. Query cache-t hasznalva megfelelo/eleg jo teljesitmenyt ad. Szoval en meg vagyok elegedve a MySQL-lel.

ASK Me No Questions, I'll Tell You No Lies

Ha pl. az SA-val veted ossze, akkor az felismer ~70% spamet, mig a statisztikai szurok lazan 99.5%-t. Kb. 60x jobb pontossag. Hat ebben. Meg abban, hogy tanulni kepes. Ha tevesen kategorizal egy levelet, csak kattintasz 1-et, megtanulja, es kesz. Mig SA-nal beletorodsz, hogy ez van, vagy kezdhetsz rule-okat tweak-elni, aztan good luck. A jobb teljesitmenyrol (Perl vs. C-bol optimalizalt gepi kod) meg nem is beszeltunk.

ASK Me No Questions, I'll Tell You No Lies

Igen, hasznal(hatsz vele), es igen, a spamd sokat dob(hat) rajta. Kivancsi vagyok egy adott honapban (mondjuk eddig juniusban) milyen pontossagot ersz el vele, hanyszor hibazott, kell-e hozza feherlistat hasznalnod, stb.

Az SA egy csomo modult kepes hasznalni, pl. rbl-ek, feherlistak, razor/pyzor, a millio rule, + statisztikai modul. Azonban a Bayes-i elemzes csak a lanc vegen szerepel, azaz elegge lebutitott uzemmodban fut. De hadd magyarazza el (nalam sokkal ertelmesebben) Zdziarski:

"SpamAssassin, for example, was (and still is for the most part) one of these types of filters, however they've recently added a statistical "component" to the filter. So now it's not a heuristic filter and it's not a statistical filter - it's more like a gas/electric hybrid. If you're one of the 27 people who drive a gas/electric hybrid, you probably realize it's not particularly powerful. This also represents how most appliances are built today - several layers of heuristic tests and then stick a Bayesian element in at the bottom. Hybrid filters don't seem to be quite as powerfil either as they're more of a hodgepodge of tools thrown together than any type of technologically meaningful solution. In fact, due to what I call heuristic programming, any statistical components in the solution can end up acting dumbed down as a result of being told what ham and spam is by lesser-accurate (namely heuristic) parts of the filter. It seems rather asinine to use the less accurate portion of the filter to train the more accurate portion, but that's how most hybrid filters are concocted today. Statistical filters will learn whatever you tell them to, so naturally when they're trained by something dumber than a human, they're going to react dumber than a human. I've talk to many people today using commercial appliances based on either SpamAssassin or some other hybrid model, and it's quite scary to hear that they're still deleting spam out of their inbox by the dozens."

http://www.zdziarski.com/papers/justifying.html

ASK Me No Questions, I'll Tell You No Lies

Igen, valoszinuleg arra gondolt. A kulonbseg pedig az eredmenyben van. Te hany spamet kapsz 1 honapban, es ebbol mennyit ismer fel az SA-d a Bayes-i modullal egyutt? Ha nem kapcsolod azt be, akkor van egy 70%-os pontossagu szurod. Hogyan valtozik az eredmeny, ha bekapcsolod? Elersz vele 99+% pontossagot? Mennyi eroforrast (cpu, ram) kot le? Parhuzamosan hany levelet bir feldolgozni? Mennyit 1 ora alatt?

ASK Me No Questions, I'll Tell You No Lies

Viszonylag sokat, de ennek oka van: alig van szűrés a mailboxomon. :)
Hogyan változik: jelentősen.
99% pontosság: nem végeztem ilyen irányú méréseket.

A SA erőforrásigényes, ez tény, cserébe azért elég sokmindent csinál (rule-ok, nyelvfelismerés, bayes, stb). Megkockáztatom, hogy ugyanezt megcsinálnád C-ben, a te megoldásod sem lenne éppen gyors. :)

99% pontosság: nem végeztem ilyen irányú méréseket.

Ha lesz egy szabad fel perced, megnezhetned, mert erdekel a dolog.

Megkockáztatom, hogy ugyanezt megcsinálnád C-ben, a te megoldásod sem lenne éppen gyors. :)

A spam1.txt-det mennyi ido alatt kategorizalod SA-val? Btw. eppen az a poen, hogy nem ugyanezt kell C-ben implementalnod, hanem valami egeszen mast, ami cserebe raadasul jobb is :-)

ASK Me No Questions, I'll Tell You No Lies

Nem engem szólítottál meg, de írok:

Spamassassin fut, bayes szűrővel. A ponthatárokat kicsit levittem, a statisztikai szűrő által adott pontokat 50% felett megemeltem.

Naponta kb. 1200 levél érkezik a gépre, ennek kb. 50-75%-a spam.

Az emberektől (van kb. 25 felhasználó meg 2 levelezőlista) kértem, hogy ha valaki spam-et kap, szóljon, és akkor majd tanítunk. Eddig senki nem szólt, hogy spam jött volna.
Ami be szokott néha esni, a lev.listára kb. heti egy-két levél, ami ismeretlen feladótól jött, és spam.

A bayes szűrőt kézzel szoktam tanítgatni a levlistánál megfogott levelekkel, meg az általa karanténba tett spamekkel.

Szóval szerintem a 99+% pontosság megvan. Erőforrás: a gépet ez a forgalom egyáltalán nem terheli le, nem tudom, mennyi lenne a kapacitása, stressz teszt nem volt.

G

Nem pont a spamassassin rule alapú részére, hanem a statisztikaira gondoltam.

Lenne egy kérdésem.

Van két teljesen azonos spamem:
http://people.fsn.hu/~bra/spam/spam1.txt
http://people.fsn.hu/~bra/spam/spam2.txt

Az ilyen jellegűeket hogy ismered fel (ill. milyen hatékonysággal) és hogy éred el, hogy egy felhigított adatbázissal ne nőjön a false pozitívok aránya?

*108. nbsp+file (3762089525271396111) 0.0001 1
*107. EMBED* (7483434266038931321) 0.9999 1
*106. the+general (4052006121316921691) 0.9999 4
*105. would+receive (15976007169991334141) 0.9999 2
*104. IMAGE* (7483996357091406636) 0.9999 1
*103. she+has (10053755815145061077) 0.9999 2
*102. since+had (1037514816243532409) 0.9999 2
*101. she+knew (4668260387673678200) 0.9999 2
*100. the+young (16975760900445530504) 0.9999 2
*99. that+day (6880385495948816435) 0.9999 2
*98. and+asked (9139364393696499649) 0.9999 2
*97. the+meaning (4232931118242364889) 0.9999 2
*96. body+you (946471886575773721) 0.9999 2
*95. for+instance (18341375218773084059) 0.9999 2
*94. long+time (1258478331452993289) 0.9999 2
*93. the+girl (6880954418528045568) 0.9999 2
*92. had+the (10181134560870918518) 0.9999 2
*91. that+she (6880385495945944047) 0.9999 2
*90. heard+the (6244593988701621300) 0.9999 2
*89. mind+that (10400941804286448964) 0.9999 2
*88. not+nbsp (4274937709967116388) 0.9999 1
*87. knew+you (3294682324346736602) 0.9999 2
*86. value+and (5471258715761747084) 0.9999 2
*85. but+what (839572175614814958) 0.9999 2
*84. your+way (7802131326963663579) 0.9999 2
*83. 6.00.2900.3028+name (7249445795970949799) 0.9999 1
*82. the+prince (11751313827241548697) 0.9999 4
*81. mshtml+6.00.2900.3028 (8459113188405492426) 0.9999 1
number of tokens: 109, most interesting tokens: 28, used: 28
top10: 28, truespam: 27, truespam/top10: 0.964286
with esf_h: 1.000000, esf_s: 1.000000
phrase: 1.0000, single token: 0.5000
Bayesian result: 1.0000
1 0 0
spam1.txt: 1.0000 in 80 [ms]

Ezt eleg jol felismerte (~100%) spamkent, tele van olyan token parokkal, amelyek nalam csak spamben szerepelnek.

De nem igazan ertem, hogy mi az a "felhigitott adatbazis", egyaltalan miert higulna fel? Ha vacak az szotar, akkor az eredmeny is az lesz. Vagy nem ertettelek meg...

ASK Me No Questions, I'll Tell You No Lies

Arra gondolok, hogy egy rakás spam az ilyen jellegű statisztikai szűrőkre játszik, azaz olyan szavakat, szókapcsolatokat tartalmaz, amelyik normál (angol) levelezésben is előfordulhat és ezáltal nő a false pozitívok aránya.

Továbbá kérdés, hogy mindez multiuseres környezetben, ahol a user:
a. nagyrészt nem fog spamet reportolni
b. ha reportol is, sokszor olyat is, ami nem az (vagy másnak nem az)
c. hamet önmagától biztos nem reportol
mennyire alkalmazható egy ilyen.

Ill. mi a helyzet azokkal a spamekkel, amelyek kizárólag egy darab képet tartalmaznak, szöveget nem (OCR-t pls. ne :)?

Nem az szamit, hogy milyen szavak vannak a "normal angol" levelezesben, csak az, hogy te milyen leveleket kapsz, es mivel tanitod a szurot. Ha "normal angol" szoveget tartalmazo levelekkel is tanitod, mert szoktal ilyet kapni, akkor nem lesz fals pozitivod (ok, nem 0.000%, de valami nagyon keves).

Ha en lennek egy multiuseres kornyezetben, fognek egy halom spam ill. ham levelet (2-3-4-5000), elvegeznem azokkal a kezdeti tanitast (=globalis adatbazis). Aki nem akarja maga tanitani a szurot, annak olyan lesz a pontossaga, amilyen. Aki azonban jobbat akar, es kibir egy fix email cimre forward-ot attachment-kent (amit egy program automatikusan feldolgoz, es tanitja a szurot), annak 99.xx% pontossagu lesz a szuroje. A rendszergazda sajat statisztikaja a legjobb motivalo ero, amikor 99.[678][0-9]% pontossaggal bosszantja a lusta juzert, hogy neki is lehetne ilyen jo, ha hajlando lenne tanitani o is a szurot (amit az ido haladtaval egyre ritkabban kell).

Ha pedig ham-et nem riportol (jobban mondva tanit), akkor bizonyara tobb levelet kell a spam karantenbol/mappabol elszednie vagy a spam limitet jol fel kell neki emelni (99%-hoz kozel).

Ha egy adott user pedig elbenazza a riportolast, worst case a sajat adatbazisat rontja el. A statisztikai szurok java szemelyre szabhato. A dspam, clapf, ... tud un. merged group-ot, amikor a felhasznalo eredmenye a globalis adatbazis + sajat szotar alapjan all ossze. Ehhez ugyan tobb storage kell, de jobb eredmenyt ad.

Kiprobaltam en is az OCR-t a spam kepek ellen, mersekelt sikerrel, es zabalja az eroforrast (fork-olnom kellett, es jo 3-400 ms alatt futott le a gocr), arrol nem is beszelve, hogy 50-60% kepbol tudott ertekelheto eredmenyt kinyerni.

Az en mostani image spamjeim (English) szosalataval (word salad) vannak koritve + benne a kep. Ezeket csont nelkul fogja. A problemat ugy igyekeztem megfogni (tanitott szuronel jarhato), hogy ha a level nem eleg jo (>45% spam valoszinuseg), es kep van benne, akkor az spam. 1-2 fals igy becsuszott, azokkal tanitottam, es onnantol (remenyeim szerint) ok a dolog.

Szerk: ja, es mostanaban meguntam, hogy ho elejen mindig beesik 2-3 spam, ezert vagy 2 hete egy spec. tanitast alkalmazok, hogy minden tuti ham vagy tuti spam levelbol az ismeretlen tokeneket megtanulja, es szepen tolti a sajat szotaramba. Ezt megfejeltem egy honeypot email cimmel, ahova omlik a szemet, igy a szuro ugy ismeri meg a legujabb spam trendet, hogy nekem nem kell vele talalkoznom.

ASK Me No Questions, I'll Tell You No Lies

Minden level tartalmaz egy egyedi azonositot a fejlecben (kb. egy md5 checksum). Amikor tovabbitod a levelet, akkor a tanito program (pl. spam-fwd-train) kiszedi ezt az erteket, es megkeresi azt a mysql tablaba mentett levelet, amelynek ez az azonositoja. Ha nem letezik a kerdeses azonosito, akkor nincs tanitas.

ASK Me No Questions, I'll Tell You No Lies

( saxus | 2007. 06. 26., k – 13:43 )

Attól függ, mire kell. Ha sok viszonylag egyszerűbb lekérdezés fut (abból is inkább SELECT, és ritkán kell indexelni, vagy nem kell indexelni és INSERT/UPDATE fut, akkor az eddigi neten olvasható irományok/vélemények és saját és tapasztalataim szerint nem rossz a MySQL. Viszont ha bonyolódik a helyzet, vagy nagyon növekszik az adatmennyiség, akkor könnyen hiányozhat egy-két feautre, ami mondjuk a MySQL-ben nincs vagy kezdetleges, vagy kezdhet lassulni.

Tudom, ez elég szubjektívnek hangzik, meg kicsit sok benne, a "barátom haverjának munkatársa mesélte" effektus.

___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...

( hrgy84 | 2007. 06. 26., k – 13:44 )

Sokmindentől függ. Szvsz érdemes a MySQL-t forrásból felrakni, méghozzá optimalizált CFLAGS-sel, mert az is sokat tud dobni a teljesítményen. Mondjuk én személy szerint egy nagyobb MySQL cluster alá valamilyen forrásalapú rendszert tennék (*BSD, Gentoo), mert ilyen esetekben minden megtakarított hertz órajel fontos lehet.

( Tyra3l | 2007. 06. 26., k – 14:00 )

bar nem vagyok guru, de.
Ha csak egyszeruen queryzni kell, akkor mysql szinte mindennel gyorsabb.
Ha akarsz idegenkulcsot, vagy tranzakciot, akkor innodb enginet kell hasznalnod, ami lassabb, mint a default MyISAM, viszont kevesbe serulekeny, es tudje ezeket a featureoket.
Ha kellenek triggerek, view-k, akkor csak 5ostol felfele johet szoba a mysql.
Viszont ha hasznalod ezeket a lehetosegeket, akkor a mysql elvesziti az egyik nagy elonyet pl. egy postgresql-lel szemben: a gyorsasagat.
Altalanosagban elmondhato, hogy minnel robosztusabb egy rendszer, annal lassabb az egyszerubb feladatokra.
Ezert pl. ha felraksz egy mysql-t, meg egy postgrest/oracle-t/mysql-t, akkor a mysql egeszen addig jobban fog teljesiteni, amig csak siman queryzel, ha a fentebb felsorolt featureokhoz nyulsz, akkor mar nem lesz szvsz. annyival gyorsabb, csak ra fogsz dobbenni, hogy nem mind1, hogy pl. mysql-be 2 eve van tarolt eljaras, a mssql/oracle/postgresql-ben pedig mar "kicsit" regebb ota.
Szemely szerint postgresql-t preferalom, mert "majdnem" mindent tud, amit egy oracle, de megsem annyira lassu, ami viszont hatrany, hogy nincs hozza meg olyan jol mukodo cluster lehetoseg, mint a mysql-hez (legalabbis anno keresgeltem, de nem talaltam normalis megoldast[volt valami cucc, amivel lehetett tukrozni szervert, de nem volt egyszeruen megoldva.])

Tyrael

Readline wrapperről meg még sose hallottatok, mi?
Úristen, a sok hozzáértő...

Amúgy nem értem a nyavalygást, az sqlplus elsősorban scriptek lefuttatására van kitalálva, illetve alapvető műveletek elvégzésére. Erre tökéletes. Ha fancy stuff kell, ott az SQLDeveloper.

Mond hogy ezt írjuk a nyári melegben elfogyasztott sörök rovására, és elnézzük neked.
mysql parancssorától én hülyét kapok és előbb kezdek el bárminél utánanézni psql alternatívának, minthogy mysql-t kelljen feltennem. (Sajnos nem mindig lehet :-( )
psql shell szerintem egy álom jó sql shell, ha tudsz egy érvet is mondani, hogy miben jobb a mysql shellje, fejet hajtok előtted! (Vagy beválthatod egy korsó sörre ;-) )

Nemtom... Csak nekem MySQL után nagyon kurta-furcsa volt. Külön user kell neki, persze login shellel, mi mással, senki más alól nem indíthatok pgsql parancsokat csak a pgsql user nevében... furi.

Ehhez képest a mysql shelljét akár még userként is meghívhatom ha tisztában vagyok a mysql adminjelszóval.

Szerintem az adatbázis ne akarjon a PAM-ba kutakodni. Semmit.

"senki más alól nem indíthatok pgsql parancsokat csak a pgsql user nevében... furi."

Aha, annyira furi, hogy nem is igaz.

"Ehhez képest a mysql shelljét akár még userként is meghívhatom ha tisztában vagyok a mysql adminjelszóval."

Piha te aztán kemény vagy, apám :)

Megismétlem: mit ittál?

"Csak nekem MySQL után nagyon kurta-furcsa volt. Külön user kell neki, persze login shellel,..."

bullshit!

"Ehhez képest a mysql shelljét akár még userként is meghívhatom..."

bullshit!

"Szerintem az adatbázis ne akarjon a PAM-ba kutakodni...."

ez meg már akkora bullshit, hogy lövésem sincs honnan veszed.

Szerintem tök normális a debian way, hogy a db userek és a unix rendszer userei két független dolog, de csinál a rendszeredre egy postgres nevű usert aki DB admin, és tudsz vele createuser parancsot futtatni, sőtt, ha a -e kapcsolót is megadod neki, akkor kiírja, milyen sql parancsot hajtott végre...
Ha meg nem tetszik az alapértelmezett authentikációs módszer, akkor vi pg_hba.conf, de nem vmi. szutyok elbaszott ordenáré táblában kell összevissza updatelni, mint a mysql-nél, hanem azt már egy rendszergazda kell megszerkessze, hogy a szerverszolgáltatásod hogyan azonosíthatja be a hozzá kapcsolódó ügyfeleket. (trust, passwd, ident, ...)

Jah, hogy más alapértelmezésekre számítottál, és 0 hozzáértéssel gányolni kezdtél és vmi. nem úgy működött, ahogy vártad? Akkor olvass man-t, meg doksit!

Nagyon jó online doksija van!

Ha meg épp nem vagyok net közelbe, akkor előveszem a panem kiadó által kiadott sql referenciakézikönyvem (ami egyébként oracle-höz készült), és beírom amit ott találok. Működni fog.
De mint progamozó is nagyon szeretem a postgrest, és mint adminisztrátor is szeretem a postgrest. Meg azt is nagyon, ahogy ez a debianban meg van csinálva.

Mysql számomra a szopatás netovábbja.

Nekem, akit nem érdekelnek a kifogások, csak használná/dolgozna a db-vel, tök természetes, hogy tudjon egy foreign keyt, egy view-t, egy tranzakciót, és ne kelljen ilyen háttérmarhaságokat tudnom, hogy mi a halál töke az az innodb, meg myisam, meg lófütty... Főleg úgy, hogy ehhez az egészhez vmi. halál elb...tt szintaxisa van, amit az életben nem vagyok képes megjegyezni, ráadásul annyira mysql specifikus, hogy sehol a halálba nem láttam még ekkora elkefélt ótvarságot, mint ezek a backtickes idézések, meg táblastorage specifikációk, és mellé még tab command completion sincs a shelljében...

BTW.: Ha már vannak db usereid, meg esetleg beállítottad, hogy lehessen pw-vel autholni, stb. akkor utána már fel is paraméterezheted a psql parancsot a -U -h kapcsolókkal... Csak ugye, ameddig nem létezik az user, amivel kapcsolódni akarsz... addig ne akarj vele kapcsolódni... Meg szeretem azt is, hogy a createusernek megmondhatom, hogy mekkora jogú legyen az user: tudjon-e másik usert létrehozni, és tudjon-e másik db-t létrehozni.

Annyira össze van illeszteve a linux/unix rendszer filozófiájával a postgresql, mint egy mesebeli álom!

De ez kb. ugyanaz a szitu, mint amikor vki. win-ről jön, megszokja az ottani selejtségeket, aztán furcsa neki egy unix jellegű rendszer a case sensitivségével, a slash-backslash dirseparátor különbséggel, stb. de ott is tudni kell, hogy a win a deviáns eltérni vágyó torzszülött, mint ahogy az sql rendszereknél is a mysql az amelyik ilyen borzalom a többihez képest...

Azért a MySQL-t te se ismered annyira mint szeretnéd. A MySQL-be ugyan úgy megvan a user hozzáférés szabályozása. Jó, az tény és való, hgy a CREATE USER commandnak nem lehet megadni egybő mindent, de azt hiszem nem nagy kunszt a GRANT parancs futtatása. És ugye egy usernek alapból nem sok joga van ha semmi nincs beállítva.

"Nulla szakértelemmel gányolni kezdtél..."
Hát, tudod, én nem úgy jöttem ki anyám méhéből hogy full értettem mindenhez. Szeretném megtanulni. De ha rögtön így letámadnak a témának a tudós szaktekintélyei, akkor bizony rövid úton elmegy a kedvem az egész marhaságtól.

Amúgy csak FYI, hogy van TAB completion a MySQL shelljében, bár valóban kissé fejletlen. A sessionra a \# paranccsal lehet bekapcsolni, és ismeri az összes táblát, adatbázist, és sort ami csak felmerül. Mondom, elég fejletlen, de ez még nem olyan régi feature, és hát mint ilyen nem lehet rögtön csillivilli.

Néha valóban hasznos ha az adatbázisszerver ismeri a való világbeli usereket, de sokszor semmi haszon nincs az egészből.

Nem azt mondtam hogy hülyeség a PostgreSQL meg hülye aki kitalálta meg ott rohadjon el meg satöbbi. Csak annyit jegyeztem meg, hogy a MySQL-es előélettel rendelkező csökevényes agyam számára furcsa, értelmezhetetlen dolgai vannak. Ehhez képest úgy támadtok rám, mintha nem is tudom... Ehh... talán hagyjuk is.

Belátom, hogy hülye vagyok hozzá, kár volt megszólalnom. Sajnos a kommentet kitörölni már nem tudom, így maradjon ennyiben ez a thread, oks?

"Jah, hogy más alapértelmezésekre számítottál, és 0 hozzáértéssel gányolni kezdtél és vmi. nem úgy működött, ahogy vártad? Akkor olvass man-t, meg doksit!"

Nem mondom, hogy hülyeséget beszélsz, de azért mielött ilyen kijelentéseket teszel elötte nézd meg hogy kivel, vagy milyen beállítású emberhez beszélsz pls, mert hrgy-ről elég ismert itt HUP-os körökben, hogy elég gentoo megszálott és mint olyan elég gyakran olvas man-t, dokut, meg pár órányi google-t ilyen esetekben ismereteim szerint..
Nem kell nyomban torokra menni :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

"Ha csak egyszeruen queryzni kell, akkor mysql szinte mindennel gyorsabb."

aztán ha egy valóban öszetett lekérdezést indítasz rá kell jönni, hogy a MySQL nem ismeri az SQL szabványt sem tökéletesen! Lásd a halmazműveleteket.
Valójában az Oracle "4 lépéssel" az MSSQL "3 lépéssel" a többiek előtt jár adatbázis motorjukkal.

( turul16 v | 2007. 06. 26., k – 14:18 )

sqlite

Kevest tud, cserébe gyors. :) (Veri az eddig elhangottakat sebbeségben)

( t-bee | 2007. 06. 26., k – 17:31 )

A MySQL ellen egyetlen ellenérvet tudok felhozni: azt hogy a mai üzleti elvárásoknak nem felel meg egyetlen nézőpontból sem.

Hosztinghoz, forumok alá, weblapok mögé teljesen megfelelő ez a "berakom-tárolom-kiveszem" az adatot máködés, de ha már az adabázisokon műveleteket is kell végezni akkor megéri egy tisztességes adatbázis motort használni (ORACLE, MSSQL etc.).

Az sem véletlen, hogy egyre kevesebbet foglalkozunk direktben SQL programozással, egyre előtérbe kerülnek: PL/SQL vagy fokozva OLAP, ROLAP, SAS ...

Ha arrajársz, szóljál már a Google-nek is légyszi, hogy képben legyenek.

Ha átállnának másra, meghalna a keresőipar :)
Egyszerűbb lenne helyette find-del meg grep-pel keresni a nagy webes archivumban.

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

http://zurlocker.typepad.com/theopenforce/2005/12/googles_use_of_.html
Nekem az jott le, hogy adsense-hez hasznalnak mysql clustert, de:
"AdWords was built using the MySQL database, which is open-source and therefore available for free. It is by now also nearly as full-featured as the best commercial databases, but back in 2000 this was not the case."
Azt sugalja, hogy maga a keresomotor alatt nem mysql fut, merthogy akkoriban meg nem felelt meg az elvarasoknak.

Tyrael

Felreerted, azt egy szoval sem mondtam, hogy nincs mysql clusteruk. Meg azt sem mondtam, hogy a keresomotor valahol belul nem hasznal mysql-t. En csak annyit mondtam, hogy keresomotor itself nem egy bazinagy mysql adatbazis, ahonnan mindenfele SELECT query-kkel jonnek a talalatok.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Én spec letörném a kezét az összes embernek, aki éles adatokon akar elemzéseket futtatni, de sajnos újabban egyre több olyan szerencsétlen van, aki elhiszi, hogy az éles adatoknak valami szuper adatbázis-kezelő kell.
Szerinted hol futtatnak OLAP lekérdezéseket éles adatbázison? Lehet, hogy kiskutyafüle bt-ben ez jó megoldás (MS legfőbb célterülete), de ahol rengeteg rekord képződik folyamatosan, ott a szimpla sebesség számít.
Az adatokat át lehet tenni néha valami csilivili adatbáziskezelőbe, ami minden eszeveszetten bonyolult select-et támogat.

Magyarázd el nekem légyszi, hogy miért olyan kib. nagy kérés egy sql rendszertől egy foreign key vagy egy view?
És azt, hogy ugyanezeket a psql nagy adatmennyiségeknél miért képes kb. olyan nagyságrendű sebességgel kezelni, mint a mysql a sima semmiresehasználható myisam tábláit?!

Csak a buta ember megy bele egy ennyire hülye vitába mint Te. Lehet hogy Te érzelmi alapon preferálod a MySQL-t mert írtál már köré valami dinamikus weblapot, vagy felinstalláltál már egy webáruházat, de ne felejtsd el az adatbázis kezelőt nem azért használjuk hogy adatokat (emialcímeket, postokat stb.) tároljunk!
Az meg hogy mithasznál a Google nekem és neked is indiferens, és óvaintelek attól hogy így kardoskodj a egy véleményed melett:
"De hát uraim a Google is ezt használja!" - vazzeg van valami meggyőzőbb érved is!?

Példaként csinálj már egy INTERSECT kérdést MySQL-ben! Vagy építs rá egy adattárházat, esetleg valósíts meg valami adatbányászat szerűséget benne. Ha készen vagy nyugodtan jelentkezz mert nagy bravúrt vittél véghez: "piszkavassal precíziós heggesztést csináltál", ami nem lehetetlen de megkérdőjelezi józanságodat!
Ha meg mégsem megy akkor, beláthatod a MySQL messze nem nevezhető relációs adatbáziskezelőnek, az meg tény hogy nem ismeri még az SQL92 szabványt sem.

Persze egy "webfejlesztő Pistikének" nehéz elmagyarázni hogy a LAMP on kivűl még létezik egy hatalmasabb világ ami az IT területének >90%-át teszi ki. Persze itt azok a hülye IT szakemberek melóznak, akik a webfejlesztők körében egységesen közutálatnak örvendnek. Véleményem szerint a "közutálat" oka az lehet hogy míg egy MySQL guru hozzá nem tud nyúlni egy Oracle-hez vagy egy MSSQL-hez úgy hogy azokat optimális működésre tudja bírni, addig egy IT szakembernek nem okoz gondott visszanyúlni az (my)SQL-hez ami ugye csak nyomokban bírja az SQL nyelvet.

és mégis troll!
TE kezdted a mysql fikázását, még mindig nem látok semmit, ami szimpla utálatodon kívül megmagyarázná a bajaidat.

Ehe-ehe. Valaki megint nem tudja mit beszél és kinek. Vagy leragadtál a mysql 3.23-nál, mint minden más mysql fikázó, vagy csak nem birod elhinni, hogy az őfényessége oracle-n kívül másban is lehet dw-t csinálni.

Bravúrokon túl vagyok, de nem is te vagy az adatbázisok atyaúristene, hogy észt osszál, szálljál már le a földre. Személyeskedni kezdtél, elbuktad. Ennyi.

De hogy a te stílusodban toljak egy kis trollkodást: oracle vs join? doksi mit ír erről?

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

khmm... nekem itt egy ember tűnt úgy, hogy személyeskedni kezdett (uram bocsá, trollként viselkedett), konkrétumokat, linkeket, stb.-t egy szálat se írt, csak minden alap és ok nélkül személyeket sértő hozzászólásokat...
[szerk:]link alatt technikai dolgokra való linkeket értek, és nem e-peniskedéseket, hogy a google használ mysql-t, mert abból nem derül ki mire, és hogyan használja[/szerk]

És nem akarok ujjal mutogatni, hogy ki, majd a fórumból kihámozza mindenki magának...

Javaslom neked hogy töltsél le egy Oracle Express Edition http://www.oracle.com/technology/software/products/database/oracle10g/i… és kezd el próbálgatni ha nem hiszed el hogy van élet a MySQL-en túl is. Sőt igazán ott kezdődik minden!

"Az Oracle Database 10g Express Edition (Oracle Database XE) belépő szintű, kis helyigényű adatbázis-kezelő az Oracle Database 10g 2. változatának programkódja alapján, amely ingyenesen használható fejlesztésre, és szabadon telepíthető és továbbadható. A gyorsan letölthető adatbázis-kezelő adminisztrációja is egyszerű. Az Oracle Database XE kiváló kiinduló megoldás:" http://www.oracle.com/global/hu/database/Express_Edition.html

Persze a tudást sehol sem kaphatod meg ingyen, sok sok tanulás kell ahoz az egyetlen minőségi lépés megtételéhez, ami a MySQL alapjaidról ellépést jelenti egy mérnöki problémamegoldó szemléletmód irányába.

Valami ismeretlen oknál fogva hajlandó az Oracle arra is, hogy megkeresésedre ingyenes DVD lemezt küldjön; és ha megfelelő fórumokon értelmes és tiszeteletteljes hangnemben megfogalmazott kérdése(i)dre a kedves Oracle fejlesztő(k) személyesen is hajlandók neked segítő információt nyújtani. :)

Hogy oda ne szaladjak...
XE egy trágyadomb. Nagyban nem tudod használni (pl csak 1 procit támogat), de kell neki erőforrás rendesen. 1gb ram mellé kell neki 1gb swap space. Orákulus barátaink meg nem képesek rendes debian csomagot építeni. Kb 2 hónappal ezelőtt kellett használnom. Kínszenvedés volt felrakni egy etch-re.

Ráadásul "kis helyigényü". lol...

Amire az xe jó, arra szerintem a mysql több mint jó...

Orákulus barátaink meg nem képesek rendes debian csomagot építeni. Kb 2 hónappal ezelőtt kellett használnom. Kínszenvedés volt felrakni egy etch-re.

HHhHHHhhah

horgok

erdekes h solarisos, windowsos, openvmses, tru64es, hpuxos, aixos verzio mukodik

debianos nem, pedig az osszes nagy oracle felhasznalo etchen kuldi

--
miau

Most szivesen beírnék ide valamit amitől a MySQL 5.x.z kifeküdne de nem teszem mert, MySQL barátaink szivűkhöz kapnának hogy ez nem is az amire számítottak!

Néhány hónapja volt alkalmam egy 0. verziójú adattárház alap igényeit végighallgatni, aztán gondoltam egy nagyot hogy a következő meetingre a .pps prezentációt megfűszerezem egy adatbázis 0. béta tesztel is. Feldobtam egy MySQL-t a laptopomra, és ledöbbenve tapasztaltam, hogy ha egy lekérdezésbe egy másik "alkérdést" ágyazok be pl (EXISTS) akkor a MySQL hibával visszatért. Ez suxxx!

Mivel úgyis Oracle-t használ az a bank ami 2db 64 processzoros szerveren futtatja adatbázisait (kiváncsi lennék az rendszermérnökök véleményére, miként futna egy MySQL szerver ezen a gépen?) ezért hát feltettem XE-t ami pont elegendőnek bizonyult az adattárház tervezéshez. Az XE valóban fejlesztéshez és tanuláshoz készült kiadás éppen ezért ajánlottam bárkinek szabad használatra.

Az bullshit hogy erőforrás igényes egy 1Gbyte RAM-os notin Virtual PC-ben vígan fut, nálad valami probléma lehetet, vagy az adatbázisok voltak nagyok.

Ne próbáljon senki XE-re élesben üzleti alkalmazást ültetni, mert ez az amit az Oracle sem szeretne, ezt korlátozza.

Összegezve a MySQL valóban gyors de nem tud sokmindent (kb SELECT, INSERT, UPDATE, DELETE és vége sajnos a nagyon nagyon fontos INTERSECT, UNION, EXCEPT stb. nem megy benne) nem is foglalkuzunk vele érdemben. Játékszernek meg ott van az ingyenes XE ami azért teljes értékű Oracle, csak korlátozva van a processzorok száma, a táblák mérete (úgy emlékszem 2.000.000 sor) de ez a fejlesztőket nem érinti.

"Az bullshit hogy erőforrás igényes egy 1Gbyte RAM-os notin Virtual PC-ben vígan fut, nálad valami probléma lehetet, vagy az adatbázisok voltak nagyok."

Az egy dolog, hogy elmegy, de hibával tért vissza a dpkg -i, mert 1023mb swap területem volt 1 gb ram mellett, az orákulusnak meg legalább 1024 kell, amiből persze később 1et sem használ, mert van elég ram a rendszerben.

Debian csomagokhoz még egy kis élménybeszámoló: Prof mondja, hogy töltsük le az egyetem szerveréről ingyenesen, ezzel dolgozzunk. Mire én benyögöm, hogy ez bizony windowsos. Mire ő: Mi kéne? Mondom: debian. Mondja: "Hát, azt nem tudom. Nézd meg neten, talán le tudod tölteni. Ha nem, akkor használj egyetemi gépet windowsal."
Aztán bújtam az oracle-weblapot, hogy hol lehet letölteni. Aztán miért nem szeretni az oldaluk az operát. Telepítésről már írtam.
Tudom, ez nem releváns egy jól belőtt, működő rendszer esetén, bár szerintem nagyon sokat elárul egy szoftverről, hogy mennyire bonyolítják túl a telepítést, a honlapot stb...

Az való igaz hogy support és hozzáértés nélkül körülményes egy megbízható complex rendszert telepíteni, és ez sokakat el is bizonytalanít elsőre. Nos nekem a Wines változat van fent annak ellenére hogy UNIX-os projectet bűvölök, és a Unix is Virtual PC-ben fut nálam kényszerű okok miatt.

Itt van Debian csomag is: http://www.oracle.com/technology/software/products/database/xe/htdocs/1…
Az installt az alábbi OTN-en keresd meg.

Az OTN community nagyon jó segítség tud lenni, gyakorliatilag a legtöbb friss információt itt lehet elérni; a fejlesztők is aktívan nézegetik, egy kérdésre átlag 1-2 napon választ adnak (saját tapaszatlat). Innen lehet eljutni: http://www.oracle.com/technology//index.html

Nem szorosan ide tartozik, de ezen kívűl fejlesztéshez a JDeveloper nagyon jó eszköz, az ADF-el nagyon hatékony vékony kliens alkalmazásokat lehet gyorsan fejleszteni. Egyenlőre ez technológia még hazánkban nem nagyon elterjedt, szokás szerint 2-3 éves késéssel kezdik el bevezetni a cégek.

"azért vannak a szabványok, hogy azoknak ne feleljen meg a \"TopLevelDatabaseEngine\""

Tudtommal minden sql-adatbázis-gyártónak meg van a saját "sql-tájszólása". Még oracle-nek is. Innentől kezdve meg nem nagyon lehet az sql-szabványokra hívatkozni. Szomorú dolog, de így van...

The alernative way to the same is to edit /etc/default/oracle-xe and change:

#ORACLE_DBENABLED=true
ORACLE_DBENABLED=false

szerk: vagy nem értem miben nem bízol...
szerk2: ha az első megoldásuk tréségére gondolsz, akkor inkább itt van ez: http://www.oracle.com/technology/tech/linux/install/xe-on-kubuntu.html

Mint már írtam az OTN-en részletesen le van írva az install is: http://www.oracle.com/technology/pub/articles/smiley_10gdb_install.html és az XE-re is van howto és az előttem leírt http://www.debianhelp.co.uk/oracle.htm link is jó.

és még link:
http://www.oracle.com/technology/pub/notes/technote_php_instant.html

Köszi, igen. Van hozzá dokumentáció, ok.
Én csak a személyes tapasztalatomat írtam le vele. Pl amikor felment a deb-csomag sikeresen, elindult az xe, de még csak véletlenül se adott nekem webinterfészt az 127.0.0.1:8080/apex címen...
Nos, lehet, hogy másnál ment rendesen, nekem nem ment és nem jött be. Ez egy tapasztalat szubjektív leírása, nincs mit rajta érvelni. ;-)

xe?
mintha azt mondanad, hogy vista home basicet nezzem meg, hogy az ultimate milyen jo.
kis helyigény... DB2-vel is jobban járok.

Valami ismeretlen oknál fogva nem értem, hogy miért hiszed azt, hogy én mysql-en nevelkedtem. Ahogy nem értesz egyet valakivel, azonnal "biztos mysql fan, énmegmondomnekihogy mssql/oracle/excel".

Az xe dvd meg lassan egy eve erkezik, igy a dvd alapu kiprobalasarol letettem...

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

Az adatok gyors (~real-time) elemzese sok helyen komoly uzleti elonyt jelent, sok helyen nelkulozhetetlen igy kar csodalkozni ha az ugyfelek ilyet (is) szeretnenek, es ezert hihetetlen osszegeket hajlandok fizetni. A tozsdei kereskedok nem sokra mennek azokkal a lekerdezesekkel, amik csak masnapra futnak le...

Akkor néhány tapasztalatom (sok év adatbázis alapú alkalmazásfejlesztés után):

MySQL tényleg piszok gyors tud lenni az összes többivel összehasonlítva néhány területen: nagy tömegű adat rögzítése, egyszerű lekérdezések, profik által írt összetett lekérdezések. Többnyire read only adatokon is veszettül gyors. Nagy tömegű konkurrens adatrögzítésnél lehetnek gondok a lock-olások miatt, bár ez megkerülhető.

PostreSQL nem annyira gyors, vannak idegesítő nyűgjei (fragmentálódás, vacak blob-kezelés), de egyre jobb (szépen fejlődik) és a licence sokkal jobb MySQL-nél. SQL-je sokkal inteligensebb, de szakértelem nélkül ezzel sem érdemes bonyolult query-ket írni.

Oracle: hát nem egy villám, sokkal lassabb általában, mint a fentiek, viszont van egy hatalmas előnye: a bonyolult lekérdezéseket olyan szinten elemzi, hogy közel olyan vagy néha jobb sebességeket produkál, ment amilyen query-ket a profik írnak a fenti két adatbáziskezelőn.

Saját tapasztalatom alapján egy-egy rosszul megírt lekérdezés simán bír 100-szoros vagy akár 1000-szeres futási idővel futni egy jól megírt query-hez képest. Az Oracle abban nagy szerintem, hogy az ilyen lekérdezéseket addig optimalizálgatja, míg közel olyan vagy jobb nem lesz, mintha egy igazi guru írta volna.

Valószínűleg ezek a dolgok szülik a folyamatos MySQL<->Oracle -- A ... a gyorsabb viákat. Maga a technológia (indexek ilyen-olyan bináris fában, tranzakció-kezelés technikái) már 10 évvel ezelőtt is kiforrottak voltak, ilyeneken nem nagyon érdemes rágódni, nagyjából ugyanaz van mindegyik adatbázisban.

Az ilyen "MySQL belassul nagy mennyiségű adatnál" vélemények meg többnyire csak annyit jeleznek, hogy aki állítja, nem tud query-t optimalizálni vagy adatbázist tervezni (vagy inkább mindkettő). Az adattárolás és az index-kezelés technológiája ugyanis tényleg majdnem ugyanaz mindenhol.

Namost egy cég vagy fizet egy gurut, vagy vesz Oracle-t (vagy más hasonló kaliberű dolgot) az adatbányászati feladatokra. Az Oracle általában olcsóbb. Viszont ez nem a három fős cégek kategóriája persze.

Szóval ezért írtam, hogy az adatbányászati feladatokra, amikor manager-ek mindenféle grafikus tool-okkal dobálnak össze query-ket, célszerű berakni komolyabb adatbázis-kezelőt (pl. Oracle), mert előfordulhat, hogy a 10 napig futó összetákolt lekérdezések 1 óra alatt fognak lefutni és nem terhelik feleslegesen az éles rendszert sem.

Vannak persze további összetevők is. például az egyetemről frissen kijött emberkék nem bírnak elszakadni a normálformáktól, amik sok esetben tökéletesen alkalmasak arra, hogy már tervezéskor gondoskodjunk róla, hogy a kész alkalmazást majd lehetetlen legyen üzemeltetni.

stb., stb.

"Vannak persze további összetevők is. például az egyetemről frissen kijött emberkék nem bírnak elszakadni a normálformáktól, amik sok esetben tökéletesen alkalmasak arra, hogy már tervezéskor gondoskodjunk róla, hogy a kész alkalmazást majd lehetetlen legyen üzemeltetni."

Ezt részleteznéd? Ugye bár elvileg arra találták ki a normálformákat, hogy használható legyen az adatstruktúra...
Sőt, még olyanokat is mondtak nekünk, hogy a hozzáértő ember nem normalizál, mert amit lefirkantja a gondolatait, az már alapból legalább 3.nf-ban van...

Normálformák update-re optimalizáltak.
Lekérdezéskor csomó (adott esetben felesleges) join-t kell csinálni, ami lassíthat.
Ezért van az, hogy adatbázis táblát nem elég annak alapján tervezni, hogy tudjuk mi lesz benne. Azt is tudni kell, hogy milyen kérdések és frissítések lesznek.

Na, nem bírtam megállni, hogy a hatalmas flémbe ne írjak valamit :-).

Igazad van. De szerintem nem a normalizálással van a probléma, az egy hasznos dolog. Nagyobb probléma az ha minden adatot újra kell számolni "merthát meg vannak az adatok". Ha rendeszeresen újraszámolni kell olyan adatokat amelyek konstansok "mert az ügyfél lekérdezési ezt megkívánják" akkor a gyakorlatban célravezetődőbb, ha letároljuk a részeredményeket.
Pl. Számlafejek listája mellett szeretné látni a végösszeget. A tételekből össze lehet szummázni az értéket, de ha több 1000 számláról van szó, amiken több 10 tétel is szerepel akkor már, az elméletben szépen működő dolgok a teljesítmény rovására mennek.

Azért írtam már Oracle-be olyan query-t, ami kb. 5 óráig futott, és utána átfogalmazva le lehetett szorítani olyan 1,5 órára.
Pedig 10g volt, de valamiért magától nem találta ki, hogy ha a where feltételbe teszek egy subquery-t, ami semmitől se függ, akkor azt egyszer le kéne futtatni, és az eredményét használni, hanem ő soronként mindig le akarta futtatni.

G

( dii | 2007. 06. 26., k – 23:13 )

Helló!

Nem kívánok a flame war-ba csatlakozni, tehát ne úgy vegyétek a kérdést mint a "bizonyítsd az igazad" felszólítást.

Tudnátok, konkrét példát mutatni, ahol a postgresql-el olyat lehet csinálni amit mysql-el nem? Ne valami odavetett félmondatot ha lehet, hanem leírva, hogy 'A' tábla, 'B' tábla, ez meg az kell... remélem érthető.
Tényleg nem flame-et akarok, eddig kis-középvállalati megoldásokra C++ alá nekem megfelet a MySQL de szeretném látni mit profitálhatok az átállással. A progiban csak 1 sor, de megtanulni "jól" kezelni a dolgot nem kevés idő, tehát hit alapon nem fogok erre pazarolni.

Hát konkrét SQL sorokat nem tudok mondani, de ha elolvasod a topicot és kiszűröd a troll/flame kommenteket, akkor azért pár releváns dolog lejön.

A MySQL egyik gyenge pontja a tárolt eljárás. Van rá lehetőség, de sok tekintetben korlátolt.
A másik hiányossága az idegen kulcs fogalmának hiánya. Ugye, sokszor szükség lenne arra, hogy az SQL adatbázis lekezelje azidegen kulcs kapcsolatokat, pl. kaszkádolt frissítésnél/törlésnél. Sajnos erre jelenleg semmilyen megoldás nincsen.
A MySQL többféle adatbázis-backendet támogat, ám ezeknek különböző előnyei/hátrányai vannak. Nagyon oda kell figyelni, hogy a megfelelő feladathoz a megfelelő backendet válaszd.

És nem utolső sorban, mint kiderült a MySQL nem tud semmit a hostoló rendszer által ismert userekről, azaz ha ilyen feature-ra van szükség (pl. intranetenelőfordulhat az egységes jelszórendszer követelménye), akkor egyetlen lehetőség a rendszer PAM-MySQL-re átállítása, vagy egy egyéni PAM modul kreálása.

Igyekszem szűrni a trollozást de nehéz :)

Tárolt eljárás: hát igen, ebben lenne lehetőség ahogy elnézem. Észben fogom tartani, hogy ha szükség lesz ilyenre...
PAM probléma: értem, szerencsére nincs ilyesmire szükség.
Idegen kulcs: foreign key? Ez valamilyen szinten már van, innoDB esetén.

Köszi a válaszokat! Turulnak is, ő is használható infót küldött :)

Deviation from SQL standards: Like MySQL in general, in an SQL statement that inserts, deletes, or updates many rows, InnoDB checks UNIQUE and FOREIGN KEY constraints row-by-row. According to the SQL standard, the default behavior should be deferred checking. That is, constraints are only checked after the entire SQL statement has been processed. Until InnoDB implements deferred constraint checking, some things will be impossible, such as deleting a record that refers to itself via a foreign key.

Tyrael

Én ezt találtam kb. 1 éve, 5.x-es MySQL-el is próbálkoztam

A delete-nél az van, hogy ugyanarra a táblára mint amiből törölsz mysql alatt nem hivatkozhatsz egy alselectben. Ezt a postgres tudja, a MySQL-ben azt hiszem sikerült végül is kikerülnöm, de postgres fél órás futási ideje helyett valami 5 óra után sem futott le ugyanez mysql alatt.

A másik egy érdekesség volt, ahol full-text search-ot kellett alkalmazni. Itt a mysql egy lekérdezésnél kb. ugyanannyinak tünt, mint a postgres. Kicsit talán jobb is volt. Viszont amikor a szerveren éles futással teszteltem a mysql 1,5-ös loadot produkált, a pgsql viszont 0,5-ös loadot produkált csak ugyanakkora forgalomnál. :-) Mintha lennének gondok a több useres optimmal.
Ehhez hozzátartozik, hogy mindkettő lehetőségeit kihasználtam optimalizáltam.
mysql key-buffer, %valami%' és a match stílusú fulltext indexek stb.
pgsql shared-buffers, és text_pattern_ops típusú indexek, stb.

Ja és a mysql kiakadt egy 20 millió soros táblán valami memória-elfogyási hibával, amikor valamit group-by-oltam rajta. Ugyanezt a pgsql simán megcsinálta.

Na ezek óta használok inkább pgsql-t (bár használok ahol muszály mysql-t is).

flame://oracle pre-9i vs join? :) az is egy tajszolasi kulonlegesseg? :)
(post-9i -kkel dobalozni nem er, mert mai napig latok clustereket(gyartosorok vezerlese) amik upgradejet csak megtervezni tobbhavi munka lenne)

noflame://Azta mit találtam (gyk: fejezetcimet nezd meg:)
http://www.dba-oracle.com/art_sql_iso_99.htm

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

( drastik | 2007. 06. 26., k – 23:16 )

sracok a szinvonal az olyan mint amikor ket foldmuves beszelget a gazdasagrol

--
miau

Minap próbált valaki meggyőzni, hogy az mssql szerver tulajdonképpen mindenben jobb, mint a mysql... Gyorsaság + megbízhatóság + több gép közti megosztás, ezeket emelte ki. Szerintem nem feltétlenül volt igaza, bár a mssql szerverhez egyáltalán nem értek.

ez még mindig odabasz :))

( Frantique v | 2010. 04. 27., k – 12:48 )

Nem nyitok új szálat, hátha valaki tudja a megoldást...
Select_full_join érték alattomosan kúszik felfele, 300+ adatbázis van, a lekérdezések nagy része dinamikusan állítódik elő, de hol nézhetem meg, melyek a hülye lekérések?
--
Coding for fun. ;)

meg se nezted a linkeket (vagy nem ertetted meg)
amugy ugye tudsz rola, hogy van
http://dev.mysql.com/doc/refman/5.0/en/server-options.html#option_mysql…
beallitas, amivel bekerulnek a slow query logba az indexet nem hasznalo lekerdezesek is, fuggetlenul attol, hogy mennyi ideig futottak?

Tyrael