A NoSQL (pl. MongoDB) szerintem...

 ( carlcolt | 2014. december 22., hétfő - 8:37 )
...csak egy hype, semmi újat nem nyújt, semmi szükség rá
7% (23 szavazat)
...csak olyan adatra jó, ahol csak key-value/array-kat tárolunk minden külső függőség (pl. Constraint foreign key) nélkül
32% (103 szavazat)
...rengeteg esetben jó, ritka hogy tényleg az SQL jobb valami adathoz NoSQL helyett
14% (45 szavazat)
...teljes mértékben alkalmas mindenre amire a relációs adatbázisos SQL-ek
2% (6 szavazat)
...el fogja pusztítani hamarosan az így feleslegessé vált SQL RDBMS-eket
0% (1 szavazat)
Egyéb, leírom hozzászólásban
7% (23 szavazat)
Nem próbáltam még SQL és / vagy NoSQL megoldásokkal dolgozni
37% (119 szavazat)
Összes szavazat: 320

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A 2.-ra szavaztam, nagyon fajt a 4., 5. lehetosegeket beleirni a szavazasba, de muszaj volt, mert egyre tobb ilyen (velem egyet nem erto) szemellyel talalkozok, kivancsi vagyok milyen az aranyuk.

Nem igazán ismerem a NoSQL rendszereket, de a hype-ot látom körülöttük. Nekik, akik szerint mindenre ez lesz majd (újra) a megoldás, nemrég megjelent egy összehasonlítás Postgres és a MongoDB között:

EDB found that Postgres outperforms MongoDB in selecting, loading and inserting complex document data in key workloads involving 50 million records:

  1. Ingestion of high volumes of data was approximately 2.1 times faster in Postgres
  2. MongoDB consumed 33% more the disk space
  3. Data inserts took almost 3 times longer in MongoDB
  4. Data selection took more than 2.5 times longer in MongoDB than in Postgres

--
The Elder Scrolls V: Skyrim

Like

Anno én is végeztem méréseket a témakörben, a MongoDB-nél lényegében minden gyorsabb.

Én is végeztem méréseket, és a Cherokee-nál lényegében minden gyorsabb.
Jaa, a terepezést kihagytam.

Egyáltalán nem vagyok a téma szakértője, de biztosan nyújt valami előnyt is a MongoDB (vagy inkább a noSQL). Könnyebb karbantarthatóság, egyszerűbb lekérdezések? Ha esetleg valaki nálam szakértőbb itt jár, tudná egy példával illusztrálni az előnyét? (lusta vagyok utánakeresni)

Üzemeltetési szempontból előny a robusztusabb replikáció, egyszerűbb skálázás és nagy általánosságban a jobb hibatűrés.

plusz rugalmasabb a struktúra. Egy start upnál ahol még gyakran változik az adatszerkezet ez előnyös lehet.

Egy start upnál ahol még gyakran változik az adatszerkezet ez előnyös lehet.

ezt a gyogyszemet egyszer tanitani fogjak majd valaLOL...

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Mi a baj vele? A mongodb-s oktató videókban volt interjú pár webes startup-pal és ez volt az egyik érv amiért kedvelték.
(amúgy ha hülyeséget írok is értelmesebb lenne egyből leírni, hogy mi a gond, mint itt lol-ozni)

De hat LOL-ozni sokkal menobb... (nem)
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

latom, zokon vetted, hogy beszoltam a ketismeretlenes egyenlet megloldokeplete miatt...

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Mé', van neki: X= -A^(-1)B

Tudod mi a vicces? Hogy nem is lattam mostanaig azt a kommentedet, szoval eselyem se volt megsertodni rajta.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

ugy ertem, nem kene, hogy a struktura allitolagos rugalmassaga miatt valassza egy startup a nosql-t egy rdbms/... helyett. Hanem mindig a feladathoz kene valasztani az eszkozt: ha pedig az olyan, akkor a startup szamara is egy rdbms a jo valasztas, nem a mongodb, etc. Egy akar sok eve a piacon levo ceg eseteben is - indokolt esetben - szukseges aldozat lehet az adatok valami egeszen masba migralasa. Szoval amit mondani akartam az az, hogy egy ceg startup vagy sem, az aligha realis erv egy technologia mellett/ellen...

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

"amúgy ha hülyeséget írok is értelmesebb lenne egyből leírni, hogy mi a gond, mint itt lol-ozni"

De hiszen a hup-on vagy, itt nem divat kijavítani a másikat, inkább szórakozni azokon akik esetleg hülyeséget írnak (bár nem gondolnám hogy azt írtál főleg ha csak közvetítetted amit olvastál/láttál)

Huhh, ebből nem sok "újat" olvastam ki, de kicsit utánaolvasgattam. Találtam egy RDBMS-sel való összehasonlítást is, és ha jól értelmeztem/szűrtem le, erősen feladatfüggő, hogy melyiket érdemesebb választani (ahogy lentebb is írták, illetve a panaszolt lassúság is ennek tudható be).

a kerdes az hogy mit akarsz csinalni, a ketto nem igazan egymas kivaltasara van, nincs ezustgolyo, minden jo valamire es van amire meg nem jo. Van amire sima sql megoldasok jobbak van amire nosql megoldasok.
Kezdve azzal hogy noSqlben is van legalabb 3 kulonbozo fele alvaltozat, key-value, column-based, es graph (aztan lehet van meg tobb is) amik mind masra megoldasok, egy key value tipusuval kinszevedes az amire egy graph database valo es vice-versa. szoval ezek egyike sem az ami majd ugy ahogy van levalt egy masik technologiat, itt csak arrol van szo hogy kaptunk egy joval arnyaltabb skalat ahol kedvunkre valogathatunk a kulonbozo megoldasokbol figyelembe veve hogy melyik illeszkedik leginkabb a probelmahoz amit meg akarunk oldani.

Ha valahol el akarod kezdeni akkor pl ezt tudom ajanlani: https://www.youtube.com/watch?v=qI_g07C_Q5I

EDB egy PostgreSQL megoldásszállító, nincs kétségem, hogy korrekt a teszt, de nem szerencsés soha az ilyen.

Amikor OO környezetben programoztam mindig a munka (kódolás) és valószínűleg a futásidő legnagyobb része is az OO/RDBMS transzformáció volt. Keretrendszerek teljesítményét pedig kevésbe tudom kontrollálni. Ezén marad egy idegen érzés, mindig.

Ezért én értem a Mongo és más NoSQL törekvéseket. Sokszor a fájlrendszert használtam adatbázisnak, ha a gyorsaság fontosabb volt.

Mongo-t majd megnézem, ha megint rászorulok ilyesmire. A lényeg, hogy örülök, hogy azért ez az irány is megy.

---------------------------------------------
ubuntu - android - smalltalk - flamenco

azert a mongodb-n kivul van jopar masik megoldas.

A mongodb nem azert terjed mert a leggyorsabb lenne,
hanem konkretan sql-rol migraloknak van kitalalva.
Minden SQL lekerdezesnek megcsinaltak a parjat kb.

