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

• #1014 Soak veterán Lacces #1013

  Új Válasz 2012-11-30 21:49:30 #1014

  Ú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

  

  Soak

  veterán

  válasz Lacces #1013 üzenetére

  Most a terhelhetőség nő lineárisan vagy a terhelés? El lehet szurni, mindent el lehet. Nyilván pár száz oldal letöltésnél per nap nem fog senkinek feltünni hogy egy szar az adatbázisod mert megoldja erőből a géped.

  Amit tudsz optimalizálni, hogy 1. Az oszlopokat a bennük tárolt adatra alakitod a lehető legjobban 2. Olyan query-ket írsz amik lehetőség szerint indexek mentén tudnak haladni.

  De ha nagy terhelésű rendszert tervezel és fontos a rendelkezésre állás akkor érdemes átnézni a nem relációs adatbázisokból egy-kettőt . Bizonyos feladatokra nagyon jók, de elég sok még gyerekcipőben jár . Vannak hatalmas előnyeik a relációs adatbázisokkal szemben (meg hatalmas hátrányaik is nyilván) . De pl egy cassandrával elég jól tudsz egy clusteren belül terhelés elosztani és az adatbiztonságod is lehet jó egyszerre.

• #1012 Soak veterán Lacces #1007

  Új Válasz 2012-11-30 16:52:48 #1012

  Ú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

  

  Soak

  veterán

  válasz Lacces #1007 üzenetére

  Mire gondolsz skálázhatóság alatt?

• #1010 martonx veterán Lacces #1005

  Új Válasz 2012-11-30 14:05:52 #1010

  Ú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

  

  martonx

  veterán

  válasz Lacces #1005 üzenetére

  Ha már GUI kell, nem teljesen mindegy, hogy milyen nyelven íródott a GUI?

• #1008 Sk8erPeter nagyúr Lacces #1007

  Új Válasz 2012-11-30 13:30:57 #1008

  Ú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

  

  Sk8erPeter

  nagyúr

  válasz Lacces #1007 üzenetére

  Jó kulcsszavakat beírva elég gyorsan lehet találni válaszokat, például:

  JSPMyAdmin

  Nem tudom, milyen, nem próbáltam még.

  A másikra majd a többiek.

• #1006 Sk8erPeter nagyúr Lacces #1005

  Új Válasz 2012-11-30 13:03:56 #1006

  Ú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

  

  Sk8erPeter

  nagyúr

  válasz Lacces #1005 üzenetére

  Mi az, hogy Java-alapú szerverhez? Az kit érdekel, milyen webszerver fut rajta? Az a lényeg, hogy UNIX/Linux-alapú, vagy Windows. Ettől függ, milyen program ajánlható.

• #956 martonx veterán Lacces #953

  Új Válasz 2012-10-18 16:31:22 #956

  Ú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

  

  martonx

  veterán

  válasz Lacces #953 üzenetére

  Sürgősen kezdj el rendes munkahelyet keresni, ahol szakértő programozók dolgoznak, nem pedig kontárok.

• #954 Sk8erPeter nagyúr Lacces #953

  Új Válasz 2012-10-18 15:39:05 #954

  Ú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

  

  Sk8erPeter

  nagyúr

  válasz Lacces #953 üzenetére

  "Csak számomra mindig olyan érdekes, hogy rám szólnak, hogy bontsam szét selectre, és ne Joinoljak"
  Ki szól rád? A munkahelyeden ilyen okos emberek dolgoznak?

• #951 Peter Kiss őstag Lacces #943

  Új Válasz 2012-10-18 08:31:28 #951

  Ú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

  

  Peter Kiss

  őstag

  válasz Lacces #943 üzenetére

  1. Tranzakció rollback volt.
  2. Aki inkább több SELECT-et használ, az hülye.

• #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.

