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

• #6 cucka addikt bambano #5

  Új Válasz 2011-08-09 19:57:37 #6

  Ú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

  

  cucka

  addikt

  válasz bambano #5 üzenetére

  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.

• #11 cucka addikt sztikac #9

  Új Válasz 2011-08-10 20:51:44 #11

  Ú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

  

  cucka

  addikt

  válasz sztikac #9 üzenetére

  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 ]

• #15 cucka addikt bambano #13

  Új Válasz 2011-08-11 11:43:56 #15

  Ú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

  

  cucka

  addikt

  válasz bambano #13 üzenetére

  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 ]

• #25 cucka addikt bambano #21

  Új Válasz 2011-08-11 14:45:16 #25

  Ú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

  

  cucka

  addikt

  válasz bambano #21 üzenetére

  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 ]

• #28 cucka addikt bambano #27

  Új Válasz 2011-08-11 21:24:40 #28

  Ú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

  

  cucka

  addikt

  válasz bambano #27 üzenetére

  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

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