Aki a sebessegre akar menni, annak azert van mibol valogatnia.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Az a baj ezzel a statisztikával, hogy a noqsl egyik jóságát kihagyja: az adatszerkezetek egymásba ágyazhatóságát. Mi három éve használjuk production környezetben, és van olyan collection-ünk, ami SQL-ben 5-6 táblából joinnal jönne csak össze lekérdezésnél, míg mongodb-ben 1 "where id=X". Lehet, hogy több helyet foglal, és lehet, bizonyos esetekben lassabb (indexekkel mi a helyzet?), de én 6-7 év oracle tapasztalat után felüdülésnként kezdtem el használni a mongodb-t.
Igaz, hogy az adat-struktúra összeállításánál előre kell nagyon gondolkozni, és okosnak kell lenni, de utólag meghálálja magát, nagyon.

de ti tenyleg csak MySQL-t lattatok? Oracle-ben meg Postgres-ben is van nested tabla meg sorobjektum meg oszlopobjektum, eleg hasonloan mukodik.

NoSQL-t, csak az App Engine Datastore-t használom, nem tudom mennyire igaz a többire, de az valahol a 2 és a 3 között, a "csak" pont olyan túlzás a 2.-ban, mint a "rengeteg" a 3.-ban.

+1
szerk.: a 3-asra szavaztam, de valóban a 2 és 3 közt van az igazság szerintem.

Én is kb. így látom. Mind a NoSQL-nek, mint a klasszikus SQL-nek van létjogosultsága. Erősen függ a megoldandó feladattól és az adatmennyiségtől.

Naponta dolgozom SQL es noSQL megoldasokkal es a tapasztalatom az, hogy ezek kombinalt alkalmazasa szinte "kotelezo" abban az esetben ha a tarolt/keresett adathalmaz merete nagy es folyamatosan novekszik. SQL-t skalazni kesz harcmuveszet noSQL-hez kepest (nem feltetlenul MongoDB-re gondolok).

Igen, pont ezt akartam írni, hogy azért a jobb noSQL megoldásoknál simán be lehet rakni egy-egy új szervert, és akkor az működik, míg postgresql-nél masszívan kell
trükközni.

Ez erdekel. Hogy oldod meg a replikaciot, a konzisztenciat egy noSQL szervernel? Egyaltalan, melyik az a noSQL megoldas, aminel szerinted konnyu az uj szerver beszerelese (mert nem konkretizaltad)?
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Szia, még csak ismerkedünk a noSQL-lel, eddig postgresql-t használtunk. Sajnos belefutottunk egy olyan problémába, hogy iszonyat mennyiségű adatot kell tárolnunk, és ezeket
user interface-ről kereshetővé tenni, úgy, hogy néhány másodperces válaszidőt tudjunk hozni. Pár éve nézegettem a noSQL megoldásokat, és ott egy cluster összerakása tényleg
pofonegyszerű volt (postgresql-ből eddig master-slave redundanciát sikerült összerakni). Nem vagyok biztos benne, hogy mongoDB volt, de úgy emlékszem, hogy valami populáris rendszert próbálgattam, tesztelgettem. Úgy emlékszem, hogy eventual consistencyt tudott a rendszer, az akkori céljainkra ez nem volt megfelelő, viszont erre a mostani feladatra meg pont jó lenne...

"Igen, pont ezt akartam írni, hogy azért a jobb noSQL megoldásoknál simán be lehet rakni egy-egy új szervert, és akkor az működik, míg postgresql-nél masszívan kell trükközni."
...
"még csak ismerkedünk a noSQL-lel"
...
"úgy emlékszem, hogy valami populáris rendszert próbálgattam, tesztelgettem"
...
"Úgy emlékszem, hogy eventual consistencyt tudott a rendszer"

En meg ugy fogok emlekezni hogy teljesen hulye vagy a temaban, de azert beallitod tenykent hogy milyen jo az a rendszer amit tulajdonkeppen nem is hasznaltal arra, amirol allitod hogy nagyon alkalmas ra meg "alkalmasabb mint a Postgres".

Mint írtam, PostgreSQL-t használunk, és végigpróbáltuk az összes lehetőséget, de egyedül a master-slave megoldást sikerült normális, használható állapotba hozni. Ez viszont sajnos azt jelenti, hogy limitálva vagyunk vagy 2 szerverre, vagy pedig alkalmazás layerben kell kezelnünk az egynél több adatbázis kezelést.

Ehhez képest játszottam korábban egy noSQL rendszerrel, ahol a legalapabb tutorialt követve nagyon szépen összeállítottam egy clustert (4 virtuális géppel).

Ezért mondom, hogy "simán be lehet rakni egy új szervert", mert a kis dummy tesztemnél kb. egy parancsot kellett végrehajtanom, és a szerver belépett a clusterbe, és működött, ahogy kellett.

Nem írtam sehol, hogy alkalmasabb, mint a postgreSQL, azt írtam, hogy itt kapásból ment a cluster.

"iszonyat mennyiségű adatot kell tárolnunk, és ezeket user interface-ről kereshetővé tenni"

Megkockaztatom hogy ez nagyreszt szoveges adat, ha nem akkor ne is torodj velem :)
az ilyesmire tipikusan fulltext search-ot szokas hasznalni nem pedig direktben adatbazisban turkalast, ilyeneket tudok javasolni hogy: sphinx, solr, elastic

Szia,

nem, GPS koordinátákat akarunk tárolni, egyéb metainformációkkal... de köszi, megnézem az ajánlott rendszereket, hátha jó lenne nekünk...

A nagyságrend kb. olyasmi, hogy percenként 4 üzenet, 3000+ felhasználóval, 0-24-ben, és 3-hónap, fél évig kell tárolni az adatokat, ezeket visszakeresni (gipsz jakab
hol járt 2014.01.02 és 2014.01.03 között). Ez nagyságrendben 3 milliárd rekord, ebből kellene snail trail-t rajzoltatni, valami elfogadható sebességgel. Az egy táblába
pakolunk mindent már elvetettük, most az az ötlet, hogy minden felhasználó kap egy táblát, így csak olyan max. 1 millió rekordban kell keresni, ami bőven elfogadható
mennyiség, ráadásul még időre is lehet szűrni.

Én Cassandra-t javasolnék, egy tábla elég, idősoros adatokra kiváló (timeuuid).

CouchDB-nél mondjuk 5 perc egy master-master replication. Vagy master slave. Ha valami cloud szolgáltatót használsz, pl. Cloudant, akkor kevesebb. (Persze a CouchDB kevés helyen elég, de ez egy másik kérdés.)

Cassandra esetén egy node hozzáadása annyi, hogy megmutatom az új tagnak a haverokat (seed), aztán magára hagyom őket. A node eltávolítás egy 'nodetool decommission' parancs. Egy döglött node cseréje annyi, mint az új hozzáadása, csak pluszban megmondom neki, hogy melyik haverja helyére kerül.

