Hirdetés
Új hozzászólás Aktív témák
-
Soak
veterán
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.
-
#1008
Sk8erPeter
nagyúr
Lacces
#1007
Sk8erPeter
nagyúr
Jó kulcsszavakat beírva elég gyorsan lehet találni válaszokat, például:
Nem tudom, milyen, nem próbáltam még.
A másikra majd a többiek.
-
modder
aktív tag
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 performanceNoSQL-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
Sk8erPeter
nagyúr
"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. -
PazsitZ
addikt
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.
-
#944
Speeedfire
félisten
Lacces
#943
Speeedfire
félisten
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
- Gitáros topic
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Samsung Galaxy Watch6 Classic - tekerd!
- alza vélemények - tapasztalatok
- Google Pixel topik
- OLED TV topic
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- „Új mérce az Android világában” – Kezünkben a Vivo X300 és X300 Pro
- The Elder Scrolls V: Skyrim
- Projektor topic
- További aktív témák...
- MSI CreatorPro Z16P RTX A5500 TOUCH! (vapor chamberrel)
- Jura Impressa C5 Automata kávégép 6 hónap Garancia Beszámítás Házhozszállítás
- Telefon felvásárlás!! Xiaomi Redmi 9, Xiaomi Redmi 9AT, Xiaomi Redmi 10, Xiaomi Redmi 10 2022
- 24 GB-os RTX 3090 OEM
- Lenovo X13 Yoga 2in1 Thinkpad WUXGA Touch i5-1145G7 vPro 16GB 256GB 4G LTE GPS Win11 Pro Garancia
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: Laptopműhely Bt.
Város: Budapest