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
  • "A valós életben nagyon ritkán törekszünk a száz százalékos pontosságra"

    Ez itt nem erről szól. Ha már tervezési időben is tudni lehet, hogy a választott eszköz ilyen-olyan okból fogva alkalmatlan a feladatra, akkor ki kell zárni az alkalmazását. 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.

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


    "informatikában amúgyis ritkán törlünk adatokat "

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


    "PHP alkalmazásszervernek? Nem hallottam, hogy PHP-ben bárki megkísérelt volna alkalmazásszervert írni. Java és C++.

    adatbáziskezelőben (konkrétan mysql-ről beszélünk ugye) szinkonizálni nem úgy kell, hogy átírod a forrását, hanem pl. zárolod a táblákat egy atomi műveletként végrehajtott utasításban."

    Ami a PHP-t illeti valóban nem elkalmazásszerver írására való, de nem is így értettem a mondatot. Legyen inkább csak "alkalmazás"... OK?


    " zárolod a táblákat egy atomi műveletként végrehajtott utasításban"

    Baromi gyors és hatékony módszert fogsz elérni akkor, ha minden SQL utasítást table lock-al végzel. Mindezt pont egy webszerveren, ahol a felhasználók száma állandóan változik és egymásról semmit sem tudnak... Mi lesz akkor, ha ráugrik 20 user egyszerre?

    És ha utána számolsz, akkor ez nem is olyan nagy szám. Példaként: adott egy konkrét társkereső rendszer - nevet most nem írnék - ahol forgalmasabb időpontokban egyidejűleg 7-800 user is bent van. Van egy egyszerű "monitor" mely 20 másodpercenként frissül és jelzi a chat-kéréseket és a kapott leveleket. A vonal tulsó végén egyszerre legalább 3-an updatelik ezt a táblát :)

    Nos számításaim szerint, ezt a táblát így másodpercenként 30-40-szer kell teljes lock ba tenni!

    Ezért nem jó megoldás webserverre a table lock...


    "nézzük indirekten: vajon MYSQL AB miért hagyta volna defaultnak a nem tranzakciós táblatípust ha a tranzakciós abszolút értelemben jobb?"

    Azért, mert a tranzakciós megoldás egyértelműen erőforrásigényesebb és lassabb is mint a régimódi "dirty-read"-os módszer... És ha ez lenne a default, akkor szegény user elvesztené azt az érzését, hogy a MySQL footprint-je töredéke a többi komoly SQL szervernek és mégis milyen gyors...





    Mutasd a teljes hozzászólást!
  • "De nem kell démonizálni a táblazárolást sem, egy egyprocesszoros gépen ugye a párhuzamos végrehajtás eleve korlátozott, ráadásul amíg az érintett szálak várakoznak, addig a többiek dolgozhatnak."


    Pont erről beszélek! El kellene már felejteni a táblaszintű zárolásokat... Ez úgy 10-15 éve max. 5-10 gépes Clipper-es hálózatokon még megoldható volt, de egy olyan adatbáziskezelőben, amit a legtöbben PONT WEB-re fejlesztett SQL szervernek tartanak, halott ügy!


    Ami pedig az egyprocesszoros gépeket illeti...
    Az, hogy csak egy processzorod van még nem jelenti azt, hogy korlátozott lenne a párhozamos végrehajtás. Az "atomi szintű" utasítások valóban nem tudnak egyszerre futni, de a gépemen jelenleg is 15-20 thread-ből megy select és insert, update.
    Mutasd a teljes hozzászólást!
  • Az eredeti kérdés ez volt: "ennek te épp a közepébe SELECT-álsz bele, és azt látod hogy van 13 rekord épp." Szerintem erre sikerült válaszolnom, ha ezek a válaszok nem állnak akkor mutasd meg miért.

    táblazárolás: az eredeti javaslatomba ott szerepelt egy szócska, hogy ha *rendszeresen* előfordul, akkor a tranzakciós táblatípust használd. Ebben az eseben nem maga a tranzakció miatt, hanem azért mert az a táblatípus rekordszinten zárol. De nem kell démonizálni a táblazárolást sem, egy egyprocesszoros gépen ugye a párhuzamos végrehajtás eleve korlátozott, ráadásul amíg az érintett szálak várakoznak, addig a többiek dolgozhatnak.

    Ami a példából általánosítást illeti, éppen arra szeretném felhívni a figyelmet, hogy ne általánosítsatok, egy olyan abszolút sorrend, mint ami a második hozzászólásban szerepel nem állja meg a helyét. És ennek bizonyítására egy valós példa is elég...

    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. Le kellene higgadnod.
    Mutasd a teljes hozzászólást!
  • A valós életben nagyon ritkán törekszünk a száz százalékos pontosságra. Pl. érdekel valakit, hogy egy tejüzemben hány tejeszacskó van pontosan? Nem. Annál is inkább, mert még ha pontosan tudná is a masina, mire a kezelőp elolvassa a számot, addigra az már érvénytelen.

    Amiről te beszélsz, az az adatok rendelkezésre állása és/vagy érvényességi ideje, nem pedig a konzisztenciája. Ez két teljesen eltérő dolog, így innentől kezdve az érvelésed is hamis.

    adatbáziskezelőben (konkrétan mysql-ről beszélünk ugye) szinkonizálni nem úgy kell, hogy átírod a forrását, hanem pl. zárolod a táblákat egy atomi műveletként végrehajtott utasításban.

    Ja. Csak az a baj, hogy a táblák folyamatos zárolása konkurrens környezetben annyira belassítja az adatbáziskezelőt, hogy így máris elveszti a MySQL az egyetlen előnyét: a szekvenciális, egyszerű lekérdezések esetén más adatbáziskezelőkhöz képest viszonyla kedvező sebességét. De akkor miért is a MySQLt- használjuk, ha az egyetlen előnyét mi magunk tesszük kihasználhatatlanná??

    Konkrétan: a több mint egy éve mysql-el működő, tíz táblában másfélmillió rekordot tartalmazó szoftverben - bármiféle keverés nélkül - nem kellett túllépni az alkalmazásszerveren belüli szinkronizáción. Tehát se adatbáziskezelőn belüli szinkronizálásra se tranzakciós táblákra *nem volt szükség*.

    És ez most mit jelent? Ez egyetlen konkrét feladat, amiről még azt sem tudjuk, hogy milyen típusú adatokat kezel. Hogyan gondoltad ebből az egyetlen példából messzemenő következtetések levonását úgy általánosságban?

    Egyébként lehet, hogy ha részletekbe belemennénk, kiderülne több hibája is, amiről te esetleg még nem is tudsz. Meg így konkrétumok nélkül mindig könnyű "tényeket" felhozni, mert ellenőrizhetetlenek, így cáfolhatatlanok.
    Mutasd a teljes hozzászólást!
  • "Ha egy csöpp esélye is van, már nem jó megoldás"

    A valós életben nagyon ritkán törekszünk a száz százalékos pontosságra. Pl. érdekel valakit, hogy egy tejüzemben hány tejeszacskó van pontosan? Nem. Annál is inkább, mert még ha pontosan tudná is a masina, mire a kezelőp elolvassa a számot, addigra az már érvénytelen.

    ne törölj - informatikában amúgyis ritkán törlünk adatokat (illetve csak egyszerre nagytömegben), úgyhogy ez tipkikusan magától adódik

    Ezt ugye Te sem gondolod komolyan?

    én meglehetősen konkrétan beszéltem eddig is, lehetne mellőzni az ilyen típusú, bármiféle érvet mellőző kinyilatkoztatásokat?

    szinkronizálás: PHP alkalmazásszervernek? Nem hallottam, hogy PHP-ben bárki megkísérelt volna alkalmazásszervert írni. Java és C++.

    adatbáziskezelőben (konkrétan mysql-ről beszélünk ugye) szinkonizálni nem úgy kell, hogy átírod a forrását, hanem pl. zárolod a táblákat egy atomi műveletként végrehajtott utasításban.

    MINDIG TRANZAKCIÓS TÁBLATÍPUST használj


    nézzük indirekten: vajon MYSQL AB miért hagyta volna defaultnak a nem tranzakciós táblatípust ha a tranzakciós abszolút értelemben jobb?

    Konkrétan: a több mint egy éve mysql-el működő, tíz táblában másfélmillió rekordot tartalmazó szoftverben - bármiféle keverés nélkül - nem kellett túllépni az alkalmazásszerveren belüli szinkronizáción. Tehát se adatbáziskezelőn belüli szinkronizálásra se tranzakciós táblákra *nem volt szükség*.

    Mutasd a teljes hozzászólást!
  • "-(nézd meg, hogy tényleg gond-e az adott helyen egy ritka inkonzisztencia ill. mennyi az esélye, hogy a valóságban is előforduljon.)"

    Ha egy csöpp esélye is van, már nem jó megoldás. Ráadásul annál nehezebb lesz megtalálni a hiba okát, minnél ritkábban fordul elő :)

    -ha lehet, kerüld el a problémát, pl. ne törölj

    Ezt ugye Te sem gondolod komolyan? Elvetve...

    -ha nem megy, akkor szinkronizálj az alkalmazásszerverben vagy az adatbáziskezelőben

    Hogy szinkronizáljon az alkalmazásszerverben? Pl. egy PHP fájlban egy hogy oldod meg? (Lehet, hogy meg lehet, annyira nem ismerem, de picikét furcsának tűnhet). Ami az adatbáziskezelőben való szinkronizálást illeti: felejtsük már el, ezt a "nyílt forrása van, kijavítom" hozzáállást... Ezek nem 20 soros komponensek...


    -ha rendszeren előjön, akkor használj tranzakciós táblatípust."


    Ez megoldás, csak másképp! MINDIG TRANZAKCIÓS TÁBLATÍPUST használj...


    Mutasd a teljes hozzászólást!
  • Ez teljesen korrekt fejtegetés - eltekintve persze a gúnyos visszakérdezéstől a végén, amit ha lehet mellőzzünk.

    De mi a kérdés? Hogyan lehet mysql-el ilyen problémát megoldani?

    biztos te is ki tudsz találni megoldást, de pár ötlet:
    -(nézd meg, hogy tényleg gond-e az adott helyen egy ritka inkonzisztencia ill. mennyi az esélye, hogy a valóságban is előforduljon.)
    -ha lehet, kerüld el a problémát, pl. ne törölj
    -ha nem megy, akkor szinkronizálj az alkalmazásszerverben vagy az adatbáziskezelőben
    -ha rendszeren előjön, akkor használj tranzakciós táblatípust.
    Mutasd a teljes hozzászólást!
  • Pusztán SELECT-ekhez valóban nem kell tranzakció.

    Amennyiben az egész rendszerben egy időben vagy CSAK SELECT-ek vannak, vagy csak közös adatokon nem dolgozó irási műveletek.

    Amennyiben ugyanis ezt a kettőt kevered, akkor már lehetséges hogy INKONZISZTENS adatokat fogsz látni, pl. 20 child rekordot akarsz egyszerre felvenni, vagy pláne törölni, és ennek te épp a közepébe SELECT-álsz bele, és azt látod hogy van 13 rekord épp.

    Te most ezt helyes eredménynek neveznéd?

    Finrod
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Igen, sajnos nekem is ez a thread-safe dolog a legnagyobb bajom.

    Most pont emiatt gondolkodom az MSDE-re való portoláson. Tényleg: tudja valaki így fejből, hogy az MSDE 2000 milyen megszorításokkal működik? (értem ezalatt: esetleges rekordszám korlátozás, egyidejű userek száma, stb...)


    Az InterBase 7-et még nem teszteltem, de az állítólag teljesen SMP-s és thread-safe...
    Mutasd a teljes hozzászólást!
  • Nekem úgy tűnik, developer license.

    "We grant you a nonexclusive, nontransferable limited license to use the programs only for purposes of developing and prototyping your applications, and not for any other purpose. If you use the applications you develop under this license for any internal data processing or for any commercial or production purposes, or you want to use the programs for any purpose other than as permitted under this agreement, you must contact us, or an Oracle reseller, to obtain the appropriate license. We may audit your use of the programs. Program documentation is either shipped with the programs, or documentation may accessed online at http://otn.oracle.com/docs."

    péter
    Mutasd a teljes hozzászólást!
  • Az Oracle oldalán láttam, hogy letölthető az Oracle9i.

    Ez milyen verzió?

    Ha leszedem használhatom?
    Mutasd a teljes hozzászólást!
  • Egyszer én is felraktam az SAP DB-t, néhány héttel azután, hogy publicba ment.

    Tetszett a tudása, de leszedni a gépemről azt nem nagyon lehetett :)

    péter
    Mutasd a teljes hozzászólást!
  • Ja, az IB 6.5/Firebird client tényleg nem thread-safe, ez komoly szivás.

    Nálunk a háromrétegű rendszerben az IB-vel rengeteget szivtunk ezzel. Természetszerűleg a klienskéréseknek megfelelően az alkalmazásszerver egyszerre több szálon is kapcsolódott és dolgozott az IB-vel. Tipikusan BLOB-ok olvasásakor lépett fel a thread safety hiányából fakadó read error, de máskor is megjelent.

    Ráadásul az IB párhuzamossága egyébként is hagy maga után kivánnivalót, egyrészt ugye a multiprocessor support kiesett mivel ott a gyönyörű critical section/mutex/akármilyen exclusive lock a core előtt, másrészt (gondolom emiatt) ha egy "erős" lekérdezés fut, ami mondjuk fél percet vesz igénybe, akkor a többi kliens csak kinlódik, semmi időt nem kap. Szóval minden, csak nem SMP.

    Az MSSQL ezzel szemben akár clusterbe is húzható, teljesen SMP, jobban managelhető, a sebesség nagy adatmennyiségek esetén (néhány millió rekord) összehasonlíthatatlan. Viszont pénzbe kerül -- azok az ügyfeleink, akik komoly adatmennyiségekkel dolgoznak, beállítottak dedikált vasat, a többiek pedig kapják az MSDE-t.

    Az IB egy csomó mindenre jó -- akár nagy adatmennyiségeknél is -- de azért részemről igazán komoly, kritikus rendelkezésre állást és rövid válaszidőt kívánó rendszernél nem alapoznék rá.
    Mutasd a teljes hozzászólást!
  • A MySQL szvsz akkor jó ha pici szerveren kell kisebb feladatokat elvégezni ami nem igényel 100%-os rendelkezésre állást és megbízhatóságot (azaz Pl. pénzügyi tranzakciónál kiesik, de Pl. egy fórum, társkereső, játék, vagy más hasonló dolog elmehet rajta.
    Ps. Az tény hogy a jelenleg elterjedt verzió nem tartalmaz olyan dolgokat hogy tranzakciókezelés vagy tárolt eljárás, de ha belegondolunk hogy még mostanság is akad a piacon olyan dobozos ügyviteli szoftver ami fájl alapú (dbase, paradox, access) alapokon nyugszik szvsz nem kell nagyon földbe döngölni a mysql felhasználókat, bár én azért a postgresql-t, interbase-t, db2-t jobban kedvelem.
    Mutasd a teljes hozzászólást!
  • Annak tartod aminek akarod. Ettől még tény, hogy egy piacra fejlesztett terméknél az egyik legfontosabb prioritás a rugalmasság és a bővíthetőség, alakíthatóság. És az is, hogy ezeket a MySQL a triggerek, tárolt eljárások, összetett lekérdezések és hasonlók hiányával egyáltalán nem biztosítja.
    Mutasd a teljes hozzászólást!
  • miután személyeskedés színtű érvelésnek tartom azt, hogy még nem írtam komoly rendszert és nem a piacból élek inkább kiszállok a vitából.
    Mutasd a teljes hozzászólást!
  • "Sokkal fontosabb, hogy mennyire marad konzisztens az adatbázis a hosszú használat során, mennyire marad könnyen fejleszthető a kód, mennyire könnyen bővíthető új funkciókkal az oldal a teljes adatbázis átszervezése nélkül, stb." Most valami elméleti dologról beszélünk.

    Ha te ezt így gondolod, akkor nyilván nem a megfelelő feladatokon dolgozol. Aki írt már komoly rendszert, és a piacból él, az pontosan tudja, hogy saját magával tol ki amikor nem gondol előre egy rendszer bővíthetőségére, és amikor nem feladatspecifikus mérések alapján dönti el a legmegfelelőbb eszközt, hanem elméleteket állít fel, meg közkeletű tévhitek alapján dönt (pl. "MySQL a leggyorsabb").

    Elméleti kérdés az, amiről te beszéltél: hogy sokszázezer rekordot szépen feldolgoz a memóriában a MySQL.

    Azt kell megérteni, hogy bizony van olyan terület ahol a mysql erőnyerő.

    Senki nem mondta, hogy ez nincs így. Azt viszont állítom, hogy 100 feladatból csak egyetlen egy van, ahol valóban a MySQL az optimális megoldás.

    Az, hogy a webes rendszerek nagy része alatt MySQL működik nem annak köszönhető, hogy valóban ez a legmegfelelőbb eszköz a feladatra, hanem, hogy ez elegendően fapados ahhoz, hogy a webdesignerből web-"programozóvá" avanzsált emberkék gyomrát ne feküdje meg. Aki akár csak egyszer is használt már valódi SQL szervert (akármelyiket), annak eszébe nem jutna soha MySQL-t használni, ha csak valami nagyon szorító körülmény nem kényszeríti rá erre.
    Mutasd a teljes hozzászólást!
  • egymillió rekord rendszeres olvasgatása: igen, kétségtelen, működésképtelen rendszerek sebességét nincs értelme összehasonlítani. Bár szerintem ez mindenkinek triviáis, úgyhogy javaslom, hogy a továbbiakban működőképes rendszereket feltételezzünk...

    Azért ha már 2 gigabájt memóriákkal dobálóztok, felettébb tanulságos lesz megnéznetek mennyiért lehet ekkora szervert bérelni az USA-ban...

    "Sokkal fontosabb, hogy mennyire marad konzisztens az adatbázis a hosszú használat során, mennyire marad könnyen fejleszthető a kód, mennyire könnyen bővíthető új funkciókkal az oldal a teljes adatbázis átszervezése nélkül, stb."

    Most valami elméleti dologról beszélünk. Kábé két éve használom a mysql-t és a fenti problémák *fel sem merültek*. De: nyilvánvalóan van olyan probléma amire meg a mysql nem jó. Mint ahogy erre egy hasonló topikban én magam mondtam példát. Azt kell megérteni, hogy bizony van olyan terület ahol a mysql erőnyerő.
    Mutasd a teljes hozzászólást!
  • Mondjuk a PostgreSQL-ból is csak Cygwines változat van Win32 alá, és az általam eddig látott adatbáziskezelők közül ezt a legnehezebb feltelepíteni (utólag már egyszerűnek tűnik, de hát ugye utólag mindig könnyű okosnak lenni), de ezt leszámítva kiválóan dolgozik.
    Mutasd a teljes hozzászólást!
  • A multkor megnéztem ezt az SAP DB-t.

    Az elején még igéretesnek hangzott a tudása és jó, hogy megy NT-is, mert nekem az kell. Viszont megnéztem, hogy miképp lehet telepíteni Windows alá, és elment tőle a kedvem... A lényeg az, hogy nem Windows ra fejlesztik, hanem Unix-ra, ezért ha Windows-on szeretném használni, akkor két programocsomagot kell telepítenem, mely "szimulálja" a Unix funkcióit...

    Köszönöm, ebből nem kérek... Így szerintem semmilyen épeszű fejlesztő/rendszergazda/informatikus nem telepítené éles rendszerre. A natív Windows-kód állítólag fejlesztés alatt van.

    Mutasd a teljes hozzászólást!
  • Az eredeti témához visszatérve...

    Én nagyon sokat használom a Firebird-et. Nagyon cool, de néhány buktatóra felhívnám mindenki figyelmét:


    - A gds32.dll nem thread-safe :(
    - Nem szereti a duál procit...

    Ez utóbbiak az InterBase 6.5-ig igazak, a 7.0-ás IB most jött ki, az thread-safe és SMP-s... Viszont az unlimited licenc 1 milla :)


    - Nálam egy régebbi verzió néha megdöglött User Definied Function-ok hívásakor. Mostanság nem teszteltem.

    - A Delphi-s DBXpress-ben fogtam néhány hibát, mely eléggé idegesítő. IBX-el minden ok.
    Mutasd a teljes hozzászólást!
  • Ha a konkrét sebességre vetítjük a listát, akkor messze az MSSQL vezet.


    Ami pedig a MySQL-el való sebességösszehasonlítást illeti:

    Nem érdemes olyan redszereket összehasonlítani sebesség szempontjából (sem...) ahol az összehasonlítás egyik résztvevője a másik szolgáltatásainak, megbízhatóságának kb. 1/10-ét nyújtja.

    Továbbá kiváncsi lennék egy olyan "éles" tesztre is ami nem olyan "hozzáértők" csináltak, akik életükben még csak MySQL láttak. Egy ilyen tesznek kb úgy kellene kinéznie, hogy:

    - adott egy adatbázis
    - benne 150 tábla
    - benne 300 view
    - benne 200 tárolt eljárás
    - egyszerre 1000 felhasználó
    - némelyik tábla csak átlagos 1-200 -as rekordszámot tartalmaz, viszont életszerűen lenne néhány olyan tábla melyben 10 millió feletti a rekordszám
    - olyan lekérdezéseket produkálni, melyek életszerű lekérdezések, nem pedig 1 millió tétel végigolvasása ID sorrendjében
    - Mindez egy 4-8 processzoros szerveren 8 GB rammal.


    Nos biztos, hogy ilyen körülmények között, is a MySQL lenne az Oracle, DB2 és az MSSQL elött sebességben? Nem hinném...
    Mutasd a teljes hozzászólást!
  • Amit említettél összehasonlítást a MySQL oldalán (http://www.mysql.com/information/crash-me.php) azt gyorsan tessék elfelejteni!

    Én már egyszer átböngésztem, és gyakorlatilag a fele sem igaz. A MySQL-es fiúk csináltak tulajdonképpen egy összehasonlítási listát, ahol hol a konkurencia termékének szolgáltatásának meglétét "felejtették el kipipálni", hol pedig a MySQL hiányos oldalait bemutató tulajdonságokat nem tették bele a listába, miközben azt minden normális SQL szerver 10-15 éve tudja!

    Mutasd a teljes hozzászólást!
  • Vagy igen, vagy nem, de nem tudom ez hogy kapcsolódik ide...

    Úgy, hogy tök lényegtelen, hogy egy nem életszerű vagy rosszul megszervezett rendszeren az alternatívák közül melyik a leggyorsabb (v. a legkevésbé lassú), hanem azt kell nézni, hogy életszerű körülmények között, jól megszervezett rendszeren melyik nyújt optimálist megoldást.

    A konkrét esetben ugye arról van szó, hogy egy üzleti alapokon működő oldal esetében lényegtelen, hogy mondjuk a konkurrensekének egy ötöde csak a mysql memory footprintje (ami nem igaz, de tételezzük fel), mert akkor egyszerűen 5x annyi memóriát kell rakni a szerverbe és kész. Sokkal fontosabb, hogy mennyire marad konzisztens az adatbázis a hosszú használat során, mennyire marad könnyen fejleszthető a kód, mennyire könnyen bővíthető új funkciókkal az oldal a teljes adatbázis átszervezése nélkül, stb. Mert ugye +2GB memória ára az egy fejlesztőnek kb. 1-2 heti költségét teszi ki, és így sokkal inkább megéri a plusz memóriát belevágni, mint éveken keresztül nyögni az adatbáziskezelő fapadosságát.
    Mutasd a teljes hozzászólást!
  • Egy kezemen meg tudnám számolni azokat a magyar oldalakat, amelyiken több ezer felhasználó böngész egyszerre


    igen, és kábé ugyanennyi oldal van amelyik profitot hoz


    a mysql mysql táblatípusa (mert ügye van neki tranzakciós táblatípusa is) szintén az atomi műveletekkel (á la implicit tranzakció) operál. Éppen azért mert ezt gyorsra lehet csinálni.
    Mutasd a teljes hozzászólást!
  • Egy nyilvános, profitorientált webes alkalmazás több ezer egyidejű felhasználót jelent.

    Egy kezemen meg tudnám számolni azokat a magyar oldalakat, amelyiken több ezer felhasználó böngész egyszerre. És ez alatt nem valódi konkurrenciát értek, hanem mondjuk fél órás inaktivitási limittel számolva a felhasználókat.

    Ez a felhasználószám pedig maga után vonja hogy itt nem lesznek olyan tranzakciók, amelyek öt táblát írnak és még tízből olvasnak stb.

    Két, maximum három táblánál többre kiterjedő tranzakciókat nehezen tudok elképzelni. Ez egyébként lényegtelen is, mert a tranzakciók lassú
    ságát nem a módosított táblák, hanem a módosított rekordok száma, illetve ezzel összefüggésben a record versioning overhead okozza.

    Egyébként vannak olyan adatbáziskezelők is (pl. IB), ahol tranzakción kívül nem is tudsz műveletet végezni, tehát gyakorlatilag minden tranzakciókban történik. De más adatbáziskezelőknél is gyakorlatilag az atominak tekinthető tranzakción kívüli művelet (pl. egyetlen INSERT, v. UPDAT) is valójában ugyanolyan módon kerül végrehajtásra mintha tranzakcióban lenne. Csak éppen az alkalmazásnak nem kell az IB mintájára "kézzel" gondoskodnia ezek az automatikus tranzakciók megnyitásáról és lezárásáról.
    Mutasd a teljes hozzászólást!
  • Nagyon rosszul van megszervezve az az adatbázis, amelyben másfél millió rekordot kell az adatbáziskezelőnek bármilyen lekérdezéshez beolvasnia.


    Vagy igen, vagy nem, de nem tudom ez hogy kapcsolódik ide...
    Mutasd a teljes hozzászólást!
  • Van egyébként egy speciális előnye a mysql-nek amit adott esetben nem lehet eléggé értékelni: másfél millió rekordot szépen elkezelget 10 megabájt lefoglalt memóriában.

    Nagyon rosszul van megszervezve az az adatbázis, amelyben másfél millió rekordot kell az adatbáziskezelőnek bármilyen lekérdezéshez beolvasnia.
    Mutasd a teljes hozzászólást!
  • Szvsz nincs semmi kulonbseg a webes es desktop alkalmazasokban ilyen teren. Barmelyikben lehet nagy es kis programot irni, adatbazissal a hatterben.


    Egy nyilvános, profitorientált webes alkalmazás több ezer egyidejű felhasználót jelent. Ez desktop alkalmazásoknál ugye nem jellemző. Ez a különbség.

    Ez a felhasználószám pedig maga után vonja hogy itt nem lesznek olyan tranzakciók, amelyek öt táblát írnak és még tízből olvasnak stb.
    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