Egy pesti ügyfelünknél Sybase ASE fut, sok probléma van vele, úgyhogy váltani akarunk. A legnagyobb gond, hogy rosszul viseli ha többen akarnak írni és olvasni egyszerre egy táblát. Rettenetesen lelassul, lényegében használhatatlan.
30-40 felhasználó van
legnagyobb tábla kb 1 millió tétel
a gyakran használt tábla kb 50 ezer tétel
egyidejű írások egyszerre néhány ezer tétel
Nyílt forrású adatbázisra szeretnénk váltani. Tesztek alapján a MySQL tűnik legjobbnak a feladatra, de nyitottak vagyunk más megoldásra is. Olyan szakértőt keresünk, akinek van tapasztalata ilyen terheléssel. Tud ajánlani adatbázist, vállalja a telepítést, finomhangolást, automatikus mentést, helyreállítást hibánál, folyamatos támogatást,..
Sebők Norbert
sebok1@enternet.hu
Bar nem vagyok annyira otthon az SQL adatbazis-kezelok teren, hogy vallaljam, de egy tanacsot adhatok: MySQL-t tessek elfelejteni... SQL92-rol meg csak nem is hallott szegeny.
http://www.postgresql.org
Nekem a sebesség a fontos, pontosabban az hogy elfogadható időn belül válaszoljon. Inkább programba teszem a tárolt eljárásokat, triggereket, ha erre gondoltál.
Lefuttatam egy kisebb tesztet, 100 tételt 2-en írnak egyszerre, folyamatosan újra és újra, miközben egyvalaki olvassa is. Emelett még fut egy másik írás és két másik olvasás is.
Sybase
- 79 sec átlagos várakozás a 100-as tételre
- 1 sec alatt a másik két olvasásra
- gyakori deadlock üzenetek
PostgreSQL
- 16 sec átlagos várakozás a 100-as tételre
- 1 sec alatt a másik két olvasásra
- gyakori deadlock üzenetek
MySQL
- 3 sec átlagos várakozás a 100-as tételre
- 1 sec alatt a másik két olvasásra
- nincs deadlock üzenet
Tehát erre a feladatra lassú a Postgre is, bár nem ismerem, lehet hogy van valamilyen optimalizálás.
A MySQL-nek van más hátránya azon kívül hogy le van maradva, pl megbízhatóság, hibák, .. Rá lehet bízni egy cég adatbázisát?
Egy adatbazisvaltas egyaltalan nem egy trivialis problema, jol el van aknasitva (avagy olyan dolgokat hasznal amit X adatbaziskezelo tud, Y
amire valtani szeretnenk pedig nem) es a sok-sok query-bol nehany biztosan maskeppen mukodik X-en, mint Y-on.
Eleg regen hasznalunk mar MySQL-t - megvannak a maga hulyesegei. A MySQL "buta adattarolasra" egeszen jol mukodik, de nagyon konnyen el
lehet veszteni benne az adatok konzisztenciajat. A MYISAM tablaformatum
a nem megfelelo finomsagu lockolasi mechanizmus miatt nagyon gyorsan veszit a teljesitmenyebol. Az INNODB egesz jo, de mindig egy kicsit mashogy mukodik.
Egyebkent mit jelent az az "ilyen" terheles, mondjuk tranzakcio/sec-ben merve? Az a 30-40 felhasznalo "mit" csinal?
Az szep es jo, hogy egyszerre probaljak irni, de:
-Milyen tranzakciokezeles van beallitva az adatbaziskezeloknel? Read uncommited, Read commited, Repeatable read, Serializable?
Alapertelmezett tranzakcios elszigetelesegi szintek:
Sybase Repeatable read
Mysql Read commited
sok-sok query-bol nehany biztosan maskeppen mukodik X-en, mint Y-on
Igen, számítok rá, hogy jó alaposan bele kell nyúlni a programba, ez vállalható.
Az INNODB egesz jo, de mindig egy kicsit mashogy mukodik.
InnoDB-t tervezek használni, fontosak a tranzakciók.
Mit értesz azon, hogy mindig egy kicsit másképp működik?
Mik a hibák?
Az a 30-40 felhasznalo "mit" csinal?
Ez egy ügyviteli szoftver, számláznak, cikket keresnek, bevételeznek, könyvelnek, tekintélyes kimutatásokat kérnek le, stb...
Tranzakció / sec, azt nem tudom pontosan. Előfodul, hogy mondjuk 3-5 felhasználó tárol 50-2000 tételnyi adatot különféle táblába, miközben még 3-5 másik felhasználó böngészi a cikkeket, vagy összetett nagy kimutatásokat kér le. Persze lehet ennél több is, kevesebb is egyszerre.
A tapasztalat az, hogy elég egyetlen komoly terhelés (pl egy kimutatás) és megáll a rendszer, senki nem tud dolgozni, míg le nem fut. Főleg ha egyszerre többen kérnek listát, vagy tárolnak sok adatot.
Milyen tranzakciokezeles van beallitva az adatbaziskezeloknel?
Igen, ez jó felvetés. Alapértelmezett volt eddig, az nálam MySQL 4.1.4-en Repeatable read. Kipróbáltam mind a 4-et:
Repeatable read: 3 sec
READ COMMITTED: kicsit lassabb 4 sec
READ UNCOMMITTED: még lassabb 5 sec
SERIALIZABLE: használhatatlanul lassú, akadályozzák egymást
Mashogy mukodik = ajanlom figyelmedbe a changelogokat
Postgresql-ben a default izolacios szint Serializable:
http://www.postgresql.org/docs/current/interactive/sql-set-transaction.html
"Both commands are defined in the SQL standard. SERIALIZABLE is the
default transaction isolation level in the standard; in PostgreSQL"
Egy OLTP rendszer nem kifejezetten hatekonyan mukodik statisztika / olap / adatbanyaszatra - csodat az adatbaziscserevel ne varjatok. De okos megoldasokkal elfogadhato teljesitmenyt lehet kicsikarni a rendszerbol.
(BTW: mi vegul az adatbaziskezelok ezen korlata miatt sajat indexelesi / tomoritesi eljarast csinaltunk a statisztika / adatbanyaszat hasznalhatova tetelere - igy egy query nem harom napig fut, majdnem kizarva mindenkit, hanem 0.1sec alatt:)
[quote:3781773634="sebokn"]Nekem a sebesség a fontos, pontosabban az hogy elfogadható időn belül válaszoljon. Inkább programba teszem a tárolt eljárásokat, triggereket, ha erre gondoltál.
Hali.
A tárolt eljárásoknak az a lényege, hogy a szerverben előre le van forditva és egyszerre egy
"eljáráson belül" több műveletet is végezhetsz.. programmal ugyan ki lehet váltani, de csak a sebesség rovására.
A MySQL-ről meg annyit, hogy valóban gyors, de ezt a sebességet azzal éri el, hogy sokkal kevesebbet tud a "nagyobb tudású" társaihoz képest.. de mivel azt is fejlesztik, az is le fog lassulni, igy lehet, hogy 1-2 év és ugyanolyan "lassú" lesz mint a többiek.
Fri
Postgresql-ben a default izolacios szint Serializable
Kipróbáltam READ COMMITTED-del is, hasonló maradt az eredmény sajnos.
(BTW: mi vegul az adatbaziskezelok ezen korlata miatt sajat indexelesi / tomoritesi eljarast csinaltunk a statisztika / adatbanyaszat hasznalhatova tetelere - igy egy query nem harom napig fut, majdnem kizarva mindenkit, hanem 0.1sec alatt:)
Az nem rossz eredmény... :)
Kb. jövő év elején kezdek egy ilyen kimutatás-készítő programot építeni nekik. Egyelőre azzal kisérletezem, hogy teljes egészében memóriában tartom az adatokat, és indexelt mutatókon keresztül jutok hozzájuk. Ez jó, mert pl 500ezer számla eladási mennyiség helyett csak ezer darabot kell tárolnom, annyi az ismétlődés. És a sebesség is elég jó..
Ti milyen módszert használtok? (már ha el szabad mondanod)
[quote:70ebed4586="Frimen"]A tárolt eljárásoknak az a lényege, hogy a szerverben előre le van forditva és egyszerre egy
"eljáráson belül" több műveletet is végezhetsz.. programmal ugyan ki lehet váltani, de csak a sebesség rovására.
Az a baj, a szerven futó eljárások mindekit feltartanak és csak halmozódnak. Ha ehelyett átteszem a kliensre a számításokat, akkor csak azt az egyetlen klienst tartom fel és tehermentesítem a szervert.
(legszivesebben teljesen elosztott rendszerrel szeretnék dolgozni, ahol nincs is szerver, mindenki tárolja az adatoknak azt a részét, amit használ és frissítik egymás között, ... sajnos nem sok ilyen kezdeményezésről tudok)
Javaslom kipróbálásra a Firebird 1.5.1-et is. Elődjeit is, ezt a verziót is használjuk közepes méretű (> 2GB, rekordszám>1000000 néhány táblában) adatbázisokkal, sok (és sokféle műveletet végző) felhasználóval.
Egyszerű a telepítés, tipusfeladatokra könnyű a konfigurálás. Léteznek hozzá jó admin progik, de mindent lehet parancssorból is - még win alatt is. :-)
Nagyon jól használhatóak a triggerei, tárolt eljárásai. Gyenge pontja a jogosultságkezelésben, hogy az egyes objektumok tulajdonosi joga nem ruházható át, tehát meggondoltan kell létrehozni a táblákat, tárolt eljárásokat.
A tranzakciókezelése jól sikerült, még nem tudtam úgy összeomlasztani, hogy ne konzisztens állapotot kapjak (és mindig tudtam menteni a meghibásodott adatbázisból is).
Ha segítség kell a használathoz, optimalizációhoz, tudok segíteni.
Mozsi
[quote:4f9e899015="Mozsi"]Javaslom kipróbálásra a Firebird 1.5.1-et is. Elődjeit is, ezt a verziót is használjuk közepes méretű (> 2GB, rekordszám>1000000 néhány táblában) adatbázisokkal, sok (és sokféle műveletet végző) felhasználóval.
Köszi, jól hangzik, teszek egy próbát.
[quote:4f9e899015="Mozsi"]Ha segítség kell a használathoz, optimalizációhoz, tudok segíteni.
Ok, kereslek, ha végül ezt választom.
A tarolt eljarasok - a tevedesek elkerulese vegett - nincsenek forditva (ertsd: runtime kodgeneralas, muveletek sorrendje) az adatbaziskezeloben (bar kivetelt tudok:).
Az optimalis vegrehajtasi terv fugg az adatbaziskezelo pillanatnyi allapotatol, tartalmatol igy ertlelme nincs joelore letarolni. Raadasul egy tarolt eljaras vegrehajtasanak nehany trivialis peldatol eltekintve egyaltalan nem becsulhetok az input parameterekbol. (Es a tablak tartalmarol meg szo sem esett, mert azok is valtozhatnak - es valtoznak is)
Ha sok gyakori query van, akkor ajanlom figyelmedbe a PREPARED query-ket, a legtobb adatbaziskezelo (pl.: postgres, oracle) valamilyen szinten tudja cachelni a lekerdezes terveit. (avagy az adatbazis allapota nem mindig valtozik olyan nagyon gyorsan, hogy a mar elkeszitett tervek sokkal rosszabbak lennenek)
[quote:eadc387a6b="handler"]A tarolt eljarasok - a tevedesek elkerulese vegett - nincsenek forditva (ertsd: runtime kodgeneralas, muveletek sorrendje) az adatbaziskezeloben (bar kivetelt tudok:).
Kivétel például a Firebird is. Tervezd előre az indexeidet, akkor nincs gond. :-) Egyébként lehet frissíteni a tervet, ha megváltoztattad a végrehajtási feltételeket. Normális üzemben (értsd: nem zajlik fejlesztés az éles adatbázison) ez nem okoz gondot, sőt.
[quote:eadc387a6b="handler"]Ha sok gyakori query van, akkor ajanlom figyelmedbe a PREPARED query-ket, a legtobb adatbaziskezelo (pl.: postgres, oracle) valamilyen szinten tudja cachelni a lekerdezes terveit. (avagy az adatbazis allapota nem mindig valtozik olyan nagyon gyorsan, hogy a mar elkeszitett tervek sokkal rosszabbak lennenek)
Csak azokat a query-ket tudják így kezelni az adatbázismotorok, amelyeknél csak a query-ben lévő konstansok változnak meg, a query szerkezete azonos. Legtöbbször csak akkor használhatod ki ezt a lehetőséget, ha beágyazott sql-lel vagy az adott adatbáziskezelőhöz tartozó fejlesztőeszközzel dolgozol.
Azért azt se tessék elfelejteni, hogy a MySQL nem tud stored procedurest (ill. az ötös tud, de az szerintem még öngyilkosság, ha cégnél élesben váltasz rá)
Én nagyon szeretem a MySQLt, egyszerű weboldalak mögé ideális, de számlázást sok juzerrel én nem bíznék rá...
[quote:c3bfd7ac02="drojid"]Én nagyon szeretem a MySQLt, egyszerű weboldalak mögé ideális, de számlázást sok juzerrel én nem bíznék rá...
Van egy ilyen hangulat a MySQL körül, hogy nem megbízható. Ez csak rossz beidegződés, vagy tényleg féltenem kell az adataimat MySQL-ben? Van valakinek tapasztalata adatvesztéssel például, vagy hogy lefagy, vagy hibásan működik a backup, ilyesmi... ?
http://openacs.org/philosophy/why-not-mysql
Ellenőrizni kellene, hogy ezekből mit oldottak már meg...
btami
Nekem nem volt még vele rossz tapasztalatom, igaz, nagyon nagy rendszert nem is bíztam még rá. Majd most decemberben... Ha januárban még élek, akkor igenis megbízható és terhelhető... :)
Ellenőrizni kellene, hogy ezekből mit oldottak már meg...
btami
Hát, itt a few more detailsből a "nincs subquery", "nincs trigger" és a "nincs tárolt eljárás" még most is él, úgy tudom... :( Legalábbis a négyes MySQL esetében...
És ezek azért elég komoly hiányosságai... :(
Hello,
mi használunk ügyviteli rendszernél - számlázás, kimutatások, adatszerkesztés, néhány változó adat kezelése, de az állandóan - napi 50 új - az összs meglévő mellé ! - jövő adatot. Az 50 nem tűnik sokank, de napi 50 új adat, mely mindenképpen benne marad a db-ben és ezekkel végzett különféle műveletekből származó új adatok és sorok egészen szép számot tudnak generálni. A lekérdezések pedig _nagyon_ összetettek tudnak lenni. Postres-t használunk. Jobban skálázható, egyetlen hátránya, hogy találnod kell olyan időszakot, amikor hetente tudod vacuum-ozni, mert az kell neki néha. BLOB adatok - szkennelt számlamásolat, cégbejegyzések szkennelve stb - külön shared object-tel teljesen jól használható, de ekkor már kell alkalmazni különféle triggereket is, és a vacuum_lo-t is. Nagyon szépen skálázható és kibírja a "kábeltesztet - működő gépből kihúzzuk a tápkábel(eke)t, memória nem redundáns, nincs battery backuped memória és cachelünk a merevlemezen. Eddig nem akadt még vele probléma, egy esetet kivéve, mikor tényleg összeszarta magát csúnyán, de abban eléggé ludas volt egy UPS is, ami éppen kisebb hülyeségeket csinált.
Sybase milyen verzió? Milyen optimalizációkat végeztetek vele? Az _én_ tapasztalataim - pénzügyi rendszer, kb 30.000 ember és cég adataival és kb 50 ember bérköltségeivel - nagyon jól működött, míg el nem avult alatta a vas és amíg a fejlesztő cégnél nem jött divatba, hogy a legrosszabb emberüket küldjék ki, aki az optimalizációkról és még a normál formákról sem hallott. De addig semmi bajom nem volt vele.
[quote:7cfd0c5b90="Ago"]Postres-t használunk ... Nagyon szépen skálázható és kibírja a "kábeltesztet - működő gépből kihúzzuk a tápkábel(eke)t, memória nem redundáns, nincs battery backuped memória és cachelünk a merevlemezen. Eddig nem akadt még vele probléma, egy esetet kivéve, mikor tényleg összeszarta magát csúnyán, de abban eléggé ludas volt egy UPS is, ami éppen kisebb hülyeségeket csinált.
MySQL mit szólna egy ilyen "kábelteszthez"? Elvesztene adatokat?
[quote:7cfd0c5b90="Ago"]Sybase milyen verzió? Milyen optimalizációkat végeztetek vele? Az _én_ tapasztalataim - pénzügyi rendszer, kb 30.000 ember és cég adataival és kb 50 ember bérköltségeivel - nagyon jól működött, míg el nem avult alatta a vas és amíg a fejlesztő cégnél nem jött divatba, hogy a legrosszabb emberüket küldjék ki, aki az optimalizációkról és még a normál formákról sem hallott. De addig semmi bajom nem volt vele.
12.5 Linuxon. Táblák átszervezését, indexeket, lekérdezés optimalizálásokat csináltam, de belső finomhagolásokat nem, mert nem vagyok különösebben szakértő. A Sybase emberei pedig igen igen drágák...
A sebessége csak az egyik baj, rengeteg apró kényelmetlenség van vele. Például a dump nem hordozható operációs rendszerek között, a Sybase Central az adatbázis szerkezetet SQL-be 30-40 apró hibával tette ki, a triggereket időnként olvashatatlanra formázza meg, nem lehet tranzakción belül új táblát létrehozni, .. stb, stb ...
Az elmúlt hónapban jónéhány ilyen problémába futottam, próbáltam megoldást keresni, de a neten nincsenek források, kivéve a fizetős Expert Excange-t, nincsenek nyilvános levelezőlisták sem. Pythonban programozok, aminek jó a dokumentációja, rengeteg forrás van a neten, ha nem találom a megoldást, van kit kérdezni. Ehhez képest amikor gond van az adatbázissal szörnyen tehetetlennek érzem magam, nincs hova fordulnom, nincs kit kérdeznem... Úgyhogy jól támogatott adatbázisra váltok.
Én aránylag sok adatbáziskezelőt használtam, de a MySQL-től feláll a szőr a hátamon, komoly dolgot nagyon nem érdemes rábízni. Nemrégiben pl. reportoltam nekik egy bugot, miszerint az inner join-os lekérdezések egyszerűen hibás eredményt adnak. Erre elég arrogáns módon közölték, hogy azt ők nem támogatják. Csak azt nem értem, hogy akkor miért nem lehet erre kiírni egy hibaüzenetet, hogy bocs, ezt ne használd.
Egyébként nem csak ezek idegesítő dolgok, hanem vannak neki fura "feature"-jei. Ezt érdemes elolvasni: http://sql-info.de/mysql/gotchas.html
Ha jól támogatottat szeretnél, akkor ott a PostgreSQL vagy a Firebird, mindkettővel nagyon jók a tapasztalataim.
Hozzászólások
Egy pesti ügyfelünknél Sybase ASE fut, sok probléma van vele, úgyhogy váltani akarunk. A legnagyobb gond, hogy rosszul viseli ha többen akarnak írni és olvasni egyszerre egy táblát. Rettenetesen lelassul, lényegében használhatatlan.
30-40 felhasználó van
legnagyobb tábla kb 1 millió tétel
a gyakran használt tábla kb 50 ezer tétel
egyidejű írások egyszerre néhány ezer tétel
Nyílt forrású adatbázisra szeretnénk váltani. Tesztek alapján a MySQL tűnik legjobbnak a feladatra, de nyitottak vagyunk más megoldásra is. Olyan szakértőt keresünk, akinek van tapasztalata ilyen terheléssel. Tud ajánlani adatbázist, vállalja a telepítést, finomhangolást, automatikus mentést, helyreállítást hibánál, folyamatos támogatást,..
Sebők Norbert
sebok1@enternet.hu
Bar nem vagyok annyira otthon az SQL adatbazis-kezelok teren, hogy vallaljam, de egy tanacsot adhatok: MySQL-t tessek elfelejteni... SQL92-rol meg csak nem is hallott szegeny.
http://www.postgresql.org
Nekem a sebesség a fontos, pontosabban az hogy elfogadható időn belül válaszoljon. Inkább programba teszem a tárolt eljárásokat, triggereket, ha erre gondoltál.
Lefuttatam egy kisebb tesztet, 100 tételt 2-en írnak egyszerre, folyamatosan újra és újra, miközben egyvalaki olvassa is. Emelett még fut egy másik írás és két másik olvasás is.
Sybase
- 79 sec átlagos várakozás a 100-as tételre
- 1 sec alatt a másik két olvasásra
- gyakori deadlock üzenetek
PostgreSQL
- 16 sec átlagos várakozás a 100-as tételre
- 1 sec alatt a másik két olvasásra
- gyakori deadlock üzenetek
MySQL
- 3 sec átlagos várakozás a 100-as tételre
- 1 sec alatt a másik két olvasásra
- nincs deadlock üzenet
Tehát erre a feladatra lassú a Postgre is, bár nem ismerem, lehet hogy van valamilyen optimalizálás.
A MySQL-nek van más hátránya azon kívül hogy le van maradva, pl megbízhatóság, hibák, .. Rá lehet bízni egy cég adatbázisát?
Egy adatbazisvaltas egyaltalan nem egy trivialis problema, jol el van aknasitva (avagy olyan dolgokat hasznal amit X adatbaziskezelo tud, Y
amire valtani szeretnenk pedig nem) es a sok-sok query-bol nehany biztosan maskeppen mukodik X-en, mint Y-on.
Eleg regen hasznalunk mar MySQL-t - megvannak a maga hulyesegei. A MySQL "buta adattarolasra" egeszen jol mukodik, de nagyon konnyen el
lehet veszteni benne az adatok konzisztenciajat. A MYISAM tablaformatum
a nem megfelelo finomsagu lockolasi mechanizmus miatt nagyon gyorsan veszit a teljesitmenyebol. Az INNODB egesz jo, de mindig egy kicsit mashogy mukodik.
Egyebkent mit jelent az az "ilyen" terheles, mondjuk tranzakcio/sec-ben merve? Az a 30-40 felhasznalo "mit" csinal?
Az szep es jo, hogy egyszerre probaljak irni, de:
-Milyen tranzakciokezeles van beallitva az adatbaziskezeloknel? Read uncommited, Read commited, Repeatable read, Serializable?
Alapertelmezett tranzakcios elszigetelesegi szintek:
Sybase Repeatable read
Mysql Read commited
sok-sok query-bol nehany biztosan maskeppen mukodik X-en, mint Y-on
Igen, számítok rá, hogy jó alaposan bele kell nyúlni a programba, ez vállalható.
Az INNODB egesz jo, de mindig egy kicsit mashogy mukodik.
InnoDB-t tervezek használni, fontosak a tranzakciók.
Mit értesz azon, hogy mindig egy kicsit másképp működik?
Mik a hibák?
Az a 30-40 felhasznalo "mit" csinal?
Ez egy ügyviteli szoftver, számláznak, cikket keresnek, bevételeznek, könyvelnek, tekintélyes kimutatásokat kérnek le, stb...
Tranzakció / sec, azt nem tudom pontosan. Előfodul, hogy mondjuk 3-5 felhasználó tárol 50-2000 tételnyi adatot különféle táblába, miközben még 3-5 másik felhasználó böngészi a cikkeket, vagy összetett nagy kimutatásokat kér le. Persze lehet ennél több is, kevesebb is egyszerre.
A tapasztalat az, hogy elég egyetlen komoly terhelés (pl egy kimutatás) és megáll a rendszer, senki nem tud dolgozni, míg le nem fut. Főleg ha egyszerre többen kérnek listát, vagy tárolnak sok adatot.
Milyen tranzakciokezeles van beallitva az adatbaziskezeloknel?
Igen, ez jó felvetés. Alapértelmezett volt eddig, az nálam MySQL 4.1.4-en Repeatable read. Kipróbáltam mind a 4-et:
Repeatable read: 3 sec
READ COMMITTED: kicsit lassabb 4 sec
READ UNCOMMITTED: még lassabb 5 sec
SERIALIZABLE: használhatatlanul lassú, akadályozzák egymást
Mashogy mukodik = ajanlom figyelmedbe a changelogokat
Postgresql-ben a default izolacios szint Serializable:
http://www.postgresql.org/docs/current/interactive/sql-set-transaction.html
"Both commands are defined in the SQL standard. SERIALIZABLE is the
default transaction isolation level in the standard; in PostgreSQL"
Egy OLTP rendszer nem kifejezetten hatekonyan mukodik statisztika / olap / adatbanyaszatra - csodat az adatbaziscserevel ne varjatok. De okos megoldasokkal elfogadhato teljesitmenyt lehet kicsikarni a rendszerbol.
(BTW: mi vegul az adatbaziskezelok ezen korlata miatt sajat indexelesi / tomoritesi eljarast csinaltunk a statisztika / adatbanyaszat hasznalhatova tetelere - igy egy query nem harom napig fut, majdnem kizarva mindenkit, hanem 0.1sec alatt:)
[quote:3781773634="sebokn"]Nekem a sebesség a fontos, pontosabban az hogy elfogadható időn belül válaszoljon. Inkább programba teszem a tárolt eljárásokat, triggereket, ha erre gondoltál.
Hali.
A tárolt eljárásoknak az a lényege, hogy a szerverben előre le van forditva és egyszerre egy
"eljáráson belül" több műveletet is végezhetsz.. programmal ugyan ki lehet váltani, de csak a sebesség rovására.
A MySQL-ről meg annyit, hogy valóban gyors, de ezt a sebességet azzal éri el, hogy sokkal kevesebbet tud a "nagyobb tudású" társaihoz képest.. de mivel azt is fejlesztik, az is le fog lassulni, igy lehet, hogy 1-2 év és ugyanolyan "lassú" lesz mint a többiek.
Fri
Postgresql-ben a default izolacios szint Serializable
Kipróbáltam READ COMMITTED-del is, hasonló maradt az eredmény sajnos.
(BTW: mi vegul az adatbaziskezelok ezen korlata miatt sajat indexelesi / tomoritesi eljarast csinaltunk a statisztika / adatbanyaszat hasznalhatova tetelere - igy egy query nem harom napig fut, majdnem kizarva mindenkit, hanem 0.1sec alatt:)
Az nem rossz eredmény... :)
Kb. jövő év elején kezdek egy ilyen kimutatás-készítő programot építeni nekik. Egyelőre azzal kisérletezem, hogy teljes egészében memóriában tartom az adatokat, és indexelt mutatókon keresztül jutok hozzájuk. Ez jó, mert pl 500ezer számla eladási mennyiség helyett csak ezer darabot kell tárolnom, annyi az ismétlődés. És a sebesség is elég jó..
Ti milyen módszert használtok? (már ha el szabad mondanod)
[quote:70ebed4586="Frimen"]A tárolt eljárásoknak az a lényege, hogy a szerverben előre le van forditva és egyszerre egy
"eljáráson belül" több műveletet is végezhetsz.. programmal ugyan ki lehet váltani, de csak a sebesség rovására.
Az a baj, a szerven futó eljárások mindekit feltartanak és csak halmozódnak. Ha ehelyett átteszem a kliensre a számításokat, akkor csak azt az egyetlen klienst tartom fel és tehermentesítem a szervert.
(legszivesebben teljesen elosztott rendszerrel szeretnék dolgozni, ahol nincs is szerver, mindenki tárolja az adatoknak azt a részét, amit használ és frissítik egymás között, ... sajnos nem sok ilyen kezdeményezésről tudok)
Javaslom kipróbálásra a Firebird 1.5.1-et is. Elődjeit is, ezt a verziót is használjuk közepes méretű (> 2GB, rekordszám>1000000 néhány táblában) adatbázisokkal, sok (és sokféle műveletet végző) felhasználóval.
Egyszerű a telepítés, tipusfeladatokra könnyű a konfigurálás. Léteznek hozzá jó admin progik, de mindent lehet parancssorból is - még win alatt is. :-)
Nagyon jól használhatóak a triggerei, tárolt eljárásai. Gyenge pontja a jogosultságkezelésben, hogy az egyes objektumok tulajdonosi joga nem ruházható át, tehát meggondoltan kell létrehozni a táblákat, tárolt eljárásokat.
A tranzakciókezelése jól sikerült, még nem tudtam úgy összeomlasztani, hogy ne konzisztens állapotot kapjak (és mindig tudtam menteni a meghibásodott adatbázisból is).
Ha segítség kell a használathoz, optimalizációhoz, tudok segíteni.
Mozsi
[quote:4f9e899015="Mozsi"]Javaslom kipróbálásra a Firebird 1.5.1-et is. Elődjeit is, ezt a verziót is használjuk közepes méretű (> 2GB, rekordszám>1000000 néhány táblában) adatbázisokkal, sok (és sokféle műveletet végző) felhasználóval.
Köszi, jól hangzik, teszek egy próbát.
[quote:4f9e899015="Mozsi"]Ha segítség kell a használathoz, optimalizációhoz, tudok segíteni.
Ok, kereslek, ha végül ezt választom.
A tarolt eljarasok - a tevedesek elkerulese vegett - nincsenek forditva (ertsd: runtime kodgeneralas, muveletek sorrendje) az adatbaziskezeloben (bar kivetelt tudok:).
Az optimalis vegrehajtasi terv fugg az adatbaziskezelo pillanatnyi allapotatol, tartalmatol igy ertlelme nincs joelore letarolni. Raadasul egy tarolt eljaras vegrehajtasanak nehany trivialis peldatol eltekintve egyaltalan nem becsulhetok az input parameterekbol. (Es a tablak tartalmarol meg szo sem esett, mert azok is valtozhatnak - es valtoznak is)
Ha sok gyakori query van, akkor ajanlom figyelmedbe a PREPARED query-ket, a legtobb adatbaziskezelo (pl.: postgres, oracle) valamilyen szinten tudja cachelni a lekerdezes terveit. (avagy az adatbazis allapota nem mindig valtozik olyan nagyon gyorsan, hogy a mar elkeszitett tervek sokkal rosszabbak lennenek)
[quote:eadc387a6b="handler"]A tarolt eljarasok - a tevedesek elkerulese vegett - nincsenek forditva (ertsd: runtime kodgeneralas, muveletek sorrendje) az adatbaziskezeloben (bar kivetelt tudok:).
Kivétel például a Firebird is. Tervezd előre az indexeidet, akkor nincs gond. :-) Egyébként lehet frissíteni a tervet, ha megváltoztattad a végrehajtási feltételeket. Normális üzemben (értsd: nem zajlik fejlesztés az éles adatbázison) ez nem okoz gondot, sőt.
[quote:eadc387a6b="handler"]Ha sok gyakori query van, akkor ajanlom figyelmedbe a PREPARED query-ket, a legtobb adatbaziskezelo (pl.: postgres, oracle) valamilyen szinten tudja cachelni a lekerdezes terveit. (avagy az adatbazis allapota nem mindig valtozik olyan nagyon gyorsan, hogy a mar elkeszitett tervek sokkal rosszabbak lennenek)
Csak azokat a query-ket tudják így kezelni az adatbázismotorok, amelyeknél csak a query-ben lévő konstansok változnak meg, a query szerkezete azonos. Legtöbbször csak akkor használhatod ki ezt a lehetőséget, ha beágyazott sql-lel vagy az adott adatbáziskezelőhöz tartozó fejlesztőeszközzel dolgozol.
Azért azt se tessék elfelejteni, hogy a MySQL nem tud stored procedurest (ill. az ötös tud, de az szerintem még öngyilkosság, ha cégnél élesben váltasz rá)
Én nagyon szeretem a MySQLt, egyszerű weboldalak mögé ideális, de számlázást sok juzerrel én nem bíznék rá...
[quote:c3bfd7ac02="drojid"]Én nagyon szeretem a MySQLt, egyszerű weboldalak mögé ideális, de számlázást sok juzerrel én nem bíznék rá...
Van egy ilyen hangulat a MySQL körül, hogy nem megbízható. Ez csak rossz beidegződés, vagy tényleg féltenem kell az adataimat MySQL-ben? Van valakinek tapasztalata adatvesztéssel például, vagy hogy lefagy, vagy hibásan működik a backup, ilyesmi... ?
http://openacs.org/philosophy/why-not-mysql
Ellenőrizni kellene, hogy ezekből mit oldottak már meg...
btami
Nekem nem volt még vele rossz tapasztalatom, igaz, nagyon nagy rendszert nem is bíztam még rá. Majd most decemberben... Ha januárban még élek, akkor igenis megbízható és terhelhető... :)
[quote:82a056f2ca="btami"]http://openacs.org/philosophy/why-not-mysql
Ellenőrizni kellene, hogy ezekből mit oldottak már meg...
btami
Hát, itt a few more detailsből a "nincs subquery", "nincs trigger" és a "nincs tárolt eljárás" még most is él, úgy tudom... :( Legalábbis a négyes MySQL esetében...
És ezek azért elég komoly hiányosságai... :(
Hello,
mi használunk ügyviteli rendszernél - számlázás, kimutatások, adatszerkesztés, néhány változó adat kezelése, de az állandóan - napi 50 új - az összs meglévő mellé ! - jövő adatot. Az 50 nem tűnik sokank, de napi 50 új adat, mely mindenképpen benne marad a db-ben és ezekkel végzett különféle műveletekből származó új adatok és sorok egészen szép számot tudnak generálni. A lekérdezések pedig _nagyon_ összetettek tudnak lenni. Postres-t használunk. Jobban skálázható, egyetlen hátránya, hogy találnod kell olyan időszakot, amikor hetente tudod vacuum-ozni, mert az kell neki néha. BLOB adatok - szkennelt számlamásolat, cégbejegyzések szkennelve stb - külön shared object-tel teljesen jól használható, de ekkor már kell alkalmazni különféle triggereket is, és a vacuum_lo-t is. Nagyon szépen skálázható és kibírja a "kábeltesztet - működő gépből kihúzzuk a tápkábel(eke)t, memória nem redundáns, nincs battery backuped memória és cachelünk a merevlemezen. Eddig nem akadt még vele probléma, egy esetet kivéve, mikor tényleg összeszarta magát csúnyán, de abban eléggé ludas volt egy UPS is, ami éppen kisebb hülyeségeket csinált.
Sybase milyen verzió? Milyen optimalizációkat végeztetek vele? Az _én_ tapasztalataim - pénzügyi rendszer, kb 30.000 ember és cég adataival és kb 50 ember bérköltségeivel - nagyon jól működött, míg el nem avult alatta a vas és amíg a fejlesztő cégnél nem jött divatba, hogy a legrosszabb emberüket küldjék ki, aki az optimalizációkról és még a normál formákról sem hallott. De addig semmi bajom nem volt vele.
[quote:7cfd0c5b90="Ago"]Postres-t használunk ... Nagyon szépen skálázható és kibírja a "kábeltesztet - működő gépből kihúzzuk a tápkábel(eke)t, memória nem redundáns, nincs battery backuped memória és cachelünk a merevlemezen. Eddig nem akadt még vele probléma, egy esetet kivéve, mikor tényleg összeszarta magát csúnyán, de abban eléggé ludas volt egy UPS is, ami éppen kisebb hülyeségeket csinált.
MySQL mit szólna egy ilyen "kábelteszthez"? Elvesztene adatokat?
[quote:7cfd0c5b90="Ago"]Sybase milyen verzió? Milyen optimalizációkat végeztetek vele? Az _én_ tapasztalataim - pénzügyi rendszer, kb 30.000 ember és cég adataival és kb 50 ember bérköltségeivel - nagyon jól működött, míg el nem avult alatta a vas és amíg a fejlesztő cégnél nem jött divatba, hogy a legrosszabb emberüket küldjék ki, aki az optimalizációkról és még a normál formákról sem hallott. De addig semmi bajom nem volt vele.
12.5 Linuxon. Táblák átszervezését, indexeket, lekérdezés optimalizálásokat csináltam, de belső finomhagolásokat nem, mert nem vagyok különösebben szakértő. A Sybase emberei pedig igen igen drágák...
A sebessége csak az egyik baj, rengeteg apró kényelmetlenség van vele. Például a dump nem hordozható operációs rendszerek között, a Sybase Central az adatbázis szerkezetet SQL-be 30-40 apró hibával tette ki, a triggereket időnként olvashatatlanra formázza meg, nem lehet tranzakción belül új táblát létrehozni, .. stb, stb ...
Az elmúlt hónapban jónéhány ilyen problémába futottam, próbáltam megoldást keresni, de a neten nincsenek források, kivéve a fizetős Expert Excange-t, nincsenek nyilvános levelezőlisták sem. Pythonban programozok, aminek jó a dokumentációja, rengeteg forrás van a neten, ha nem találom a megoldást, van kit kérdezni. Ehhez képest amikor gond van az adatbázissal szörnyen tehetetlennek érzem magam, nincs hova fordulnom, nincs kit kérdeznem... Úgyhogy jól támogatott adatbázisra váltok.
Én aránylag sok adatbáziskezelőt használtam, de a MySQL-től feláll a szőr a hátamon, komoly dolgot nagyon nem érdemes rábízni. Nemrégiben pl. reportoltam nekik egy bugot, miszerint az inner join-os lekérdezések egyszerűen hibás eredményt adnak. Erre elég arrogáns módon közölték, hogy azt ők nem támogatják. Csak azt nem értem, hogy akkor miért nem lehet erre kiírni egy hibaüzenetet, hogy bocs, ezt ne használd.
Egyébként nem csak ezek idegesítő dolgok, hanem vannak neki fura "feature"-jei. Ezt érdemes elolvasni: http://sql-info.de/mysql/gotchas.html
Ha jól támogatottat szeretnél, akkor ott a PostgreSQL vagy a Firebird, mindkettővel nagyon jók a tapasztalataim.