Minden mást a Cassandra elintéz. Jól.

Engem inkabb a NoSQL + Mission critical rendszerek erdekelnenek? Egy jol konfiguralt RDBMS eseten (bar csak Oracle es MySQL tapasztalatom van.) Az alap, hogy ha egy tranzakcio commitolasra kerult, akkor az az adat bekerult az adatbazisba, es elerheto, akarmi tortenjen is.
Amikor utoljara neztem a Mongo-t, akkor ott meg erre nem volt garancia, ez mar valtozott?

A probléma nem adatbáziskezelő vs noSQL, hanem logikai: hogyan oldjuk meg egy N szerverből álló elosztott rendszerben a konzisztenciát...

http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1

A NoSQL adatbázisok úttörői az elosztott adatbázisoknak. Idővel backendet jelenthetnek és irányt mutatnak relációs társaiknak.
Viszont az üzleti felhasználásban nagyon sokat jelent, egy relatív egyszerű, bejáratott felület, mint amilyen az SQL.

Én abban bízom, hogy előbb utóbb moduláris lesz minden adatbázis, választható frontenddel és backenddel. Remek kezdeményezés szerintem a FoundationDB, vagy a becsődölt InfiniDB, és a MariaDB+Cassandra kombináció.

Én először a NoSQL adatbáziskezeléssel találkoztam (MUMPS) még 2000 táján és ezután kellett relációs adatbázisokkal dolgoznom. Nekem ez visszalépésnek tűnt akkor. (Volt olyan kollégám aki RDBMS-ről váltott MUMPS-ra, ő meg azt érezte visszalépésnek :-)) A MUMPS alapjain írták a Caché-t, ami egy időben a világ leggyorsabb adatbáziskezelőjének mondta magát. A MUMPS-t és a Caché-t is el lehet érni SQL-en keresztül, csak nem érdemes...
A db - object összerendelés MUMPS-os megoldásánál nehezen tudok egyszerűbbet elképzelni. Úgy emlékszem ha a változó ^-al kezdődött, akkor közvetlenül az adatbázisra vonatkozott. Olyan, mintha a ^-al kezdődő változók olyan globális változók lennének amik eltárolódnak a lemezen, tehát amint beállítjuk az értékét, az összes többi futó folyamatban már az új érték látszik. Deklarálni sem kellett a változókat, csak használni őket. Minden parancsnak volt 1-2 karakterre lerövidített verziója, így egy programsorban egész sok mindent meg lehetett oldani...

A SQL/NoSQL adatbazisok kulonbozo dolgokra valok.

A SQL irasra es ad-hoc olvasasra valo: a normalformara hozott relacios adatbazisban, tranzakcio kereteben iras a fo use case. A lekerdezesek pedig nagyon rugalmasak, megfelelo indexek eseten a sema valtoztatasa nelkul is megfelelo teljesitmennyel futtathatok.

A NoSQL olvasasra valo: az egyseg, a "dokumentum" optimalis esetben megfelel egy lekerdezes eredmenyenek, vagyis plusz joinolas nelkul, egy darab olvasassal lehet prezentalni az adatot a usernek. Mindezt raadasul konnyu nagy rendelkezesre allassal kombinalni (lasd meg CAP theorem). Cserebe viszont az iras maceras, altalaban a muvelet "eventually consistent", vagyis elobb-utobb latni fogod a frissitett adatot is, de nem tudod, mikor (es hol). Nincs hagyomanyos tranzakcio, egy dokumentumot egyszerre tobben is modosithatnak, es ilyenkor nem az adatbazis, hanem a program feladata feloldani a konfliktust (Riakban legalabbis igy van).

Aztan ott a Redis, ami lenyegeben egy perzisztens hashtabla, cache-elesre (pld. sessionok adatainak tarolasara) tokeletes.

Es meg nem is emlitettuk a specializaltabb adatbaziskezeloket (pl. grafadatbazisok, oszlop-orientalt adatbazisok stb).

Izelitonek es alapveto tajekozodashoz tudom ajanlani a Seven databases in 7 weeks konyvet, viszonylag atfogoan ir a temarol.

(Ebbol az egeszbol csak annyit akartam kihozni, hogy a kerdes feltevese rossz, nem jobb vagy rosszabb a NoSQL a hagyomanyosnal, minthogy nem helyettesitoi egymasnak.)

a kerdes feltevese rossz

+1, meg a sablonosan szadba eroltetett valaszok is

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

"egy dokumentumot egyszerre tobben is modosithatnak, es ilyenkor nem az adatbazis, hanem a program feladata feloldani a konfliktust"

Mongóban az írásnál adatbázis-szintű lock jön létre. Se írni, se olvasni nem tud ilyenkor más. Egy kivétel van, amikor az íráshoz adatot kell betölteni diszkről memóriába. Ilyenkor egy időre engedélyezett (lehet) az olvasás.

"Mongóban az írásnál adatbázis-szintű lock jön létre. Se írni, se olvasni nem tud ilyenkor más. "

Mintha ez igencsak a paci tuloldala lenne, nem?
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Igen (akárcsak a jogosultságkezelés). De ez nem azt jelenti, hogy a Mongo fejlesztők szerint ez így jó, egyszerűen csak nem ez volt a prioritásos funkció. A következő verzióban már lesz collection szintű lock, szóval szépen lassan azért reszelik ezt a részét is.

Nesze neked "web scale" :D

Mi egy szerkesztőségi rendszerhez használjuk, ahhoz például tök jó. Kevés az írás, nincs szükségünk tranzakciókra (ha egy hiba folytán inkonzisztencia lépne fel, akkor sincs semmi, kijavítjuk, üzletileg nem kritikus). Cserébe nagyon kényelmes benne kötetlen formátumú dokumentumokat tárolni, keresni.

"...a kerdes feltevese rossz..."

Nyilvan ilyen erzese volt a kolleganak:

https://www.youtube.com/watch?v=b2F-DItXtZs (A hires "Mongo DB Is Web Scale" video.)

Zsenialis video!

+1

Teljesen egyetértek, csak egy kicsit nem a zárójeles résszel.
Szerintem helyettesíthető egyik a másikkal, csak egészen másfajta gondolkodással és más fajta eszközökkel lehet elérni kvázi ugyanazt vagy jobbat a másiknál.

Erősen feladatfüggő.

Az előző munkahelyemen vagy egy üzleti naplózás, amelybe naponta 10-15 millió bejegyzés kerül, amelyet meg kell őrizni 5 évig. Ez napi 30GB lazán struktúrált adatot jelent az öt évre ez nagyjából 50TB. Erre van egy jól bejáratott IBM-es stack, ami szerint a naplóbejegyzés MQ-n kerül bejegyzésre, ez replikált és perzisztált, innen dolgozódik be egy DB2 adatbázisba, amely szintén replikált, majd 5-10 nap után kikerül archiválásra TSM-be. Na, mindez csillagászati áron van...

