Firebird vs MsSQL vs egyeb SQL serverek

Firebird vs MsSQL vs egyeb SQL serverek
2002-12-19T11:28:42+01:00
2004-02-06T11:07:57+01:00
2022-11-01T19:55:36+01:00
  • szóval biztosan nagyon kúl dolog ez, de azér egy text file sorainak a megszámozása nem biztos, hogy meg kell, hogy haladja egy ilyen program képessségeit


    Ezt kifejtenéd bővebben? Mondjuk úgy, hogy reprodukálni is lehessen, hogy létezik-e a hiba, mert elég valószinűtlennek hangzik... (az meg, hogy nem tudja melyik sor a hibás az nonsense, azért használják pár millióan ennél "picit" bonyolultabb feladatok megoldására is. és remélem nem olyanról beszélsz, hogy szemantikailag valamit elrontottál előrébb, de a hiba egy későbbi pontban jön elő (mondjuk az eljárás meghivásakor) és meglepődsz, hogy miért a meghivásnál jelzi a hibát...)
    Egyébként DTS-ről beszélsz? Mert az mellesleg nem az mssql engine része...

    Mivel az a dolog ölég gyönge, van hívási mechanizmus akármilyen object kód meghívására


    Az már megint más tészta, mssql-ből is hivhatsz bármilyen kódot, itt arról volt szó mit támogat az engine. (te hangsúlyoztad külön ki, hogy szoritkozzunk az engine-re és ne hozzá kapcsolódo techonlógiákra, különben az én listám végtelen lett volna, hogy mit nem tud pg...)

    A pg-n megmondhatod, hogy hány processz-ben fusson. Ha van elég memória meg CPU, akkor jó sok is lehet. Ez áldásosan növeli a sebességet.


    Aha, csak sajnos a többpéldányos futtatásnak halványan sincs köze a sebességnöveléshez, éppenhogy csökkenti (egymástól veszik el a processzort) ellenben biztonsági (izoláció) és egyéb előnyei vannak (kompatibilitás miatt különböző verziók párhuzamos futtatása stb-stb)
    Az, hogy egy alkalmazás több processzt futtat, hogy ellássa a feladatát az nem többpéldányos futtatás...

    Csak azér kérdem, mert azt majdnem biztos lekörözi a kis kedvencem


    Elhiszem. Ettől még a tényen nem változtat, hogy az oracle, mssql, db2 trió a komoly adatbáziskezelők hirnevét öregbitik, addig a mysql, pg ezekhez képest játékok, csak az utóbbi komolyabb játék mint az előbbi...
    Mutasd a teljes hozzászólást!
  • (És van native pg win-en csak nem könnyű előállítani, lásd bormennyiség fentebb)

    erre gondoltál?
    pg on win

    Te 3 perc alatt megiszol 1 liter bort?
    Mutasd a teljes hozzászólást!
  • Régi 6.5
    Oh kérem az már nem is mssql :))

    Na ja, de a hibák azér' megmaradtak. (példának okáért mondjuk egy kb 20 ezer insert-et tartalmazó text-et kel betölteni (sql2k). Van grafikus túl, nem kell gépelni! File megnyit, zöld nyil megnyom, hibaüzenet sorszámmal Kattintás a message windown a hibaüzenetre, hurrá, ráugrik a jelzett sorra. Igenám, de nem az a hibás szóval biztosan nagyon kúl dolog ez, de azér egy text file sorainak a megszámozása nem biztos, hogy meg kell, hogy haladja egy ilyen program képessségeit)

    gyorsan felnéztem ide itt sem láttam

    Nagyon tetszik köszi a linket, kiteszem az ablakba (eddig még nem láttam ;) ! ugyanezt éreztem, amikor az sql server "leírását" olvastam MS-nél. Hiába, a PR az PR
    Érdemi rész: azér nem láttad, mert valahogy más elven működik a dolog: van egy saját nyelv, ami hasonlít a transactsql-re. Mivel az a dolog ölég gyönge, van hívási mechanizmus akármilyen object kód meghívására (mondjuk legyen fortran :), gyakorlatilag dinamikus linkelés jelleggel. Emiatt a Procedural languages pont takarja ezt, ha jól sejtem.


    [többpéldány] De ezt a programnak is támogatnia kell. (

    Itt nem ugyanarról van szó. A pg-n megmondhatod, hogy hány processz-ben fusson. Ha van elég memória meg CPU, akkor jó sok is lehet. Ez áldásosan növeli a sebességet. És mivel én ugyan nem szakszerűen de dolgoztam(ok) mindkettővel, az MSSQL-nek ezen a téren van egy kis előnye, elsősorban erősebb gépeken (véleményem szerint a gyengébb gépeken a windoz megfogaja az SQL sebességét. ez csak érzés, de látványos, hogy mondjuk egy 600MHz-es procin 256 Mmemóriával a pg gyorsabb (használható), mint az MSSQL 2k (kivárhatalan), addig egy gyorsabb gépen a sebességviszonyok hogyan alakulnak át)

    Webes dolgok: nem látom forradalminak, bár ha azt vesszük a pg-hez valami-t hozzá kell csapni, de a csomag környékén van (PhpPgAdmin v. valami hasonló php-s izé, csak nem emléxem rendesen a nevére) - azaz végső soron tényleg nem a pg része

    [Skálázhatóság:] ... ezt is támogatnia kell a programnak.

    Igen, igen a hozzászólásom végén azért céloztam erre. De lehet, hogy támogatja, meg az is lehet, hogy annyira nem is kell támogatnia, a fene se tudja. A process distribucióval csodadolgokat lehet ám művelni anélkül, hogy az áldozat tudná. A disk rendszer vs pg kérdésről meg 5letem sincs, de majd megkérdezem a CODA-sokat, hogy az jó-e erre.

    Oh, ég és föld... Mssql-en van snapshot replication (megy az egész objektum (view, tábla, sp bármi)), transactional replication (a másik rendszer is végrehajtja ugyanazokat a modositó sql-ek mint a főgép (insert, delete, update), merge replikáció

    Merge nincsen, Másik kettő van. Hatalmas clusterekben nem tudom. Beállításhoz min. 1000 ml minőségi bor szükséges

    Na és mi van a firebird-el? Csak azér kérdem, mert azt majdnem biztos lekörözi a kis kedvencem (És van native pg win-en csak nem könnyű előállítani, lásd bormennyiség fentebb)
    Mutasd a teljes hozzászólást!
  • mssql vizsgád van Régi 6.5


    Oh kérem az már nem is mssql :))
    De a 7-est is lassan el kéne felejteni.

    Mit jelent a többpéldányos futtatás? (ha azt, hogy egy gépen több server is futtaható, akkor ez op.rsz kérdése.)


    Azt. De ezt a programnak is támogatnia kell. (egymást elérjék, driverek támogassák, ne akadjanak össze, együttműködjenek akár replikáció szintjén is stb-stb)

    Milyen előnytjelent az iis integráció konkrétan?


    Pl ilyen http alapú lekérdezéséket 0% programozással, 100% menedzselhetőséggel :))
    http://server/vroot/view_vagy_tábla/xpath_lekérdezés?paraméterek

    vagy

    http://server/vroot?sql="update tabla ..."

    Ilyen alapon a pg-nek meg Apache/PHP/perl integrációja van.


    Ezt erősen kétlem...

    Skálázhatóság: ez pg-nél megint csak op.rsz kérdése.


    Szerintem meg ezt is támogatnia kell a programnak. Persze ahhoz, hogy _optimálisan_ is fusson egy akkora vason. Az mssql a lentebb megnevezett rendszerig van kioptimalizálva, afölött is elfut, de már nem olyan optimálisan. Nos én erősen meglepődnék, ha ilyen szempontból egy pg egy 2 node-os klaszternél tovább lenne optimalizálva...

    Azért azt nem gondoltam volna, hogy fölteszed, hogy nincsen user defined function a pg-ben


    Ezer bocsánat én nem találtam anno benne (ami semmit nem jelent, mert nem kötött le túl sokáig) ezért gyorsan felnéztem ide itt sem láttam (pedig nem egy elhanyagolható funkció, olyan szinten ahogy mssql-ben meg van valósitva sehol sem láttam) ezért irtam.

    Replikáció összehasonlítása: vagy replikál vagy nem. Milyen köztes eset lehetséges?


    Oh, ég és föld... Mssql-en van snapshot replication (megy az egész objektum (view, tábla, sp bármi)), transactional replication (a másik rendszer is végrehajtja ugyanazokat a modositó sql-ek mint a főgép (insert, delete, update), merge replikáció (mikor nincs főgép, mindkét gép kapcsolat nélkül is modosithat, majd kapcsolat létrejöttekor összemerge-elik a változásokat kétirányban)
    És mindezeket igen bonyolult hatalmas klaszterekben tudja. Ja ott van még a windows.ce-re irt mssql.ce az is egy külön replikáció fajta ahogy összeszinkronizál a nagy mssql-ekkel és még sorolhatnám ezeket sokáig, de nem teszem.

    serverless snapshot backup, ez mit jelent


    kicsit a raid tükörhöz hasonlit, egyszerre jelennek meg a változások a rendszer filejain és a backup helyén, igy teljesitmény veszteség nélkül (hardver támogatás esetén, ez esetben ez mssql VDI támogatást jelent) lehet real time backup-ot késziteni és szükség esetén átállni rá az mssql segitségével programozottan.
    Mutasd a teljes hozzászólást!
  • mssql vizsgád van
    Régi 6.5
    És az analysis services önmagában megér többezer oldalt és akár külön termék is lehetne.

    Igen, ez igaz. És ilyen tényleg nincsen (postgres,firebird,mysql)-ben. És tényleg jó, hogy van. És már az elején uezt próbáltam mondani. Valamilyen middleware-t kell a pg-hez hozzá keresni, ha ilyesmit akarsz. Nehéz ügy, fáradságos, és sokat kell izélgelődni.
    Ami a listát illeti:
    (Kicsit zavaró, hogy sok adatbányászathoz meg ilyesmikhez kapcsolódó funkciót is fölsoroltál. Ezek KÉTSÉGTELENÜL előnyök, és ezzel nem is akarok vitatkozni.)
    Auditing, full text serach: OK, hasznos (és nincs pg-ben, legalábbis olyan és úgy)
    XML - middleware-ből megy, pg motorjából nem megy.
    Mit jelent a többpéldányos futtatás? (ha azt, hogy egy gépen több server is futtaható, akkor ez op.rsz kérdése.)
    Milyen előnytjelent az iis integráció konkrétan? (Mondjuk láttam már pár helyet, ahol MSSQL-t használtak, de a web server azér a pacsi volt) Ilyen alapon a pg-nek meg Apache/PHP/perl integrációja van.
    Skálázhatóság: ez pg-nél megint csak op.rsz kérdése. Szegény annyi processzt indít, amennyit csak bír... Aztán hogy ezek hány gép hány processzorán, hány gépen lévő hány disken elosztott adatokkal futnak, az dönti el a skálázást (nameg az, hogy az adatait hogyan tudja elosztani a diskekk meg a memóriák között). Mielőtt még megkérdezed: így nem használtam, két gépes clustert is csak próbaképpen.
    Azért azt nem gondoltam volna, hogy fölteszed, hogy nincsen user defined function a pg-ben
    Replikáció összehasonlítása: vagy replikál vagy nem. Milyen köztes eset lehetséges?
    role alapú hozzáférés: ha létrehozok mondjuk egy "adatrögzítő" csoportot és ennek grantolok beillesztési jogot egy view néhány attributumára, akkor az kielégítő lehet? Ha nem, akkor sajnos stored procedure következik amit ilyenre nem szeretünk alkalmazni
    serverless snapshot backup

    ez mit jelent?

    És a mysql-ről: nem igazán foglalkoztam vele sohasenem (nincsen view, fk, tranzakció, az azér durva), de egyszer kellett egy fürge eszköz (brutálisan gyors). Olyan hírek járnak, hogy valami SAPdb mögéje állt, nem tudom megitélni, de lehet, hogy ez ad neki egy esélyt (mondom ezt én igazhítű pg-ista)
    Mutasd a teljes hozzászólást!
  • Nekem is az xml support jutott elszor eszembe. Ilyen jol kitalalt es gyors megoldas szerintem nincs masik.

    netchan
    Mutasd a teljes hozzászólást!
  • Legelőször megkérdezhetem milyen mssql vizsgád van? (mert furcsa, bármilyen ilyen vizsgával a hátad mögött, hogy megkérdezed miben tud többet egy postreges-nél, vagy hogy még sosem használtál az analysis services-ből semmit...)

    milyen egetverő különbségek vannak mondjuk az MSSQL és a postgres között?


    Egy pár:
    teljes xml támogatás
    clustered index
    skálázhatóság (32 proci, 64 gb ram)
    OLAP támogatás (akár közvetlenül http-ről, iis integráció, ez szitne minden funkcióra igaz nem csak az olapra)
    indexelt view támogatás
    többpéldányos futtatás (nem tudom van-e ps-ben)
    distributed partitioned views (inkább nem kisérelem meg leforditani :)
    Full text search
    english query
    user defined functions
    log shipping
    replikáció (ilyen van ps-ben is, de nem összehasonlitható a kettő)
    serverless snapshot backup
    role alaphú hozzáférés szabályozás (szerver, adatbázis, alkalmazás szinten)
    baromi részletes auditing többszáz event-el

    De ezen kivül igazából azok a funkciók sem összehasonlithatóak a két rendszeren amik "pipa szinten", (ti. hogy ott legyen a feature list-ben) benne vannak mindkét rendszerben...
    És az analysis services önmagában megér többezer oldalt és akár külön termék is lehetne.

    Namost ha ehhez megtartja a sebességét, akkor igen számottevő erő lehet.


    Ezt azt hiszem Sting már kifejtette lejjebb, reális határidőn belül esélye sincsen ilyen lemaradást behozni, de ha mégis sikerülne, akkor meg a sebességét megtartania nincs esélye, de ezt ő szebben leirta valahol lejjebb.
    Mutasd a teljes hozzászólást!
  • de most komolyan, lattal/hasznaltal mar MSSQL-t es Oracle-t komoly munkaban, vagy csak ugy hallomasbol irsz rola?

    MSSQL: csak játék feladatokra (mondjuk 30 tábla, néhány trigger (ugyanis a transact sql nem hordozható), tranzakciók, fk ...
    ORACLE: volt szerencsém 2 évet 8 asozni (sajnos most nincsen). Semmi extra, kb. mint fent, de napi igen sok tranzakció ( ha jól rémlik olyan pár millió körüli )

    Amit nem használtam (és ezért most megkövetek mindenkit, ha félreérthető voltam): analizis tool-ok, adatbányászat, meg efféle csodavarázslatok.

    Amúgy értem én, hogy aki meg mer említeni egy postgres-t, azt le kell sajnálni, mint szellemileg csökkentértékűt (Ugyanez volt a helyzet, amikor Microsft MSSQL-es vizsgámra mertem hivatkozni felvételi beszélgetéseken oracle-s helyeken)
    de ennek ellenére szerényen, mint az osztály lehhüjjébb tanulója azt szeretném megkérdezni, hogyha csak az adatbázismotor szolgáltatásait nézzük, akkor milyen egetverő különbségek vannak mondjuk az MSSQL és a postgres között?
    Hangsúlyozom: csak a motor! Analizis túl és csodavarázsló nem ér (mert olyan nincsen is a postgres-hez, ami egy nagy hátrány, dehát az árát nem kérhetem vissza )

    Amúgy az eredeti kérdésben volt egy interBase vagy firebird említés, amivel azér összemérhető a postgres elég erősen (és egyáltalán nem biztos, hogy firebird nyer )

    És mint hülyegyerek, szeretném megkérdezni az okos bácsikat: láttatok má mostanában postgrest?

    (amúgy lassan, de biztosan a mySQL is eljut a foreign key + view szolgáltatásig. Lehet, hogy má a triggeren is dolgoznak a fejlesztők... valami tranzakciókezelés is lehetséges... Namost ha ehhez megtartja a sebességét, akkor igen számottevő erő lehet. de ez jövő idő és feltételes mód)
    Mutasd a teljes hozzászólást!
  • Kozben ugye leesett, hogy kitol es miert kerdeztem?


    Hopp, most mondod, tényleg
    Bocs, de valamiért olyan magaménak éreztem a kérdést
    Mutasd a teljes hozzászólást!
  • Kozben ugye leesett, hogy kitol es miert kerdeztem?
    Mutasd a teljes hozzászólást!
  • Üdv az Uraknak!
    Végigolvasva a hozzászólásokat csak annyi megjegyzésem lenne, hogy picit az az érzésem, hogy aki a MySQL-el dolgozott komolyabb projekten először az nem igazán érti, mit lehet itt még "fokozni" az Oracle/MSSQL/Interbase/stb-ben, aki pedig az utóbb említettekkel kezdte nem érti, hogyan lehet a MySQL-t egy lapon említeni ezekkel Más területek, más elvárások, más projekt-méretek, és nem túl jellemző az "átjárás".
    Szerintem hasznos lenne, ha tényleg csak az mondana véleményt egy ilyen átfogó kérdésben, aki végigcsinált több nagyobb projektet az említett adatbázis-kezelőkkel (miheztartás végett nagyobb projekt: időtartam >6 hónap, min 4-5 fejlesztő, stb szvsz).

    Mutasd a teljes hozzászólást!
  • lattal/hasznaltal mar MSSQL-t es Oracle-t komoly munkaban, vagy csak ugy hallomasbol irsz rola?


    Igen, mssql-t eléggé jól ismerem, sokat használom. Oracle-t nem ismerem jól, mint irtam is. De azon nem kell meglepődni, ha egy mssqlt (vagy oracle-t vagy db2-t) ismerő ember a postgres-re csak elhúzza a száját, ez nem véletlen van igy. Az előbbiek komoly adabázis kezelők, utóbbi egy mysql-nél valamivel komolyabb játékszer...
    Mutasd a teljes hozzászólást!
  • nagybeno: de most komolyan, lattal/hasznaltal mar MSSQL-t es Oracle-t komoly munkaban, vagy csak ugy hallomasbol irsz rola?
    Mutasd a teljes hozzászólást!
  • Nohát biztosan igazad van

    De mondjuk egy profi oracle hivő pontosan úgy beszél az mssql-ről, mint Te a postgres-ről. És aszem, hogy ugyanannyira van igaza.

    Mutasd a teljes hozzászólást!
  • Esetleg postgres, hogy necsak fizetősről...


    Nocsak-nocsak, melyik új yukon (de tudod mit sql2k-ban megjelent) technológia található meg postgres-ben? Kiváncsian várom a listát.

    De szivesen vennék egy listát az új yukon funkciókról amik oracle-ben vagy db2-ben már benne vannak. Biztos van ilyen, de biztos, hogy van egy csomó ami meg azokból hiányzik.

    Igen, a reklámoldalon mint extra ficsört emlegetik a clusteringet, úgy egészben


    Aha, ez egy táblázat. Baloldalt "főcim" mellette kifejtve. Mellette ezzel kezdődik: Analysis services improves...
    Ha ilyen "mélységében" sikerült átolvasnod, akkor hagy ne vitázzunk már erről jó?

    "Amúgy mit jelent a clustering az analysys servicesre vonatkoztatva?"

    Minden bizonnyal azt, hogy az analysis services mostantól klaszterezhető... Az ugyanis egy külön szolgáltatás volt, "nincs köze" magához az sql serverhez. Mig az sql szerver sok-sok éve klaszterezhető addig az analysis services nem. Felrakhattad akárhány gépre nem volt kapcsolat köztük.

    Láttam valaha mssql2k-t, semmivel nem adott többet, mint a postgres


    Úristen... Akkor a mssql2k-ban is legalább olyan elmélyedhettél mint a yukon új feature-okban...

    Nálad miért nem az az etalon ?


    Mert én is csak messziről láttam :)

    Szóval TÉNYEK kellenének nekem


    Beszéljünk róla. Melyik új yukon feature melyik másik nagy dbms-ben van már benne? mondjuk oracle és db2, postgrest szerintem felejtsük el, mert komolytalan ezek mellett.
    Mutasd a teljes hozzászólást!
  • mysql már biztos a 60-as években támogatta mindezt,

    A mysql-el az a baj, hogy minden linuxot csepülő ember feltételezi, hogy a linux-osok nem láttak mást.
    Igenám, de van egy Oracle nevű cég, aki csinált ezt-azt a Network Computer mellett. Akad DB2 is. Esetleg postgres, hogy necsak fizetősről...

    clusterint feltalálása a yukonban? Hmm, láttál te már mssql2k-t valaha?
    Ja, hogy az az analysis services-re vonatkozik? Sebaj, jól hangzott, csak igy tovább...

    Igen, a reklámoldalon mint extra ficsört emlegetik a clusteringet, úgy egészben. Nézdd meg nyugodtan! Amúgy mit jelent a clustering az analysys servicesre vonatkoztatva?
    Láttam valaha mssql2k-t, semmivel nem adott többet, mint a postgres (a sebességét soha nem mértem, de ha van adatod mssql2k vs. postgres7.4 -ről, akkor várom). Mielőtt rákérdezel: oracle-t is láttam messsziről. Nálad miért nem az az etalon ?

    Amúgy csak annyit mondtam, hogy nem láttam semmiféle forradalmi dolgot első olvasásra, ettől a Yukon lehet jó is meg rossz is.
    Az egész úgy néz ki, mint amikor az NT feltalálásakor a védett módú futtatást bemutatták, mint forradalmi ujdonságot. Egyetlen szakembert sem zavart, hogy a tök elavult u*ix kezdetektől úgy épült fel, hogy a kernel és user módot szétválasztotta.

    Mint eredetileg IS említettem: jöhet lista a forradalmi ujdonságokról, mer lehet, hogy éppen a marketincsőbe mentem bele.
    Vagy szivesen fogadok linket olyan helyre, ahol mondjuk max. 2 oldal terjedelemben megmutatják, hogy technikailag mi a forradalmi a Yukon-ban (félreértések elkerülése végett: nem az sql server 3.93-hoz képest )

    Szóval TÉNYEK kellenének nekem

    Az új mosóporom jobban mos, mint az uj mosóporom!
    Mutasd a teljes hozzászólást!
  • Kár, hogy sokan mások már korábban kitalálták


    Tudom-tudom a mysql már biztos a 60-as években támogatta mindezt, oly sokminden mással ami az mssql-ből még ma is hiányzik...

    clusterint feltalálása a yukonban? Hmm, láttál te már mssql2k-t valaha?
    Ja, hogy az az analysis services-re vonatkozik? Sebaj, jól hangzott, csak igy tovább...
    Mutasd a teljes hozzászólást!
  • De az igazi durranás a yukon lesz...


    Hát ami a MS weboldalon van, az leginkább a tisztább, szárazabb érzésre asszociál bennem .
    Ami a technikai ujdonságokat illetti, olyan "forradalmi" ujdonságokat nem láttam ottan. Kétségkivül itt az ideje a replikáció, HA clustering, on-line backup/restore meg más effélék feltalálásának
    Kár, hogy sokan mások már korábban kitalálták

    (kb. 10 weboldal szárazérzés után meguntam az olvasást. Ha valamilyen extra újdonság elkerülte a figyelmememet, szívesen veszem a szememrevetését)
    Mutasd a teljes hozzászólást!
  • Ha jól sejtem az RPM azt használja RedHat-on !?
    Mutasd a teljes hozzászólást!
  • bocs, hogy beleszólok, de nem csak table és rekord lock van... Legalábbis mssql-ben biztosan nem. Ott van egy page lock is (8k). Az optimizer pedig real time dönt, hogy mikor melyiket használja... Pl. egy where nélküli update-nél nem fog sem rekord sem page lock-ot csinálni, mert mire ezen a sok fogdmeg-ereszdel-t eljátsza rajta addigra table-lock-al már rég végezne... De a kettő között nagyon jó átmenet a page lock.

    Személyes véleményem mssql 2000 után mysql-hez leülve az volt, hogy az utóbbi egy játékszer az előbbi meg egy adatbázis szerver. (az optimizer pl. egy fantasztikusan eltalált alrendszer benne) De természetesen aláirom, hogy kis igények mellett jó választás lehet a mysql is. Pénzügyileg mindenképpen, hacsak nem a hiányzó tudása miatt milliók folynak ki a hibakeresésre, foltozásra, workaroundokra...
    De az igazi durranás a yukon lesz...
    Mutasd a teljes hozzászólást!
  • Jah, az a sima fajl-alapu adatbazis ahol minden kulcshoz 1 ertek tartozhat. Nem relacios adatbazis, viszont gyors. Nehany dologra egesz jol hasznalhato.
    Mutasd a teljes hozzászólást!
  • Valakinek van tapasztalata a Berkeley DB-vel? Soha nem hallok rola semmit, pedig egy halom helyen hasznaljak, szinte minden kornyezetnek van konyvtara hozza, stb Most pl mint Subversion backend bukkantam ra, de a Zope is tudja hasznalni a ZODB helyett.

    netchan
    Mutasd a teljes hozzászólást!
  • "1. INSERT INTO VALAMI...
    2. UPDATE VALAMI...
    3. SELECT * FROM VALAMI WHERE..."

    Igen, az a 3 utasítás táblalocknál egymás után fog futni nem egyszerre, rekordlocknál meg esély van hogy egyszerre.

    De mit is jelent ez nekünk? Semmiképp sem azt hogy egyik vagy másik módszer abszolút jobb.

    (Tekintsünk most el az aszinkron io-tól, és feltételezzünk a processzorok számánál több threadet/connectiont - egy processzornál ezt nem nehéz ).

    A párhuzamosítás egy tradeoff, lerontja a teljesítményt viszont javítja az átlagos válaszidőt.

    A kérdés mire van szükséged. Ha a rendszered úgy alakult (vagy úgy alakítottad), hogy döntően csak rövid sql utasítások vannak benne, akkor jobban jársz az olcsóbb táblalockokkal. (összteljesítmény nagyobb lesz, átlagos válaszidő pedig az utasítások homogenitásától függően lehet akár jobb, akár rosszabb, mint rekordlokkosnál, de semmiképp se lesz különösebben hosszú.)
    Mutasd a teljes hozzászólást!
  • "Gondolj egy fórumra, ott is van update, ott is van bőven egy-többes kapcsolat, mégis különösebb gond nélkül meg lehet csinálni tranzakció nélkül."


    Tudsz olyan példát is mondani, ahol valóban van konkurrenciahelyzet? Nézd csak meg bármelyik hazai fórumot... Az már nagyon menő hely, ahol órákon keresztűl legalább 5 percenként van 1 hozzászólás! Én olyan rendszerre gondolok, mely komolyabb terhelésnek van kitéve. pl. minimum 5-10 SQL utasítás másodpercenként!

    És mint mondtam, ezt a szintet pl. egy menő web-es társkereső rendszerrel simán megütöd...

    Az más kérdés, hogy ezen az oldalon számos olyan "hiba" előkerül, mely a nem SQL gondolkodásmódból akad... De ezt egyszer már említettem itt, a tárolt eljárásokkal kapcsolatban :)


    Mutasd a teljes hozzászólást!
  • "Namármost egy multi-thread -ben elért adatbázisnál, - amiben nem csak select-ek vannak - tutti rossz megoldás tranzakció nélkül dolgozni."

    Gondolj egy fórumra, ott is van update, ott is van bőven egy-többes kapcsolat, mégis különösebb gond nélkül meg lehet csinálni tranzakció nélkül.

    Nagyon rossz példa. Egy fórumnál nagyon alacsony a konkurrenciahelyzet. Sokkal érdekesebb már mondjuk egy adszerver, vagy egy forgalmat mérő auditszerver. Főleg, ha nem egy oldalt szolgálnak ki, hanem 10-et, vagy 100-at.

    "Hogy lesz megbízható a lekérdezés által nyújtott adat, ha közben mindenki módosítja?"

    pl. engem érdekel, hogy mennyit adtunk el és mekkora értékben. De nem érdekel fillérre.

    Mondom, hogy nagyon szűk körben és nagyon nem valós alkalmazásokon lehetnek csak tapasztalataid. Ezek a dolgok nem így működnek. Egy pénzügyi rendszerben - bármennyire kis forgalmat is bonyolít, és bármennyire nem számítanak a fillérek - nem engedhető meg kis mértékű pontatlanság sem, mert onnantól kezdve nem fognak stimmelni a számok (a két különböző módon kihozott végösszeg pl.), és így nem működhet egy elszámoló rendszer.

    Egyébként azért is rossz az érvelés, mert amikor konkurrenciahelyzet miatt adat-/szinkronvesztés lép fel, akkor az adatbáziskezelő nem priorizál a filléres és a milliós tételek között, így utóbbiak statisztikailag pontosan ugyanolyan valószínűséggel "esnek ki", mint előbbiek. De ugye ez már azért nem olyan filléres kérdés.

    Nagyon kevés feladat az, ahol valóban a modell szintjén megengedhető az adatvesztés - ha szükséges.

    Ez egy webes alkalmazásokra optimalizált adabáziskezelő, nem kevesebb nem több. Ezen a területen tényleg ász.

    Nem értünk egyet. Számomra az egyetlen hasonló, de elfogadható kijelentés a MySQL-lel kapcsolatban: "van olyan feladat, amihez ez az optimális választás". De azt, hogy úgy áltlánosságban ász lenne akár még csak a webes alkalmazásokhoz is, nem tudom elfogadni.

    Ne felejtsük el, hogy maga az a tény, hogy egy rendszer jól működik (és akkor még nem is említettetm azt, hogy magát a hibázást is nehéz ellenőrzések hiányában észrevenni), nem feltétlenül jelenti azt, hogy optimális megoldással van dolgunk, és ne lehetne más eszközökkel még jobb megoldást nyújtani egy adott problémára!
    Mutasd a teljes hozzászólást!
  • "Namármost egy multi-thread -ben elért adatbázisnál, - amiben nem csak select-ek vannak - tutti rossz megoldás tranzakció nélkül dolgozni."

    Gondolj egy fórumra, ott is van update, ott is van bőven egy-többes kapcsolat, mégis különösebb gond nélkül meg lehet csinálni tranzakció nélkül.

    "Hogy lesz megbízható a lekérdezés által nyújtott adat, ha közben mindenki módosítja?"

    pl. engem érdekel, hogy mennyit adtunk el és mekkora értékben. De nem érdekel fillérre.

    "Miért ne törölhetnénk egyessével???"

    Nálam nem volt jellemző, hogy valamelyik rendszerünkben egyesével törölgettünk volna.


    "Legyen inkább csak "alkalmazás""

    mondjuk én alkalmazásszerverről beszéltem, sima kliensek önállóan nem tudnak szinkronizálni

    "Baromi gyors és hatékony módszert fogsz elérni akkor, ha minden SQL utasítást table lock-al végzel"

    az kizárt hogy mindegyiket lockolni kellene, mert egy darab sql utasítást nem kell lockolni, csak ha több összefüggő van és akkor is csak ha konzisztenciaproblémák lehetnek. De tiszta sor, ha az utóbbi eset a jellemző akkor rekord lockos táblát kell használni.

    teljesítmény erőforrás stb: félreértés ne essék nem is azt mondom, hogy a mysql az abszolút ász. Ez egy webes alkalmazásokra optimalizált adabáziskezelő, nem kevesebb nem több. Ezen a területen tényleg ász.
    Mutasd a teljes hozzászólást!
  • "Oké, de az 15-20 thread csak nem tud egyszerre futni, hanem hol az egyik hol a másik fut. Táblazárolás üzemszerű esetben annyit jelent, hogy átrendeződik a sorrend."

    Ez így ebben a formában nem igaz.


    Adott pl. 3 SQL utasítás:

    1. INSERT INTO VALAMI...
    2. UPDATE VALAMI...
    3. SELECT * FROM VALAMI WHERE...


    Na most ezek egy korrekt, multi-thread SQL szervernél bizony egyszerre fognak futni. Azért multi-thread.

    Ne azt, nézd, hogy a processzor egyszerre csak egy utasítást fog végrehajtani és emiatt "kapcsolgat" az alkalmazások között... A table lock ebben az esetben az 1 utasítás elkezdésekor rákerül a táblára. A 2. utasítás ilyenkor kénytelen várni az első utasítás teljes végigfutásához. A 3. utasítás meg mindkét utasítást meg kell, hogy várja a table lock miatt... És lehet, hogy ez a második UPDATE miatt akár X másodpercig is eltart...

    Tranzakciós adatbázisnál ez a 3 utasítás egyszerre, 3 thread-ben fog lefutni úgy, hogy közben egyik utasítás sem vár a másik utasítás befejezésére, hogy feloldódjon a table lock. Ugyanis, minden normális SQL szerver record lock-ot alkalmaz...
    Mutasd a teljes hozzászólást!
  • Sting ez a szoftver egy éve működik gond nélkül, és bár semmit nem tudsz a vele szemben támasztott követelményekről, folyamatosan azt sugallod, hogy ezekre a követelményekre rossz megoldást adtunk.

    Nem ezt mondtam. Hanem azt, hogy az, hogy TE azt HISZED, hogy jó és optimálishoz közeli a megoldásod, az egyáltalán nem jelenti azt, hogy AZ IS. Ezt a véleményem pedig arra alapozom, amiket tőled hallottam itt adatbáziskezeléssel kapcsolatban. (Én magam egyáltalán nem nevezném a téma szakértőjének, de az már nyilvánvalóvá vált számomra, hogy neked nálamnál is jóval nagyobb hiányosságaid, és ha mást nem hát a spektrumot tekintve szegényesebb tapasztalataid vannak, mint nekem.)

    Egyébként ha megosztanád velünk a konkrét részleteket, akkor elolaszthatnád az esetleges kételyeket a megoldás megalapozottságával kapcsolatosan.
    Mutasd a teljes hozzászólást!
  • "Amit egy táblazárolás egyprocesszoros gépen effektíve blokkol, az az arra a táblára vonatkozó aszinkron io. Az az egy dolog, ami ténylegesen párhuzamosan mehetne."

    Mondjuk ez így explicit lock esetén nem igaz, mert akkor is csak az io-t blokkolja, de hosszabb ideig a lock utasítás végrehatásától számítva az unlock befejezéséig.
    Mutasd a teljes hozzászólást!
  • Oké, de az 15-20 thread csak nem tud egyszerre futni, hanem hol az egyik hol a másik fut. Táblazárolás üzemszerű esetben annyit jelent, hogy átrendeződik a sorrend.

    Amit egy táblazárolás egyprocesszoros gépen effektíve blokkol, az az arra a táblára vonatkozó aszinkron io. Az az egy dolog, ami ténylegesen párhuzamosan mehetne.

    (Persze adott esetben lehet hotspot egy táblazárolásból, és ha nem bírja a gép sebességgel, akkor tényleg más megoldást kell keresni).

    A táblazárolás eleve akkor jöhet szóba, ha nem az a jellemző, hanem csak a kivétel. Az egész szisztéma nagyon rövid lekérdezéseket és update-eket feltételez.

    Egy valami viszont ténylegesen idegesítő, ha a mysql nemtranzakciós tábláján (ez a táblazárolós) *hosszú* sql műveletet futtatsz, akkor addig blokkolva lesz mindenki más (ha csak olvas mindenki akkor persze nem). És azért az gyakran adódik, hogy valami speciális lekérdezést kell futtatni, ami bizony hosszú lesz. Elméleti megoldás erre is van, egy master-slave dupla adatbázis felállás, de pusztán az egyedi lekérdezések miatt önmagában erős túlzás.

    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd