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

• #2 dajkopali addikt bambano #1

  Új Válasz 2011-08-09 17:44:47 #2

  Ú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

  

  dajkopali

  addikt

  válasz bambano #1 üzenetére

  te kis provokatív

  "fácánjava calvadosban/teljesítünk, egyre jobban " - Konok Péter

• #4 burgatshow veterán bambano #3

  Új Válasz 2011-08-09 18:30:57 #4

  Ú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

  

  burgatshow

  veterán

  válasz bambano #3 üzenetére

  Valamiben csak tárolni kell az adatokat.

  Azt meg nem adod elő nekem, hogy egy olyan adatfarmban, ahol több milliárd rekord van, eltárolod nekem valami alternatív formában, indexelve, kereshetően, több részre osztva RDB nélkül...

  [ Szerkesztve ]

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

• #14 ddekany veterán bambano #13

  Új Válasz 2011-08-11 11:12:42 #14

  Ú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

  

  ddekany

  veterán

  válasz bambano #13 üzenetére

  Van olyan "noSQL" megoldás amit te üzleti (pl. banki) adatok nyilvántartására használnál?

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

• #18 attila9988 őstag bambano #17

  Új Válasz 2011-08-11 13:54:42 #18

  Ú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

  

  attila9988

  őstag

  válasz bambano #17 üzenetére

  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)

• #19 ddekany veterán bambano #16

  Új Válasz 2011-08-11 13:57:39 #19

  Ú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

  

  ddekany

  veterán

  válasz bambano #16 üzenetére

  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.)

• #23 attila9988 őstag bambano #21

  Új Válasz 2011-08-11 14:32:39 #23

  Ú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

  

  attila9988

  őstag

  válasz bambano #21 üzenetére

  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)

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

• #31 ddekany veterán bambano #27

  Új Válasz 2011-08-13 22:58:04 #31

  Ú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

  

  ddekany

  veterán

  válasz bambano #27 üzenetére

  "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?

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