MongoDB-vel vagy mas, hasonlo key-value tarolasi modot megvalosito dokumentum alapu es/vagy OO szemleletu DBMS-l volt valakinek dolga? Ha igen, mi es mik voltak a tapasztalatai vele?
- Rugalmassag?
- Megbizhatosag?
- Teljesitmeny?
- Platformfuggetlenseg?
- Tamogatottsag kulonbozo nyelvek/platformok reszerol?
- Valos eletben mennyire hasznalhato (es hol, ha nem titkos)?
- Es mire nem hasznalhato?
- Adminisztralas egyszerusege? (Mennyire macera adminisztralni, mennyire nehez egy admint atszoktatni ra, stb.)
- Uzletileg mennyire elfogadott a hasznalata?
- Userek korlatozhatosaga adatbazison belul? (Mennyire lehet tobb usert hostingolni egy szerveren)
- stb. random, ami hirtelen nem jutott eszembe.
Nem akartam flame topicba rakni, orulnek, ha on-topic keretek kozott maradna a dolog (tudom, naiv elkepzeles :).
- 2044 megtekintés
Hozzászólások
Én cassandrát használtam.
Rugalmas, megbízható, platfromfüggetlen.
Java, Python, PHP C/C++ api van hozzá.
Használható éles projektben, lásd facebook, twitter.
Semmilyen korlátozás nincs a szoftverben.
- A hozzászóláshoz be kell jelentkezni
Cassandra +1
- A hozzászóláshoz be kell jelentkezni
Irnal par sort, hogy mire es arra a feladatra milyen alternativakat lattal (ha talaltal/kerestel), ha lehet?
Es hogy mire nem ajanlanad?
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Ezek egyszerű dolgok. Javasolt egyszerű adatszerkezetek esetén, lásd FaceBook üzenőfal. Arra ideális, ha nem kell benne keresni mindenféle szempontok szerint.
Nem javasolt pl akkor, ha minden, vagy majdnem minden adatmeződben keresni szeretnél pl. fulltext search. Ezek kulcs-érték párokat tárolnak, és pl azt sem tudod megoldani velük, hogy olyan kérdésre választ kapj, hogy "melyek azok a rekordok, amelyek kulcsaiban szerepel a blabla kifejezés".
- A hozzászóláshoz be kell jelentkezni
A kérdésekre elég nagy regényeket lehet írni és nagyon sokmindentől függ. Mi a célod?
- A hozzászóláshoz be kell jelentkezni
Tegnap melo kozben vetodott fel, hogy de egyaltalan miert is szenvedunk azzal, hogy mindenfele osztalyhierarchiat megprobalunk raeroszakolni a relacios adatbazisokra. Nem erre talaltak ki azokat.
Alapvetoen, ha veszunk egy 3 retegu alkalmazast, es "szepen" csinaljuk meg, akkor ugy van:
- View
- Controller
- Modell
- DAO, DTO, ActiveRecord, stb.
- Relacios adatbazis
- Fizikai tarolo
Attol most tekintsunk el, hogy PHP-ben nem szoktam ennyire szetszeparalni a dolgokat, altalaban ami nalunk DAO, az egyben DTO is, meg valamennyire Active Record is. A mindent ezer retegre bontunk mokat meghagyom a J2EE-seknek.
Azon gondolkozok, hogy nem lehet-e ezt leegyszerusiteni ilyenre:
- View
- Controller
- Modell
- [adatbazis]
- Fizikai tarolo
Alapvetoen total felesleges az egesz osztalyhierarchiat attranszformalni egy relacios adatbazissa, sokkal celszerubbnek tunik valami OO szeru adatbazis (tisztaban vagyok azzal, hogy nem lehet mindent jol atrakni, pl. naplo szeru dolgokat). Lenyegeben durva kozelitessel magat az adatmodellt ugy szeretnem latni, ahogy van. Persze, valami indexeles kell a mezokre, kulonben egy listazas/szures a vilag vegeig is eltartana.
Igy elso ranezesre a MongoDB tunt a legidealisabbnak arra, amire nekunk kellene, de majd meg ugy is kutakodok a temaban. Csak gondoltam feldobok egy topicot ide, hatha okosodok belole valamit.
Mgj: azt latom, hogy a legtobb ilyen rendszer elgge celul tuzte ki magat, hogy a ket szomszedos galaxisra is felskalazodik, ez nekunk annyira nem szempont, leginkabb kis/kozepes meretu DB-k vannak, ugyviteli rendszer, webshop, dokumentum alapu dolgok, ilyenek.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
A topic még így is nagy, de megpróbálok néhány dolgot tömören kiemelni:
A key-value valamint a dokumentum alapú store (szerintem) kritikus része az indexelés és keresés kezelése (annak módosíthatósága és az index skálázása illetve konzisztensen tartása). A legegyszerűbb ha az adott termék ezzel nem foglalkozik (hashmap), de nagyon hamar jön egy olyan use-case, amikor ez mégiscsak kelleni fog. Aki meg foglalkozik vele, ott megjelenik egy eredendő komplexitás ami tüntethető el, csak különböző stratégiákkal más és más része hangsúlyozható. Ez ügyben elég rosszak a tapasztalataim, mi végül saját backend engine-t fejlesztünk.
A konzisztencia rovására mindig lehet teljesítményt és skálázódást nyerni (ezeknél a noSQL dolgoknál ez nem ritka), ha ezzel az alkalmazás meg tud bírkózni. A hagyományos adatbázisokhoz szokott fejlesztők tipikusan nem tudják ezt egyszerűen megemészteni, ez egy hosszú tanulási folyamat, ami nagyon hamar belevezethet egy olyan spirálba, hogy "dobjuk ki az egészet, mert nem olyan mint az SQL". Szóval én csak akkor kezdenék bele a helyetekben, ha :
1. van olyan feladat, amelyet SQL-ben nehéz vagy nem skálázódó dolog megoldani és mindenképpen ilyen megoldást kell keresnetek
2. nincs rajtatok delivery nyomás, ami miatt esetleg a türelmetlenség előretör (és van jó architekt, aki az SQL-idegen megközelítéseket tudja kezelni)
- A hozzászóláshoz be kell jelentkezni
Igazabol remeltem is, hogy szep nagy topic lesz, de ugy nez ki nem haraptak ra a nepek :)
Ami szamunkra fontos lenne:
- Fejlesztesi ido csokkentese es a fejlesztes egyszerusitese: kevesebb reteg; osztalyhierarchia<->relacios adatbazis toszojgatas elhagyasa, stb.
- Eros konzisztencia, de kis meretekben gondolkodva (nem hiszem, hogy a legtobb helyen, ahol hasznalnank, egyaltalan felmerulne az, hogy egy atlagos vason ne futna el az alkalmazas es a DB egyutt.
A skalazodas szamunkra masodlagos szempontnak szamit nalunk. Nem egy uj Facebookot/Twittert akarunk inditani.
Tovabba az is konnyen elofordulhat, hogy foldrajzilag egymastol tavolabbi helyen kell szinkronban tartani az adatokat (legyen mondjuk a maximum Magyarorszag ket tetszoleges pontja kozott, de valoszinuleg a tipikus az egy varoson beluli tobb helyi telephely).
Viszont eddig altalaban olyan igenyek merultek fel, ahol az adatok elkulonitheto reszet szerkesztettek az adott helyen, csak szukseges volt a masik adataiba valo belelatas.
Mi is gondolkoztunk azon, hogy hogyan lehetne egy nekunk megfelelo(nek tuno) rendszert epiteni. Mi arra jutottunk, hogy alapvetoen egy olyan DBMS-t lenne celszeru osszehoznunk, ami nem csinal mast, mint objektumokat tarol memoriaban (persze, ez csak a latszat, valojaban transzparensen toltene be diskrol azt, ami nincs a ramban) + az adott propertyk alapjan lancolt listak, BST-k es/vagy B fak fenntartasa indexeknek a kereseshez/listazashoz.
Tarolas/lehivas/betoltes meg gyakorlatilag egy objektum atadasa a kliensnek/szervernek. Ami meg megoldando problema az a megosztott objektum-referenciak hasznalata, de arra meg lehet megoldas, hogy valamilyen GUID szeruseggel azonositjuk az objektumokat.
Mondjuk ezen csak elmelkedtunk, ezert gondoltam, hogy mas noSQL jellegu megoldasnal mi a helyzet.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
A konzisztenciához kis mértéknél sem kell feltétlen ragaszkodni, meglepően jó dolgok jönnek ki egy kicsit lazább felfogású rendszer esetén :)
A fejlesztési idő csökkenését csak az adatkezelési réteg lecserélésétől kár várni, mivel egy csomó esetben más UI logikát célszerű implementálni egy relációs és egy dokumentum alapú vagy éppen egyéb alternatív adatbázishoz, és mint mondtam, van egy beleszokási idő is...
A ti problémátokra elsősorban group messaging + separated storage megoldás tűnik elsőre jobbnak, in-memory gráf adatbázisokból még nem láttam igazán jól működőt (igaz nem is nagyon néztem, nem hiszek abban, hogy a feladat komplexitását jól meg tudják oldani).
- A hozzászóláshoz be kell jelentkezni
Konzisztencia dolgot kifejtened, hogy miert gondolod/mik a tapasztalataid? Es a group messaging + separated storagerol tudnal adni valamit, hogy merre keresgeljek?
UI logikank meg igazabol erosen kotodik az adatkezelesi retegunkhoz. Mint irtam, mi altalaban minden tovabbi nelkul atadunk egy nezetnek egy DAO-t, nem szenvedunk azzal, hogy kulonvalasszuk a kettot, megha nem is a leg szebb megoldas. a View meg kibanyassza/hasznalja a megfelelo gettereket.
Igazabol nagyon sokszor olyanunk van, hogy az adatosztaly megfelelo getterei hozza vannak bindelve az urlapok megfelelo mezoihez. Az egesz alternativ adatkezelesi megoldas onnan jott, hogy most vagyunk lassan tul az egyik projektunkben az egyik modul egy jelentos atirasan (gyk. from scratch, mert megrendelo kitalalta, hogy majdnem minden adatmezohoz akar elozmenyeket/kommentet/ervenyessegi idot es olyan lekerdezest, hogy barmikor vissza tudja nezni, hogy az adatbazis hogy nezett ki x idovel ezelott). Itt futottunk bele abba, hogy szenvedunk azzal, hogy beleturjuk a relacios adatbazis 50+ uj tablajaba szetvallogatva az adatokat, ahelyett, hogy inkabb fogtunk volna egy objektumot es ugy ahogy van, elmentenenk.
Programozoi oldalrol ugy is csak annyi latszik, hogy az adott adatosztalyra meg lett hivva a save() metodus. Aztan alatta van a a mindenfele adatturas. Hogy is mondjam. Fajt, mire a kb. tobb meganyi generalt kodot kidebuggoltuk. Es akkor mi lett volna, ha meg nem ugy indultunk volna neki, hogy generaljuk az adatosztalyokat es az UI-t. (Szerencsere egy semat ra lehetett huzni az esetek 95%-ara).
Lekerdezes resze meg ugy is olyan, hogy annyira sok tablara van szetvagva az adat, hogy jobban megeri PHP-bol vallogatni/helyere rendezni az adatokat, mintha SQL-ben kerdezgetnenk le.
Itt ereztuk azt, hogy komplexebb dolgokra nem biztos, hogy az SQL a jobb nekunk.
(Egyebkent nem allitom, hogy nem lehetne jobb adatszerkezetet kitalalni ennek, viszont ez tunt akkor a leglogikusabbnak es tarhelykimelobbnek).
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Konzisztencia: a nagyok (Google, Yahoo, Amazon...) alapelve, hogy mindig a legkisebb szükséges konzisztenciát kell biztosítani. Azaz hogy egy könnyen emészthető példát mondjak, nem feltétlen érdemes tranzakciókat használni mindig mindenhol, pláne nem 2-, 3-, 4-, .... sok-fázisú kommit protokollokat, mert csak feleslegesen növeli a latency-t (a 10-fázisú kommit protokoll is elhasalhat az utolsó lépésben lévő kommunikáció kiesése miatt), miközben néhány soros kb. nulla igényű programkóddal ugyanúgy le lehet kezelni az esetek _egy_ _nagy_ _részét_.
Keresgélés: fogalmam sincs hogy milyen technológiákban gondolkodtok. A Java világból a Hazelcast-ot tudom javasolni.
Amivel szívtok: bődületes hekkelésnek tűnik, sok sikert a sok szívás csökkentéséhez. Mindenesetre az tény, hogy egy dokumentum-adatbázis, esetleg egy XML-alapú storage jót tenne nektek.
- A hozzászóláshoz be kell jelentkezni
"bődületes hekkelésnek tűnik"
Annyira nem vészes. Lényeg, hogy van a főtábla, ahonnan egy mező mutat a kapcsolt tábla elsődleges kulcsára. A kapcsolt táblában meg van maga az adatmező(k), comment mező hozzá (miért lett módosítva), ki/mikor hozta létre a módosítást, mikortól érvényes az adat, stb. Valamint egy hivatkozás az előző bejegyzésre.
Alapvetően egy left join a főtáblától a kapcsolt adathoz, valamint a kapcsolt adathoz hozzá lehet csapni az előző mezőt, ami így szép lassú, de legalább működik és emberi időn belül megvolt (generálva lett az egész hóbelevlanc, és alapvetően egy sémát követ minden).
Bár tény, hogy nem feltétlen a legszebb, de mi ezt találtuk esetünkben a legjobbnak.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Ha még nem használtál ilyesmit éles környezetben, javaslom, hogy keress meg egy szakembert.
Sok-sok szívást lehet elkerülni 2-3 óra konzultációval. Tényleg.
- A hozzászóláshoz be kell jelentkezni
Ez a tanács az élet elég sok területére igaz :)
- A hozzászóláshoz be kell jelentkezni
Én is nézegettem mostanában a MongoDB-t. Nem nagyon mélyedtem el benne, de a relációs adatbázisok után eléggé más világnak tűnik. (ld.: mennyire nehez egy admint atszoktatni ra)
- A hozzászóláshoz be kell jelentkezni
/off/
Ugy olvastam "Mango".. (parnak leeshet)
/off/
- A hozzászóláshoz be kell jelentkezni