Nyáron utolsó munkámként csináltam egy PoC-ot Cassandra alapokon, ahol is virtualizált környezetben egy cloud szolgáltatónál három datacenter-be tettem két-két rack-be három-három Cassandra node-ot (vagyis volt összesen 3*2*3 node, azaz 18 node) és WildFly node-ot, szépen bekonfiguráltam, és csináltam egy néhány órás tesztet kb. két tucat dollárért ($0.5/óra/gép a DO-nál). Annyi változott, hogy online elérhető volt minimális válaszidőkkel a teljes (generált) 1TB adathalmaz... de a Cassandra lineárisan skálázható, nem igényel különösebb karbantartást, nem igényel mentést, se archiválást és olcsó gép is elég neki olcsó storage-al, mert könnyen cserélhető egy döglött node.

Aztán nem lett belőle semmi, mert egyrészt az üzemeltetésen nem értették meg az elosztott adatbázis kezelés lényegét: mindenáron high end storage-t tettek volna alá virtualizált gépekkel és folyton a mentést meg az archiválást kérdezték... másrészt meg nem éreztem késztetést arra, hogy jól elmagyarázzam a Cassandra alapelveit és működésmódját, mert már igencsak eljöttem volna onnan... :)

Szóval lehet jó dolgokra használni, de például egy számlavezető rendszert nem lehet ilyesmire tenni... van viszont egy csomó lehetőség, amelyre sokkal jobban használható a NoSQL, mint az SQL.

Engem meglepett a hozzászólások sokfélesége, azt hittem jobban fel vannak készülve az informatikusok a témában. Jól esett gyakorlati dolgot is olvasni. (Számlázót simán írnék MongoDB-re. )

Akit érdekel, annak ott a Google.

http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Akit meg célirányosan a mongodb érdekel, annak ott van az ingyenes online kurzus:

https://university.mongodb.com/courses/schedule

"Csak a változás állandó." - Herakleitos

mindenáron high end storage-t tettek volna alá virtualizált gépekkel és folyton a mentést meg az archiválást kérdezték
A mentés/archiválás részét valószínüleg jogosan kérdezték.

Archiválás: 5 évig megőrzésből szokott következni olyan követelmény is, hogy olyan módon legyen tárolva, amit kifejezetten nehéz utólag módosítani-> offline adathordozón.

Backup: szintén kellhet (akár offline adathordozóra) backupolás, mert hiába replikált az adatbázis, ha van egy frontend szoftver/üzemeltetői hiba, az egész megy a levesbe. Kb "raid nem helyettesíti a backupot" elv.

High-end storage, virtuális gépek: ez meg gondolom azért, mert saját datacenterben már bevezettek egy ilyen rendszert, ahol lehet live migrálni, illetve hoszt lehalás esetén van HA/auto-restart. Egyszerűen azt akarják, hogy minden szolgáltatás egységes módszerrel legyen kezelve, még akkor is ha valamelyikre teljesítmény vagy költséghatékonyság szepontjából nem a legoptimálisabb.
---
Régóta vágyok én, az androidok mezonkincsére már!

+1, en sem talaltam semmi kivetnivalot ezekben.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

amit kifejezetten nehéz utólag módosítani-> offline adathordozón

akkor mar inkabb worm drive, bar nyilvan attol is fugg, hogy hol hogyan definialjak a 'kifejezetten nehezet'

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

"A mentés/archiválás részét valószínüleg jogosan kérdezték."

A jelen megoldás sincs mentve vagy archiválva azon a módon, ahogy gondolod.

"Archiválás: 5 évig megőrzésből szokott következni olyan követelmény is, hogy olyan módon legyen tárolva, amit kifejezetten nehéz utólag módosítani-> offline adathordozón."

Az egyes Cassandra node-ok fájlrendszer szintű mentéséről és archiválásáról volt csak szó. Offline és read-only archiválás nincs.

"Backup: szintén kellhet (akár offline adathordozóra) backupolás, mert hiába replikált az adatbázis, ha van egy frontend szoftver/üzemeltetői hiba, az egész megy a levesbe. Kb "raid nem helyettesíti a backupot" elv."

NoSQL esetén egyébként a törlés a legköltségesebb művelet, nem is gyakori, hogy a törlést használják a felsőbb rétegben, inkább megmarad a régi adat is. Gyakori az is, hogy módosítások sincsenek, minden módosítás új sorként kerül letárolásra és a felsőbb szoftverréteg dolga a legfrissebbet használni, illetve a több módosítás összefésülése egy újabb sorrá. Nehéz olyan hibát ejteni, hogy mentésből kelljen visszaállítani bármit is, ha sikerült megérteni a működésmódot.

Ha nem sikerül megérteni a működésmódot, akkor fejlesztőt és üzemeltetőt kell cserélni.

"High-end storage, virtuális gépek: ez meg gondolom azért, mert saját datacenterben már bevezettek egy ilyen rendszert, ahol lehet live migrálni, illetve hoszt lehalás esetén van HA/auto-restart. Egyszerűen azt akarják, hogy minden szolgáltatás egységes módszerrel legyen kezelve, még akkor is ha valamelyikre teljesítmény vagy költséghatékonyság szepontjából nem a legoptimálisabb."

Az egész kérdéskör ebből indult ki. Egy high end storage esetén a többszörösen replikált 50TB igencsak drága dolog, ahogy a sok nagy méretű node virtualizációja és a mindenféle hardveres és alacsony szintű HA megoldása is drága. Nagyon drága.

A NoSQL rendszerek viszont nem erre a környezetre vannak kitalálva, hanem arra, hogy olcsó, egyszerű gépekre és szinte fájdalmasan egyszerű hardveres architektúrára kerülnek, mert a HA-t maga a NoSQL szoftver oldja meg. Felesleges a high-end replikált storage, felesleges a virtualizáció, felesleges a host migrálása... egy Casssandra cluster-t alapvetően úgy kell definiálni, hogy datacenter-rack-node, ha ebbe a topológiába beleszól egy virtualizációs szoftver automatikus mozgatása az nem csökkenti, hanem növeli az üzemeltetési kockázatot. Ha ebbe beleszól a high-end storage replikálása, az nem növeli, hanem csökkenti a teljesítményt.

A NoSQL nem csak a fejlesztőktől igényel homlokegyenest más gondolkodást, hanem az infrastruktúra üzemeltetőktől is, pláne őket nehéz arról meggyőzni, hogy a mindenféle drága játékszer használata helyett csak a fizikai vasakat kell cserélgetniük, mert szakmailag erősen visszaesésnek gondolják (és ez így van, de ez egy ilyen világ).

A PoC oka az OPEX csökkentési nyomás volt a felsővezetés irányából, és ezzel a lépéssel jelentős OPEX lett volna megtakarítható azonos, illetve néhány paraméter tekintetében magasabb funkcionalitás mellett:
- a teljes öt év kereshető online, nem kell megvárni az automatikus és a kézi visszatöltést szalagról
- a hardver cserén kívül közel zéró adminisztráció kell, nem igényel azonos hardvert, "ami éppen a polcon van" az jó
- leállás nélkül frissíthető
- igények szerint bővíthető és csökkenthető a cluster mérete
- nem igényel host szintű mentést