• #949 Sk8erPeter nagyúr Lacces #943

  Új Válasz 2012-10-18 00:41:23 #949

  Ú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

  

  Sk8erPeter

  nagyúr

  válasz Lacces #943 üzenetére

  "2. Úgy vettem észre webes gyakorlatban, hogy a JOIN-lást nem nagyon szeretik. Számomra egyetem után meglepő volt, hogy inkább használjunk 3 SELECT-et, amit a szerver oldalon úgy mond összeállítunk és kérdezgetünk le WHERE ID = .... konstrukcióval, ez jobbnak tűnik, mint ha 3 táblát össze JOIN-olnék."
  Ki mondta ezt a baromságot? Egyébként nyilván esetfüggő, milyen query-t érdemes használni, nincs erre általános recept.
  De az egyszerűen hatalmas hülyeség ebben a formában, hogy jobb 3 különböző select, mint mondjuk egy értelmesen összerakott join.

  (#947):
  "Lehet már tényleg kellene írnom e kettő adatbázis rendszerről, és megírni a személyes véleményt."
  Most mindenféle bántás nélkül, a hozzászólásaidból, kérdéseidből az derül ki, hogy nem igazán vagy még kellően tájékozott ahhoz, hogy cikket írj a témáról, hogy átfogó összehasonlítást tudj ezekről írni. Ehhez komoly háttértudás, tapasztalat kell, és kellő magabiztosság, különben nagyon nagy eséllyel csak téves vagy ingatag információkat fogsz megosztani a publikummal, vagy az állításaid nagy része pusztán spekuláció, saját vélemények, érzésekre hagyatkozás megfogalmazása lenne, aminek meg nem túl sok értelme van szakmailag.
  Én személy szerint nem venném a bátorságot ilyen összehasonlító cikk megírására (mostani tudásom egyszerűen nem elég hozzá), főleg, ha olykor láthatóan alapfogalmakkal nem lennék tisztában.

• #948 PazsitZ addikt Lacces #943

  Új Válasz 2012-10-17 22:30:36 #948

  Ú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

  

  PazsitZ

  addikt

  válasz Lacces #943 üzenetére

  1.
  Azt tudom elképzelni, hogy id-val lett beszúrva a 16588-as id-jű sor. Így az increment érték onnan folytatódik.
  Magától nem ugrál

  2.
  Rendes indexelés tábla reláció mellett, 3 tábla összekapcsolása nem szabad, hogy gondot jelentsen.

  De alap esetben nézzük mit csinálhatsz.
  Legyen product, category, region táblák.

  Lekéred az aktív product-okat.
  Kapsz mondjuk 5000 rekordot. Ekkor a kategória lekérdezés WHERE IN -be sűríteni 250 id-t, a régió lekérdezésbe 2000 id-t elég fura megoldás.
  Teljes kategória és régió táblalekérdezése és szerverkód általi összepárosítása megint csak fura megoldás.

  Kis adathalmaznál persze logikusabbnak tűnhet a WHERE IN. Viszont ilyenkor egy indexelt tábla JOIN is gyorsabb.

  Speciálisabb esetekben elképzelhető, hogy optimalizálhatóak szétbontva egyes lekérdezések, de ez nem általános szvsz.

• #946 Speeedfire félisten Lacces #945

  Új Válasz 2012-10-17 22:15:20 #946

  Ú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

  

  Speeedfire

  félisten

  válasz Lacces #945 üzenetére

  Ha jól tudom nem minden esetben gyorsabb a nosql. pl ahogy hallom az fb szerű falaknál van igazán nagy haszna.

  Gondolom ez lenne az sql-es netbeans. Nem ismerem, meg vagyok elégedve a mysql workbench-el.

• #944 Speeedfire félisten Lacces #943

  Új Válasz 2012-10-17 22:02:37 #944

  Ú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

  

  Speeedfire

  félisten

  válasz Lacces #943 üzenetére

  1. Ott valami anomália lehet. Legjobb tudomásom szerint ilyen nincs. Ha rakunk bele értéket, csak akkor nő ez az érték.

  2. Hát, pedig a legtöbben a join mellett vannak. 1 nagy lekérdezés, mint több kisebb. Én is inkább erre álltam rá. Kevesebb a generált adat a szerverről.
  Szerintem minden esetben célszerű a join.

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