- LG LCD és LED TV-k
- OLED TV topic
- Kormányok / autós szimulátorok topicja
- Azonnali informatikai kérdések órája
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- TCL LCD és LED TV-k
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Ventilátorok - Ház, CPU (borda, radiátor), VGA
- AMD Ryzen 9 / 7 / 5 / 3 3***(X) "Zen 2" (AM4)
Hirdetés
-
Baladins - Megjelenési dátumot kapott a PC-s kiadás
gp A jövő hónapban esedékes premiert az év folyamán a konzolos verziók követik majd.
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
Játékosbarát frissítést kapott az ASUS ROG Ally
ph A vállalat engedélyezte az AMD Fluid Motion Frames eljárását.
Új hozzászólás Aktív témák
-
hogy lehet megfelelni a növekvő kihívásoknak? el kell felejteni az sql-t.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
#4
burgatshow
veterán
bambano
#3
-
#5
bambano
titán
burgatshow
#4
válasz
burgatshow
#4
üzenetére
azt a téves egyenlőséget vessük el, hogy az adatbáziskezelő azonosan egyenlő a relációs-adatbázis kezelővel.
ez a múltban sem volt így, pl. a 4-es vms-en is volt rekordmenedzser (ami kb. a dbf szintjét hozta), meg volt rajta hálós és relációs adatbáziskezelő is, mindezt a 80-as évek végén.
az sql eredetileg is az ad-hoc lekérdezések hatékony eszköze volt, nem a teljesítményé. eredetileg sem csúcsteljesítményű adatbázisok alá szánták soha, arra 20-30 éve is voltak jobb eszközök. Mint ahogy ma is vannak, ezen eszközök összefoglaló neve a nosql.
de-de, pont ezt akarom neked előadni, hogy nem rdb-ben tárolják a több milliárd rekordot.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
cucka
addikt
Szerintem ennyire nem fekete-fehér a helyzet, nem lehet kijelenteni egyértelműen, hogy egyik vagy másik megközelítés jobb.
Természetesen a noSQL-nek vannak előnyös oldalai, de nem ez az a varázslatos technológia, ami egy csapásra megoldja az adattárolásnál felmerülő összes problémát. -
cucka
addikt
Tévesen értelmezted a cikket. Itt nem olyan emberekről van szó, akik SQL lekérdezésíró guruk, hanem DBA-król.
(#10) hohoo Nyilván van egy támogató a rendezvény mögött, ennek ellenére magas a ló, amiről leszólod ezeknek az embereknek a szaktudását.
(Más emberek tudásának leszólásával amúgy semmi baj nincs amennyiben tudsz is mutatni valamit, ami alátámasztja a fröcsögést)(#7) bambano
Valóban nem írtad
. A teljesítményről meg annyit, hogy a klasszikus relációs adatbázisok nem azért gyengébbek teljesítményben, mert annak idején a könnyű lekérdezésekre fókuszáltak (egyáltalán, válasszuk már külön az sql nyelvet és az adatbázis kiszolgálót), hanem mert az rdbms-ek olyan funkciókat kell biztosítsanak (és olyan szabályoknak megfeleljenek), amelyeknek k*rva nagy az overhead-je.
Nyilvánvaló, hogy ha csökkented a tudást, akkor gyorsul a rendszer és ehhez nem kell noSQL, lásd pl. VoltDB.[ Szerkesztve ]
-
ddekany
veterán
Furcsa, hogy szakmai berkekben SQL erről-arról beszélnek... SQL guru, vagy akár noSQL. Miért kell így összemosni a relációs adatbázis kezelést és az SQL-t? (Maga az SQL nyelv meg, szintaktikáját tekintve, finoman szólva gyenge tervezés. Csak hát a történelmileg ez csontosodott be.)
-
-
cucka
addikt
Szerintem globálisan nem lehet kijelenteni, hogy valami hatékony/nem hatékony, mert a hatékonyság a rendszer által megvalósított funkcionalitás függvénye.
A klasszikus rdbms-eket elsősorban az ACID nevű tervezési elv fogja vissza, ennek köszönhető az a brutális overhead, amitől ezek a rendszerek más noSQL rendszerekhez képest lassabbak/nem skálázódnak elég magasra.Itt egy kicsit régi, de egész érdekes cikk erről: [link]
Egyébként a korábban említett VoltDB a cáfolat, merthogy ebben a nagy truváj, hogy ACID compliant és mégis gyors, ezt viszont bizonyos funkciók levágásával tudták elérni. Egy triviális példa erre, hogy nincs logolás. (Amitől nyilván gyorsabb lesz a rendszer, viszont te bevállalnád a logolás hiányát egy sokszázmillós rendszernél?)
További okosságok erről: [link][ Szerkesztve ]
-
-
Persze, hogy nem lehet globálisan kijelenteni, hogy valami hatékony, ezért nem hatékony az sql
egy-egy lekérdezésre lehet mondani, hogy az adott adatszerkezet ahhoz a lekérdezéshez optimális.a hálós adatbáziskezelőkben pont ez a trükk, hogy egy bizonyos lekérdezésre vagy lekérdezés-típusra bitang gyors, a többire meg erősen vakaródzik. szemben az sql-lel, ami egyenletesen nem optimális.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
#18
attila9988
őstag
bambano
#17
attila9988
őstag
Tehát akkor szerinted a relációs adatbázis kezelés semmilyen körülmények között nem lehet optimális?
Csak azért kérdezem mert pl a postgre, vagy a mysql, vagy a hasonló jellegű kereskedelmi adatbázis motorok sikere, és fejlődési pályája azt mutatja hogy kell lennie ilyennek is.
Persze nyilván más elvárásoknak kell megfelelni egy google találati lista esetében, ahol a sebesség sokkal fontosabb annál, mint hogy pl kiesett szerverek miatt nem a legfrissebb, hanem a 15 perccel korábbi rank alapján kapom meg a találatot, és mondjuk egy hellyel hátrább lesz a megfelelő oldal, és mások az elvárások egy netbank -nál, ahol az adatintegritásnál nincs fontosabb szempont, mert minden ezredmásodpercben a megfelelő pénzösszegnek kell szerepelnie a lekérdezésben.Pl mit javasolnál pl egy kereskedelmi üzletlánc raktárkészletének rendben tartásához?
„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)
-
ddekany
veterán
A kérdés úgy értendő, hogy amit egy új projectben használnál ilyen célra. Tranzakciók megléte nyilván szükséges, ezzel a noSQL megoldások egy része (mint mongoDB) kapásból kiesett. Többi ACID-os dologgal nem tudom pontosan hogy áll a maradék, és amelyik jól, az hogy áll sebességben. (Meg én személy szerint azt sem értékelném, ha az entitások nem "statikusan típusosak" lennének.)
-
#20
ddekany
veterán
attila9988
#18
ddekany
veterán
válasz
attila9988
#18
üzenetére
"Csak azért kérdezem mert pl a postgre, vagy a mysql, vagy a hasonló jellegű kereskedelmi adatbázis motorok sikere, és fejlődési pályája azt mutatja hogy kell lennie ilyennek is."
A sikeresség önmagában csak annyit bizonyít, hogy egy adott megoldás nem volt nagyon használhatatlan... szóval ezt hagyjuk ki az érvelésekből.
-
#21
bambano
titán
attila9988
#18
válasz
attila9988
#18
üzenetére
Mi az, hogy optimális?
Milyen keretek és paraméterek között méred, hogy optimális-e vagy sem?Ha veszel egy rdbms-t meg egy hálósat, akkor azt fogod látni, hogy az rdbms teljesítménye a hálóshoz képest kisebb mértékben szór. A hálósnál lesz olyan lekérdezés, amiben leveri a porba az rdbms-t, meg lesz olyan, amiben rosszabb, meg merem kockáztatni: sokkal.
Ez egy paraméter abból a listából, ami alapján választani kell. Ha azt kérdezed, mit javaslok ide vagy oda, akkor azonnal és gondolkodás nélkül első helyen bekerül egy paraméter: az ár. Ezen a ponton az oracle gyakran elvérzik. Amióta a mysql oracle tulajdon lett, azóta arról se sokat lehet tudni, hogy olcsó lesz vagy sem, stb. stb. mysql-t eddig se szerettem a butaságai miatt, de azóta ez tovább csökkent. Hogy a mostanában előbukkanó mysql forkot/forkokat lehet-e ajánlani, azt nem tudom, ahhoz meg kellene nézni legalább a stabilitását.
Én eddig mindenhol postgresql-t használtam, nekem bevált.
meg kell még jegyezni, hogy butaság lenne két paraméter alapján választani, még nagyobb butaság lenne kijelenteni, hogy ez számít csak. kilométeres listát lehetne írni arról, hogy mi alapján döntsd el, hogy melyiket választod.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
#22
attila9988
őstag
ddekany
#20
attila9988
őstag
A sikeresség önmagában csak annyit bizonyít, hogy egy adott megoldás nem volt nagyon használhatatlan... szóval ezt hagyjuk ki az érvelésekből.
Ez csak akkor igaz, ha termékekről beszélünk. Itt viszont egy szemléletmódról van szó, amelyet sok adatbázis motor követ már hosszú ideje.
„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)
-
#23
attila9988
őstag
bambano
#21
attila9988
őstag
A postgres -t ajánlom én is mindenkinek a "mit próbáljak ki elsőre" kérdésre, és ezek szerint te is alkalmazol ilyen jellegű adatbázis kezelő rendszereket.
Nyilván mindig a cél határozza meg az eszközt. Én úgy gondolom, hogy ha sokféle lekérdezésre lehet szükség, akkor a relációs adatbázis kezelő a nyerő, ha viszont a lekérdezések 90+% -a egy bizonyos szempont szerint történik, akkor jöhet szóba a hálós, vagy más egyéb megközelítés. Fontos az is, hogy az adatintegritás mennyire lényeges szempont (raktárkészletnél pl nagyon) illetve hogy elosztott rendszerben gondolkodunk -e, vagy sem.Csupán arra akarok kilyukadni, hogy a hagyományos relációs adatbázis kezelés nem feltétlenül elvetendő dolog, attól függetlenül hogy nem minden körülmények között megfelelő.
Te pedig korábban azt írtad, - vagyis úgy tűnt - hogy abszolút nem érdemes foglalkozni vele.
De valószínűleg én értettem félre valamit, mert ha elavultnak tartanád ezt a fajta megközelítést, nem használnál postgresql -t sem.
„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)
-
cucka
addikt
A hozzászólásaid alapján egyértelmű, hogy rendszergazdai szemszögből írsz
.A hálósnál lesz olyan lekérdezés, amiben leveri a porba az rdbms-t, meg lesz olyan, amiben rosszabb, meg merem kockáztatni: sokkal.
Az alapvető különbség nem itt van.
Egy rdbms X funkcióhalmazt valósít meg, egy nosql adatbázis meg Y-t, ahol jellemzően Y részhalmaza X-nek.
Ha a rendszered építése során neked olyan szolgáltatásokra van szükséged, amelyek X-nek részei, de Y-nak nem, akkor az összehasonlításod értelmét veszti. Azt, hogy valami optimális-e, szintén ebből a szempontból kell nézni, egy-egy lekérdezés sebessége túl sokat nem számít, amikor eltérő elvek szerint felépített rendszereket hasonlítasz össze, amelyeknek az egyetlen közös tulajdonsága, hogy valamilyen adatokat tárolnak valamilyen módon.Ha azt kérdezed, mit javaslok ide vagy oda, akkor azonnal és gondolkodás nélkül első helyen bekerül egy paraméter: az ár.
Ez sem egy egzakt valami. Mondjuk a mérések szerint nagy adatbázisoknál az Oracle a MySQL sebességének 2.5szeresét hozza, innen ember legyen a talpán, aki megbecsüli, hogy melyik olcsóbb. És ez csak a sebesség, további változók a skálázhatóság, mennyire lesz könnyű/nehéz supportolni, mennyire könnyű/nehéz rá fejleszteni, stb. Igazából fogalmam sincs, hogy az ezzel foglalkozó emberek hogyan tudnak egyáltalán egzakt módon választani ilyen sok paraméter függvényében.Hogy a mostanában előbukkanó mysql forkot/forkokat lehet-e ajánlani, azt nem tudom, ahhoz meg kellene nézni legalább a stabilitását.
Facebook-nél állítólag nagyon sok rendszerük alatt sharded mysql fut, tehát a mysql sincs elveszve.Én eddig mindenhol postgresql-t használtam, nekem bevált.
A postgre teljesen jó rendszer, de pont nem a sebességéről híres.[ Szerkesztve ]
-
Az miért rendszergazda szemszög, hogy fontos a sebesség?
"Egy rdbms X funkcióhalmazt valósít meg, egy nosql adatbázis meg Y-t, ahol jellemzően Y részhalmaza X-nek.": ami, szerintem, nem annyira fontos. A helyesebb nézőpont az, hogy egy sql-ben x módon kell elérni egy eredményhalmazt, hálósban meg y és x meg y között semmi összefüggés sincs.
Bankos példánál maradva: sql-ben egy ügyfél számláján a mozgásokat, a history-t kb. úgy szeded elő, hogy egy táblából szelektálsz azon sorokra, ahol a tranzakcióhoz tartozó számlaazonosító az, amit keresel. Kapsz egy eredményhalmazt, amin egyesével végiglépkedve kapod meg a program adatterületein belül az eredményt.
Hálósban meg megkeresed az ügyfél számláját, ahhoz oda vannak láncolva a mozgás rekordok, csak a láncon kell végigmenni, mintha memóriában egy kétszeresen láncolt listát buherálnál. Ciklus, következőre mutató mutató, stb. Csakhogy itt oda vannak láncolva a rekordok a számla rekordoz, tehát nem kell szelektelni, nem kell végigolvasni az egész táblát és/vagy index táblát.
Következmény: ha már megtaláltad az ügyfél rekordját, a számlatörténet előállítása ebben a hálós adatszerkezetben nagyon sokkal gyorsabb. Viszont egy nem elsődleges kulcs szerinti keresésbe meg beleszakadsz. Leprogramozni is ótvaros, lefuttatni is.
"Ha a rendszered építése során neked olyan szolgáltatásokra van szükséged, amelyek X-nek részei, de Y-nak nem, akkor az összehasonlításod értelmét veszti.": minden nyelven lehet fortranban programozni. másik mondás a szomszédból: amit nem lehet assemblyben leprogramozni, azt nem is érdemes.
Az összehasonlítás nem veszíti értelmét attól, hogy valamit nem tud az adatbáziskezelő, csak költség/idő ráfordítás oldalon kapsz pofont, hogy le kell programoznod. A szokásos végeredmény pedig az, hogy egy másik ponton meg akkorát javul a rendszer, hogy kutyaszorítóba kerülsz, melyik ujjadat harapd le.
A vételár eléggé egzakt valami szokott lenni. Ha van mondjuk egy projekted, ahol 20 fabatkát költhetsz sw-re, 20-at hardverre és akkor bejön a kilométeres nagypofájú oracle sales manager és meg akar győzni, hogy 140 fabatkáért vegyél egy alap oracle-t, akkor ilyen paraméterek mellett tetszőleges oracle jó tulajdonság sem ér semmit.
Az, hogy valami a mysqlnél 2.5x gyorsabb, elég gyenge érv
Az emberek egy része egyszerűen szokott választani: valahogy ráesik az egyikre, azt megszokja, és attól kezdve, hogy kalapácsa lett, mindent szögnek lát.
Lehet, hogy a postgresql nem a sebességéről híres, azért én csak kicsiholtam belőle kb. 60x-os sebességet az akkori mysql-ekhez képest. Nem muszáj, hogy erről legyen híres, nem is számít
pedig a mysql-ben még raidelt táblákat is használtam.A mysql nálam akkor vágta el magát, amikor a szabad licenszű mysql-ben nem volt tranzakció kezelés, így adatbáziskezelőnek se nagyon lehetne nevezni. Az a tény, hogy időközben lett benne, engem már nem szoktatott le a postgresről.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
cucka
addikt
Az miért rendszergazda szemszög, hogy fontos a sebesség?
Az a rendszergazda szemszög, hogy kihagyod a gondolatmenetedből a szoftvert, ami az adatbázist használja.A helyesebb nézőpont az, hogy egy sql-ben x módon kell elérni egy eredményhalmazt, hálósban meg y és x meg y között semmi összefüggés sincs.
Elméletben talán igen, gyakorlatban egyértelműen nem. Az, hogy milyen típusú adatbázist érdemes használni, azt a szoftver dönti el, a szoftver igényei szerint kell adatbázist választani, ami tudja a megfelelő funkciókat. Egy noSQL és egy rdbms jellemzően nem felcserélhető elsősorban a noSQL szűkebb szolgáltatáskínálata miatt.
(Persze, felcserélhető, ha noSQL-t használsz és a szoftver rétegben megírod alá az rdbms funkcionalitást, de ilyen csak elméletben létezik)
Egyébként ez a "hálós adatbázis" kifejezést honnan vetted? Csak mert tudom, hogy miről beszélsz, de ez egy nagyon rossz szó ráBankos példánál maradva
Bankos példánál maradva érdekes kérdés, hogy különféle tranzakciók során garantált-e az adatbázis integritása, vagy hogy mi történik, ha nem csak 1 reláció mentén gondolkozunk (ügyfél-mozgások), vagy hogy egy több ügyfelet érintő tranzakció/lekérdezés során mi történik, továbbá hogy mindez hogy van, ha elosztott az adatbázisod. Túlságosan leegyszerűsíted a problémákat, amelyek felmerülhetnek.Az összehasonlítás nem veszíti értelmét attól, hogy valamit nem tud az adatbáziskezelő, csak költség/idő ráfordítás oldalon kapsz pofont, hogy le kell programoznod.
Akkor meg oda lyukadunk ki, hogy gyakorlati szempontból nézve mégsem hasonlíthatod össze. Kevés nagyobb ökörség van, mint noSQL-t használni, majd szoftveresen alátenni azokat a funkciókat, amiket egy rdbms tud.A szokásos végeredmény pedig az, hogy egy másik ponton meg akkorát javul a rendszer, hogy kutyaszorítóba kerülsz, melyik ujjadat harapd le.
Kicsit tág a kérdés, de általában szerintem el lehet jutni olyan kompromisszumra, hogy ne harapj le semmit.A vételár eléggé egzakt valami szokott lenni. Ha van mondjuk egy projekted, ahol 20 fabatkát költhetsz sw-re, 20-at hardverre..
Persze, csak mellette programozóra is költeni kell meg supportra is. A drága szoftver nem feltétlenül kerül többe, mint az olcsó, ha a járulékos költségeket is nézed.A mysql nálam akkor vágta el magát..
A mysql régen szar volt, most már nagyjából jó lett. Kb. röviden
-
Az a baj az összes hszeddel, hogy feltételezed: egy adatbázis hozzáférési interfésze kizárólag relációs lehet. Ha ezt el tudnád vetni, rájönnél, hogy az rdbms nem kizárólagos út, gyakran nem is az optimális út. A relációs adatmodell mellett még legalább kettőt tanítanak rendes egyetemen, a hálóst és a hierarchikust. Ha rendes egyetemre jártál, ahol rendes oprendszereket is tanítanak, nem csak hulladékot, akkor hálós adatbáziskezelővel találkozhattál.
- nem, nem hagyom ki a szoftvert.
- "Az, hogy milyen típusú adatbázist érdemes használni, azt a szoftver dönti el, a szoftver igényei szerint kell adatbázist választani, ami tudja a megfelelő funkciókat": persze, ez egy frankó álmodozás, a valódi életből vett tapasztalatok meg azt mutatják, hogy egy vagy több tulajdonságban minden adatbáziskezelő hibádzik. Az egyik az egyikben, a másik a másikban.- "ha noSQL-t használsz és a szoftver rétegben megírod alá az rdbms funkcionalitást": ez egy ökörség. Azért használok nosql szerű adatbáziskezelőt, mert NEM akarok rdbms funkcionalitást, mivel az korlátoz.
- "különféle tranzakciók során garantált-e az adatbázis integritása, ...": nem értem a problémát. annyira lehetetlennek tartod, hogy amit egyszer le tudtak programozni (az rdbms-ben), azt máskor soha nem lehetett leprogramozni? ne már...
-"Akkor meg oda lyukadunk ki, hogy gyakorlati szempontból nézve mégsem hasonlíthatod össze.": miért?
- " Kevés nagyobb ökörség van, mint noSQL-t használni, majd szoftveresen alátenni azokat a funkciókat, amiket egy rdbms tud.": ez igaz. más kérdés, hogy ilyet nem is akar senki. ha hálós adatbázist használsz, akkor hálós gondolkodásmódot kell felvenned és úgy kell programoznod. Az, hogy rdbms szemlélettel programozol hálós rendszert, az ökörség, mint ahogy te is leírtad.
- persze, csak ha a drága szoftver nagyságrendileg lóg ki a költségvetésből, akkor felesleges agyalni rajta.
A neve egyszerű: a hálós adatmodell szabványt a codasyl dbtg dolgozta ki, magyarul Halassy Béla munkája alapján terjedt el. De olvashatsz róla a Korth-Silberschatz könyvben is.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
ddekany
veterán
"Bankos példánál maradva: sql-ben egy ügyfél számláján a mozgásokat, a history-t kb. úgy szeded elő, hogy egy táblából szelektálsz azon sorokra, ahol a tranzakcióhoz tartozó számlaazonosító az, amit keresel. Kapsz egy eredményhalmazt, amin egyesével végiglépkedve kapod meg a program adatterületein belül az eredményt.
Hálósban meg megkeresed az ügyfél számláját, ahhoz oda vannak láncolva a mozgás rekordok, csak a láncon kell végigmenni"
Felfűzöd egy láncolt listára az összes tranzakcióját? Bár végül is most mindegy. A lényeg, hogy egymáshoz fűzhetsz entitásokat. De hát hagyományos RDBMS-ben is megteheted ugyan ezt: FK->PK. Miért lehet egyik esetben ez hatékonyabban megvalósítani, mint a másikban? Nekem ugyan annak a problémának tűnik ez itt is ott is... Tárolhatod a hivatkozást mind valami közvetlen címet, de aztán ha mozgatni kell célpontot fizikailag, írhatod át mindenhol a rá mutató referenciát, azt is atomi műveletben. Szóval általában marad valami keresgélős megoldás, persze nem szekvenciálisan, hanem valami olyan adatszerkezettel amiben viszonylag gyorsan is lehet keresni. Hogy kerülik ezt ki noSQL-ben?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
it Szeptember 21-étől 23-áig hazánkban első alkalommal kerül megrendezésre SQLU Summit, az adatbázisszakma különböző ágait összefogó nemzetközi konferencia.
- LG LCD és LED TV-k
- Motoros topic
- GoodSpeed: SAMSUNG Galaxy Buds FE (SM-R400NZAAEUE) a 9 éves SONY SBH20 utódja (nálam)
- Samsung Galaxy S23 Ultra - non plus ultra
- PlayStation 5
- Aliexpress tapasztalatok
- Xbox Series X|S
- OLED TV topic
- Motorola Moto G24 Power - hol van az erő?
- Vicces képek
- További aktív témák...