Azon külön csodálkozom, hogy azért is küzdeni kell (mind itt, mind akkor és ott), hogy nagy mennyiségű idősoros adatok tárolására kitalált elosztott adatbázist használjunk nagy mennyiségű idősoros adatok tárolására... :)

Ok, ha eddig sem volt úgy mentve-archiválva, akkor tényleg kérdéses, hogy miért most kezdtek el ragaszkodni hozzá.

Ugyanakkor az, hogy a törlés/felülírás költséges művelet, még nem jelenti azt, hogy egy tetszőleges szoftverhiba miatt nem eshet szét az egész. Főleg az tud problémás lenni, ha leáll a replikálás, esetleg valami split brain állapot áll be és utána nem tud visszaszinkronizálni. Ezekre ráadásul nagyon nehéz tesztet csinálni.

Nyilván, ha garantáltan sosem törölsz/update-elsz akkor van esély rá, hogy megoldható utólag az adatok összefésülése, de nem kívánom senkinek, hogy ilyennel kelljen szopnia. 50TB adaton egy próbálkozás is napokat vehet igénybe és utána ellenőrizni sem egyszerű, hogy tényleg minden a helyére került.

Üzemeltetői oldalról sem vagyok benne biztos, hogy "visszalépés" egy ilyen rendszer működtetése. De mindenképpen kilóg az eddig bevezetett rendszerből, és ezt valóban nem szokták jó szemmel nézni.

Sokminden múlik azon is, hogy ki fúrta meg. Valami manager, mindenféle ITIL-es processekre hivatkozva, vagy a drága játékszerekkel foglalkozó egyszeri operátor.
---
Régóta vágyok én, az androidok mezonkincsére már!

"Ok, ha eddig sem volt úgy mentve-archiválva, akkor tényleg kérdéses, hogy miért most kezdtek el ragaszkodni hozzá."

Eddig host szinten volt mentés és archiválás minden érintett gépről, amelyiken átment az adat; minden host virtualizálva volt, hogy hardverhiba vagy egyéb esetben könnyen át lehessen mozgatni másik fizikai vasra. Ez volt a HA alapja.

Egy Cassandra node-ot viszont nem mentünk és nem archiválunk host szinten (mert replikálja magát a datacenter-rack-node koordináta rendszerben), általánosságban nem virtualizáljuk, mert érdemes egy egész fizikai gépet adni egy node-nak (dedikált lokális memória, SSD, SATA erőforrásokkal), nem mozgatjuk fizikai gépek között (mert hiba esetén nem lesz jó a datacenter-rack-node koordináta rendszerben a quorum és a replikáció).

http://www.datastax.com/documentation/cassandra/2.0/cassandra/architecture/architecturePlanningHardware_c.html

"Ugyanakkor az, hogy a törlés/felülírás költséges művelet, még nem jelenti azt, hogy egy tetszőleges szoftverhiba miatt nem eshet szét az egész. Főleg az tud problémás lenni, ha leáll a replikálás, esetleg valami split brain állapot áll be és utána nem tud visszaszinkronizálni. Ezekre ráadásul nagyon nehéz tesztet csinálni."

Ha leszakad egy datacenter, akkor is csak annyi van, hogy mindenki írja a naplót a saját környezetében, amikor meg helyreáll a kapcsolat, akkor összefésülik az adatokat a node-ok (replikált idősoros timeuuid kulcsok!). Addig meg a lekérdezések esetleg hiányosak lesznek, nem nagy dolog... amikor az MQ-DB2 bedolgozás állt meg valami adatbázis túlterhelés vagy hiba miatt, akkor fél napig nem volt friss adat, nem lényeges... olyan is volt, hogy az MQ állt meg, akkor egyáltalán nem volt adat addig... :)

"Nyilván, ha garantáltan sosem törölsz/update-elsz akkor van esély rá, hogy megoldható utólag az adatok összefésülése, de nem kívánom senkinek, hogy ilyennel kelljen szopnia. 50TB adaton egy próbálkozás is napokat vehet igénybe és utána ellenőrizni sem egyszerű, hogy tényleg minden a helyére került."

Faék egyszerűségű a Cassandra adatstruktúrája és a működésmódja... ehhez képest egy DB2 vagy MQ circular transaction log betelés vagy egy linear transaction log tárhely elfogyás utáni helyreállítás az igazi művészet... :)

"Üzemeltetői oldalról sem vagyok benne biztos, hogy "visszalépés" egy ilyen rendszer működtetése. De mindenképpen kilóg az eddig bevezetett rendszerből, és ezt valóban nem szokták jó szemmel nézni."

Hát... amikor a kocsmában kérdezik az IT-s haverok, hogy mivel is foglalkozol, akkor jobb azt mondani, hogy VMWare ESX-el oldjuk meg a magas rendelkezésre állást vagy EMC high-end storage-t adminisztrálunk és több száz TB adatot mozgatunk, vagy DB2 adatbázis üzemeltetünk, vagy IBM MQ cluster-t konfigurálunk, amin naponta több tíz millió adat megy át... van miről mesélni, vannak sztorik, vannak heroikus küzdelmek...

...a másik munka meg az, hogy hiba esetén kivesszük a gépet a rack-ből, fogunk egy másikat, felmásolunk rá egy image-t és betesszük a régi helyére, a többihez meg nem nyúlunk... :)

"Sokminden múlik azon is, hogy ki fúrta meg. Valami manager, mindenféle ITIL-es processekre hivatkozva, vagy a drága játékszerekkel foglalkozó egyszeri operátor."

Az elsőhöz rengeteg tudás, vizsga, tapasztalat és ismeret kell, amit megfizetnek... a másodikhoz elég egy technikus, tehát nyilván FTE vonzata is van egy ilyen átállásnak... és bizony benne van, hogy ha ilyen módon megtakarít a cég mondjuk 250 millió forint OPEX-et a hardveren és a licenceken évente, akkor ezt azért nem vállalják be, mert akkor "Józsit" is ki kellene rúgni, mert megszűnik a munkahelye.

Technológiailag a megoldás alkalmazható lett volna... ahogy rengeteg példa van arra, ahol Cassandra van rendszeresítve idősoros adatok tárolására... :)

Azt elmeséled, hogy MQ-t mikor és miért szoktak használni egy ilyen környezetben? Köszi.

Egyrészt az aszinkron műveletek miatt, másrészt a laza csatolás miatt... ez esetben adatbázis lassulás esetén nem lassulnak le a naplózást hívó folyamatok, a queue-ban gyűlnek a bedolgozásra váró adatok.

Nem azt akartam mondani, hogy a meglevő rendszer biztosan jobb lett volna a Cassandra-hoz képest, a válaszodból úgy érzem kicsit mintha ezt hallanád ki belőlem. (Volt némi közöm DB2, Websphere MQ és mindenféle ezekre épülő Tivoli termékekhez.)

