Új hozzászólás Aktív témák

• #950 modder aktív tag Lacces #945

  Új Válasz 2012-10-18 01:05:30 #950

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  modder

  aktív tag

  válasz Lacces #945 üzenetére

  Nem tudom neked mit tanítottak RDBMS-ekkel kapcsolatban egyetemen, de ha érdekel a téma, akkor tényleg érdemesebb lenne előbb jobban utána járni.

  Ez a "jobban kedvelik szétbontani több szelektre egy join-t" hát ez rohadt sokmindentől függ. pl attól, hogy abban a rendszerben, amit átvettél fingjuk nem volt mi fán terem az sql, ezért a legegyszerűbb módszerhez folyamodtak, amit még ismertek. Egy megfelelően indexelt, nagy adathalmaznál (értsd: több millió sor) particionált táblákból álló relációs adatbázisban 3 tábla joinja gyorsabb lesz, mint 3 szelekttel lekérdezni. Nem illik okosabbnak lenni az adatbázisnál.

  "NoSQL majdnem minden esetben gyorsabb az relációs adatbázisnál" -- ez is hatalmas tévhit. Még elosztott rendszerben is. nézd meg pl az alábbi cikket
  Twitter, PayPal reveal database performance

  NoSQL-re szeritem áttérni két szélsőséges esetben érdemes:
  -- elosztott az alkalmazásod, több szerveren fut, és sokkal több írás történik az adatbázisba, mint lekérdezés (facebook eset)
  -- több szerveren fut az alkalmazásod, és ki akarod használni az elosztott "NoSQL" (bár nem ugyanazt jelenti) által alapból nyújtott terheléselosztást anélkül, hogy bajlódni szeretnél egy MySQL clusterezéssel.

  Az, hogy mitől lehet lassú egy relációs adatbázis sokmindentől függ: rosszul megtervezett indexek, rosszul megtervezett lekérdezések, rossz particionálás, table lock használata írásnál sok írás mellett (érdemes inkább optimistic locking-ot használni)

  Az autoincrement pedig azért is ugorhat, mert tranzakció végén rollback volt, új adat nem került beszúrásra véglegesen, de az auto increment érték nőtt.

Új hozzászólás Aktív témák