Csupán annyit, hogy egy ilyen változtatás bevezetésénél egyrészt lehetnek olyan esetek, amiket már terv szinten le kell tudni fedni (ami egyáltalán nem biztos, hogy az adott esetben a Te feladatod lett volna). És elképzelhető, hogy a Cassandra out of the box nem fogja azt a (backup, archiválás) követelmény teljesíteni, tehát valami más is kell még mellé. Nem feltétlenül a teljes meglevő stack, inkább egy inkrementális db dump offline media-ra vagy hasonlóra gondolok.

Másrészt egy költség-haszon analízisre van szűkség. Ha a meglevő EMC-s, VMware HA-s rendszer mellé megjelenik egy ilyen bare metal platform, annak nyilván plusz OPEX költsége van, mert nem egységes a többivel. Ezt legalább becslés szinten meg lehetett volna vizsgálni (valószínüleg szintén nem a Te feladatod), és ez alapján el lehetett volna dönteni, hogy érdemes-e.

A Józsit ki kell-e rúgni kérdésre valahogy nekem mindig az volt a tapasztalatom, hogy mindig több a meló, mint az ember, úgyhogy sok esetben kifejezetten öröm, ha néhány ember esetleg felszabadul más projektre.
---
Régóta vágyok én, az androidok mezonkincsére már!

"Csupán annyit, hogy egy ilyen változtatás bevezetésénél egyrészt lehetnek olyan esetek, amiket már terv szinten le kell tudni fedni (ami egyáltalán nem biztos, hogy az adott esetben a Te feladatod lett volna)."

Mint IT Architect, eléggé átláttam. Pláne ez a terület az egyik saját "modulom" volt, amit éveken át foltozgattam, mint fejlesztő.

"Másrészt egy költség-haszon analízisre van szűkség. Ha a meglevő EMC-s, VMware HA-s rendszer mellé megjelenik egy ilyen bare metal platform, annak nyilván plusz OPEX költsége van, mert nem egységes a többivel."

Óóó... ha ez lett volna az egyetlen kivétel... de igen sok konszolidálatlan mindenféle rendszer működött-működik, hardver-szoftver-módszertan tekintetben is... :)

"A Józsit ki kell-e rúgni kérdésre valahogy nekem mindig az volt a tapasztalatom, hogy mindig több a meló, mint az ember, úgyhogy sok esetben kifejezetten öröm, ha néhány ember esetleg felszabadul más projektre."

Ha őszinte akarok lenni, akkor azt kell mondjam, hogy 30-40 százalékos FTE vágást simán túl tudna élni a cég, csak a megfelelő embereket kellene kivágni, illetve a megszokott "nem kell jónak lenni, elég jónak látszani" elv helyett tényleg jól kellene dolgozni. De ez egy másik történet, amelyben sokan annak örültek, ha a jó emberek mentek el maguktól, mert a hülye hatékonyságnövelő ötleteikkel mindig csak felkavarták az állóvizet... :)

ha a jó emberek mentek el maguktól, mert a hülye hatékonyságnövelő ötleteikkel mindig csak felkavarták az állóvizet... :)

azert te is mintha korbe jarnal n db penzugyi ceg kozott :-)

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Pénzügyi cég volt eddig a CIB, most meg az Uniqa...

...szóval a körbejárástól azért igencsak messze vagyok... :)

Ha ezzel kezded, nem kérdezgetek vissza annyit. :) Én konkrétan nem jártam ott, de 1-2 történetet hallottam az ottani IT-ról és beleillik a képbe amit leírtál.
---
Régóta vágyok én, az androidok mezonkincsére már!

Hát... történeteim nekem is lennének... :D

Üdv,

egyetértek azzal, amit itt írnak a MongoDB-ről.

A legnagyobb előnye a klasszikus relációs adatbázisokkal szemben, hogy nincsenek fix oszlopok, ugyanakkor nincs annyira "távol", hogy át komolyan bele kellene nyúlni a kliens kódba (például a Grails esetében fültőmirigy-sorvasztóan egyszerű, úgy, hogy marad az összes (G)ORM metódus).

Az viszont tény, hogy némi szemléletváltást kell alkalmazni a tervezéskor. Nincsenek (vagyis vannak, de nem úgy) külső kulcsok. A MongoDB dokumentácia erre fel is hívja a figyelmet, hogy relációknál érdemes inkább az egyik dokumentumot beleágyazni a másikba (ahelyett, hogy egymásra hivatkoznának). Nincsenek tranzakciók, ez mondjuk elég komoly ellenérv. Ha az kell, akkor vagy megoldja az ember úgy, hogy egy külön szál vagy akár egy külön program piszkálhatja csak az adatbázist (és ha valamit akarsz tőle, akkor küldj üzenetet MQ-n keresztül).

Sebesség: tény, hogy a MongoDB elég sok mindent eleve a memóriában tart és ez jó.

G.

Elegtelen

????

Oldalamat szexuálja ez az "Elegtelen" hozzászólás, valami magyarázatot ha lehetne kérnem tisztelettel.

+1

"A MongoDB dokumentácia erre fel is hívja a figyelmet, hogy relációknál érdemes inkább az egyik dokumentumot beleágyazni a másikba (ahelyett, hogy egymásra hivatkoznának). "

Igen, csak itt meg valahol serulni erzem a konzisztencia elvet. Evek hosszu soran at vertek a fejunkbe, hogy ugyanazt az adatot egynel tobbszor letarolni rossz, mert nem valtozik egyutt az adat osszes peldanya. En ertem, hogy egy Employee objekt nem nagy, de ha mindenutt jelen van egy odahanyt Employee objekt, mi garantalja, hogy mindegyik ugyanazokat az adatokat tartalmazza a dolgozorol? Semmi, a noSQL at sem latja a belso strukturakat, legfeljebb csak visszaadni tudja.

RDBMS-nel ugye ezzel semmi gond nincsen, letarolom az employee_id-t oda, ahol kell, es amikor az employee adataira vagyom, akkor a kulso kulcson keresztul eloveszem, es mindig ugyanazokat az adatokat veszem elo, fuggetlenul attol, hogy en milyen objektum vagyok.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

MongoDB-ben sem szokás egy adatot többször letárolni, ott is ugyanolyan rossz ez, mint máshol.

Inkább arról van szó, hogy a szorosan összetartozókat kell együtt tárolni.
Pl.: rendelés tárolásánál gyakran látunk ilyen táblákat rdbms-nél, hogy ORDER és ORDER_ITEM. Ezt Mongoban célszerűbb egyben tárolni egy Order objektumban:

Order {
  /order adatai/,
  OrderItems: [
    OrderItem { }, 
    OrderItem { }, ...
  ]
}

Tegyuk fel, hogy az order resze a megrendelo cime. Tegyuk fel, hogy a megrendelo elkoltozik.
Elvileg:
1. mindegyik orderben le van tarolva a megrendeleshez szukseges osszes adat (tehat ebben az esetben a vevo cime)
2. ha valtozik, akkor vegig kell nyalazni az osszes erintett rekordot/dokumentumot, es frissiteni. Plane ha adatbazis szintu lockod van, preferalt write lock-kal (MongoDB), az adatbazisod gyakorlatilag az update idejere - ami sok idot igenybe vehet - nem lesz elerheto.

Ez bizony szivas (vs SQL, ahol ez egy darab update).

Viszont ha varhatoan ez egy ritka muvelet, akkor mar nem is akkora szivas.

"ha valtozik, akkor vegig kell nyalazni az osszes erintett rekordot/dokumentumot, es frissiteni."

Ezért van az a design pattern, hogy nem módosítod az adott sort, hanem új sort írsz frissebb timestamp-el. Olvasni meg timestamp alapján mindig a legutolsót olvasod, ez gyors és "olcsó". Az UPDATE és a DELETE mindig "költséges" egy elosztott környezetben, az INSERT és SELECT olcsó.

Mi a kulonbseg a MongoDB INSERT es UPDATE kozott ebbol a szempontbol? Ugyanugy lockolni kell az egesz adatbazist, ugyanugy kell egy olvasas es egy iras, ugyanugy kell replikalni az adatbazist utana.

"Mi a kulonbseg a MongoDB INSERT es UPDATE kozott ebbol a szempontbol?"

MongoDB esetén semmi, mert mind a kettő művelet fájdalmas.

Cassandra esetén sincs semmi különbség, mert ott az INSERT és az UPDATE mechanizmusa ugyanaz: az INSERT tud adatot frissíteni, az UPDATE pedig új sort beszúrni. Az INSERT IF NOT EXISTS (= valódi INSERT) már fájdalmas művelet, el is szokták kerülni, helyette mindig inkább egy új kompozit kulcsot hoznak létre.

Például Cassandra esetén ez lehet a (messageId,timeuuid), így ha valaki szerkeszt egy üzenetet, akkor ugyanazzal a messageId-val, de egy új timeuuid-vel kerül letárolásra a módosított üzenet, lekérdezni pedig olcsó az utolsó timeuuid szerint, vagy ha kevés szerkesztés van, akkor mindent a messageId alapján és a felsőbb réteg a legutolsó timeuuid szerinti sort választja, mint friss.

Érdemes jól ismerni az adott NoSQL rendszert, mert nem ugyanaz a működésmódjuk, másra alkalmasak a specializációjuk miatt, nem jó az a megközelítés, hogy mindenre egy adott (megtanult) NoSQL-t használjuk...

Itt most megint egy ugyanolyan példát próbálsz ráhúzni, ami egy rossz megoldás NoSQL alatt is.

Itt egy jó megoldás NoSql-ben és hasonlóan RDBMS-ben, csak ott kicsit több táblában:
- A vevő adatait, mint szállítási és számlázási adatok, természetesen eltároljuk minden rendelésnél és ha változik a vevő címe, akkor SEHOL SEM módosítjuk.
- A rendeléshez letároljuk a vevő azonosítóját is. Ha változik a vevő elérése, akkor az alapján elérhető az adott vevő (az aktuális címe, telefonszáma, ...).

Tehat megiscsak normalizalsz NoSQL-ben, illetve joinolsz?
Es ha van egy olyan reportod, amiben szeretned latni a vevo cimet is? Ebben az esetben nem pont a lenyeg veszik el (1 lekerdezes = 1 query, join nelkul)?

Nem kotozkodom, tenyleg erdekel.

(Most alapvetően a Dokumentum tárolású NoSQL-ekről beszélünk, a key-valu és graph alapú teljesen más.)

Itt is szükség van normalizálásra. Természetesen át kell gondolni, hogy mit célszerű külön rakni és mit nem.
Ahol egy-egy vagy egy-sok kapcsolat van általában ott jöhet szóba, de ott se mindenhol, ugye nagyon függ a "sok" mennyiségétől.

Itt megint az a problema hogy ugy gondolsz a noSql jellegu megoldasra mint amit egy az egyben replacement jelleggel bedobsz egy relational model helyere, pedig ez nem igy van. Azert hivjak a (bizonyos) noSql megoldasokat aggregate store-oknak is masneven (ddd) mert egy aggregate az egy "consistency boundary" minek amivel konzisztensnek kell lennie az bennevan ebben a boundaryben (keyben, documentben), nem lehet olyan amivel konzisztensnek kell lennie es nincs benne, ha van, akkor benne kellene lennie, es maga a design rossz, amin valtoztatni kell. Egy rosz, nem illeszkedo designra nem tudsz jol mukodo rendszert csinalni, semmilyen technologia megoldas, legyen az noSql vagy barmi egyeb nem fogja megoldani az ilyen jellegu problemaidat. Semmilyen technologiai megoldas nem "silver bullet", es nem alkalmazhato mindenre. (Szoval igen, nem kell joinolni)
Azonban ravilagitottal az egyik tipikusan felhozott dologra ami szinte tankonyvbe illo mikor noSql megoldasokat (foleg key) magyaraznak el, es ez az hogy ezek a megoldasok tipikusan nem tamogatjak azt hogy konnyeden atrstukturald az adatokat olyan formara amilyenre szeretned allandoan. Gondolok it reportingra. Ezert szokott reporting celokra vagy parhuzamosan lenni egy relacios model is (mivel igazan forgalmas helyen live dbt azert nem live reportolunk), vagy van valamilyen asszikron process a hatterben ami ezeket meggyotri es kiszedi beloluk naponta egyszer mondjuk azt ami reportinghoz kell. Mig altalnossagban egy relacios model kicsit univerzalisabb es kepes ellatni sokfele funkciot valtozo eredmenyesseggel es teljesitmennyel, addig tipikusn a noSql megoldasok joval specializalodottabbak es egy szukebb felhasznalasi korben nyujtanak sokkal jobb teljesitmenyt mig mas celokra kenyelmetlen a hasznalatuk. megintcsak, attol fugg mire van szukseged.
Egyszeruen a gondolkodasmod teljesen mas.

Kosz a tippet az aggregate-tal kapcsolatban, mar nyalazom is a szakirodalmat :)
https://vaughnvernon.co/?p=838

"Evek hosszu soran at vertek a fejunkbe, hogy ugyanazt az adatot egynel tobbszor letarolni rossz, mert nem valtozik egyutt az adat osszes peldanya."

Na, ezt kell elfelejteni és minden világos lesz. :)

Tipikus példa az, amikor több címzettnek kell üzenetet írni. Az RDBMS világban erre két külön táblát használnál, egy message(id,fromId,timestamp,text) és egy messages(toId,messageId) táblát. Amikor létrehozol egy üzenetet, akkor egyszer beleteszed a message táblába és címzettek szerint egy-egy sort a messages táblában. Ha módosítod, akkor egyszer módosítod.

message(1,1,9:45,'valami')
messages(2,1)
messages(3,1)
messages(4,1)
message(1,1,9:46,'mégvalami')

NoSQL világban egy tábla van: messages(toId,id,timestamp,fromId,text) és amikor létrehozol egy üzenetet, akkor azt bizony annyiszor letárolod. Ha módosítod, akkor bizony annyiszor _újra_ letárolod.

messages(2,1,9:45,1,'valami')
messages(3,1,9:45,1,'valami')
messages(4,1,9:45,1,'valami')
messages(2,1,9:46,1,'mégvalami')
messages(3,1,9:46,1,'mégvalami')
messages(4,1,9:46,1,'mégvalami')

Szóval ez ilyen.

hehe, pont most gondolom ujra a clapf message history-jat (rdbms-ben), es az 1. peldad adta magat. De aztan egyeb szempontok miatt megis az ahany cimzett, annyi (majdnem ugyanolyan) bejegyzes lesz a nyero (2. peldad). Meg azon gondolkozom, hogy (ha megis nosql lesz belole, akkor) melyik nosql megoldas legyen az. Napi 1 millio emaillel szamolva mondjuk 30 millio rekordot kell tudni tarolni

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

"Napi 1 millio emaillel szamolva mondjuk 30 millio rekordot kell tudni tarolni"

Divatos dolog a NoSQL, viszont 30 millió adatra overkill...

Nagy vonalakban három use-case esetén érdemes használni:
- nagyon nagy mennyiségű idősoros adatnál (több milliárd sor, folyamatosan írod, csak egyes időszeleteket olvasol)
- potenciálisan váratlan növekedés van kilátásban (startup -> beválik az ötlet -> holnaptól egymillió felhasználód van)
- több tucat TB adat esetén (elosztott adattárolás)

A minimális node szám általában három, bármelyik NoSQL-t nézzük... egy node nem node, kettő node még kevés a megfelelő konzisztenciához (quorum). Több kisebb node jobb, mint kevesebb nagyobb.

nyilván túlegyszerűsítem, de akkor lehet az egy jó megközelítés, hogy egyszerűen sok erőforrásba kerül a relációs modell miatti join-olgatás, és nehéz fenntartani a konzisztenciát, ezért nem baj ha sok adat jön létre, mert így viszont egy helyen van az adat, ami adott esetben kellhet?

(csak tapogatózom, de a fentiekből és kis előzetes okulásból nekem ez jött le, ahogy látom a nosql egy skálázási megoldás, de gyakorlatilag természeténél fogva sokkal kevésbé rugalmas mint a relációs modell...viszont sebességben jobb, HA jól vannak az adatok letárolva: zero join, jól van normalizálva noSQL szemszögből is, ...)

Az teljesen igaz, hogy a MongoDB sebessége SELECT-eknél iszonyatosan gyors. Nekünk van egy 5 GB-os speciális DB-nk, amely a világ összes településeinek adatait tartalmazza, meg ehhez kapcsolódóan kismillió miegymást. Geonames a neve és letölthető. Na ebben Mysql szerveren egy lekérdezés 16 másodpercig futott. Ugyanez MongoDB-vel 0,016 másodpercig tartott! A DB "sosem" változik, csak ha új verzió jön belőle.

5 GB-nyi adatbazison 16 sec a query? Biztos minden koser volt a query ill. a mysql oldalon?

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Nem olyan régen futottam bele olyanba, hogy az egyik kollega egyik programja "lassú" volt, az adatbázisra várt főleg. Tettünk 1-2 indexet ide-oda, aztán begyorsult.

Aztán később más helyen megint volt valami lassulás. Ekkor egy másik kollega átnézte a query-ket, aztán az eredeti subselect-es, having-es query-t átírta, így lett a 8 másodperces futásból 0,04 sec, vagy valami ilyesmi.
Nem volt annyira "elegáns" a query, viszont nagyságrendekkel volt gyorsabb.

Ez persze nem 5 GB adatbázis volt, de 5 giga se akkora mennyiség, pláne ha csak olvasgatni kell, mert akkor simán elfér a memóriában is.

ja, az explain select ... jo talalmany

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Egyetertek a kollegakkal, a 16 sec az rengeteteg, valaki lusta volt adatbazist/queryt optimalizalni. Mivel ilyen szempontbol a noSQL-ben a kerdes sem letezik, igy egy alapvetoen rosszul osszerakott DB-t osszevetni a noSQL-lel szerintem nem fair az RDBMS-sel szemben.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

+1 kivéve ezt: "Mivel ilyen szempontbol a noSQL-ben a kerdes sem letezik,"

Ez a kérdés NoSql-ben is létezik, ott is vannak pl. index-ek, csak ott kis adatszerkezetek esetén esetleg kevésbé jön elő, mert alapvetően jobban cache-elt vagy mert eleve egyben tárolták azt, amit RDBMS-ben külön táblákban.

sub

Hat gyerekek, amikor megnyitottam a szavazast, a 2-es volt a velemenyem, de latva a kommenteket, kezd az elso lehetoseg fele csuszni, pedig a tobbseguk pont az ellenkezojet szeretne elerni (hibasan).

ez csak a te csolatasod/szegenysegi bizonyitvanyod...

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Én a 3.-ra szavaztam, de azt gondolom, hogy vannak feladatok, amikre inkább a 2. pont, és vannak, amikre inkább a 4. pont illik jobban.

Számomra a MongoDB egyik legnagyobb előnye, hogy OOP programoknál nem kell annyira megerőszakolni a tárolást (lásd impedance mismatch), hogy a használt objektumokat ide-oda kelljen alakítgatni.

Az impedance mismatch-ről itt és itt találsz leírást.

Köszi egyébként a témát, szerintem nagyon értékes hozzászólások születtek a témában.

+1

olvastam már párszor NoSQL témában, de szerintem ez a topic sikeresen összegyűjtötte az alap problémákat (relációs modellel kapcsolatban is :) ), nagyon jó kiinduló alap

Szerintem csodák nincsenek.

A NoSQL megoldások akkor teljesítenek jól, ha bizonyos feltételek teljesülnek, bizonyos dolgokról lemondunk (pl. ügyesen fába/fákba tudjuk rendezni az adatainkat vagy döntően primary kulcs alapján akarunk keresni.
Ha tranzakciókezelés kell vagy normalizálni akarunk, maradnak a jól bevált SQL szerverek.

SQL szerverrel is lehet clustert építeni: nem csak MySQL és PostgreSQL létezik. MSSQL-ben pl. három Next-Next varázslót kell végigkattintani, és kiválóan működik.

Fuszenecker_Róbert

+1 vegre valaki

> SQL szerverrel is lehet clustert építeni: nem csak MySQL és PostgreSQL létezik. MSSQL-ben pl. három Next-Next varázslót kell végigkattintani, és kiválóan működik.

+1

A többi részre is, ofc.

Ajánlott olvasmány: NewSQL.

Fuszenecker Róbert

No ez jo nagy szar teszt. Pont azt nem teszteltek, amiben a MondoDB kurva jo - a horizontalis skalazhatosagban.