baza MongoDB a bazy relacyjne Opcje

[wiewiorek]

Do tej pory używałem relacyjnych baz danych, niedawno wielce się zdziwiłem gdy spotkałem się z nosqlową bazą danych MongoDB. Ktoś tego używał i ma porównanie jakie to ma wady i zalety w porównaniu do relacyjnych baz danych? Chyba wszystkie duże serwisy są oparte o bazy relacyjne więc to MongoDB jest wykorzystywane tylko w małych serwisach czy jak to wygląda?

[alegorn]

crm - tak, ale to idzie bardziej w intranet niz internet. to nie to samo.
e-commerce -tak, zgoda, lepiej będzie to zrobić w sqlowych bazach, tyle że nadużyciem jest chyba stwierdzenie że nie da się tego zrobić na nosql
przykład pierwszy z brzegu:
http://spf13.com/post/augmenting-rdbms-wit...-for-e-commerce

czas realizacji zapytania... hmmm... przy prostych, małych bazach - różnice nie są odczuwalne.
ale jeśli mowa o dużych bazach (czyli wielomilionowych) z mojej perspektywy nosql wygrywa. (odczuwalne juz tak powyżej 1kk)

tyle że tak naprawdę, w ilu przypadkach jest to nam potrzebne? do prowadzenia bloga? do strony firmowej? do stron wizytówkowych ? do wszelkiej maści prostych for? komentarzy ?

Zależy na ile poważnie traktujesz swoje aplikacje. Do prowadzenia strony firmowej nie potrzeba nawet strony server side.

nie rozumiem argumentu.

tyle że specyfika funkcjonowania tegoż interfejsu sprawia że sqlowe bazy się nie sprawdzają.

Jakieś przesłanki, ku temu, że się nie sprawdzają? Duże serwisy nadal z nich korzystają - to, że na devblogu napiszą o nowej bazie nie znaczy, że tylko jej używają - po prostu to teraz modne.

e, mądrze waść prawisz, ale tu trochę przesadzasz.
link:
http://www.mongodb.org/display/DOCS/Production+Deployments a to tylko dla samego mongo.czytając opisy, dlaczego zdecydowano się na nosql - trudno nie zauważyć pewnych trendów.
myślę że słowa o tym iż używa się nosql tylko i wyłącznie dlatego że jest modny - są na wyrost. poczytaj dlaczego souceforge przeszło na nosql.

nie twierdzę że nosql to lekarstwo na wszelkie bolączki. wydaje mi się że jest to tak naprawdę początek rewolucji, dajmy tym bazom tak jeszcze parę lat - a z pewnością następne pokolenia programistów, będzie się dziwić, jak można było pisać aplikacje www inaczej niż w nosql...

dlaczego? gdyż wg mnie - te bazy powstały z powodu niewydolności i ograniczeń sql.
dlatego ze nosql jest dedykowany potrzebom jakie niesie internet.

oracl... tak. ale to jest nie opłacalne.
owszem da sie zabić komara strzelając z armaty. tak, jest to w 100% skuteczne. jednak kogo jednak na to stać ?

j.

[solificati]

crm - tak, ale to idzie bardziej w intranet niz internet. to nie to samo.
e-commerce -tak, zgoda, lepiej będzie to zrobić w sqlowych bazach, tyle że nadużyciem jest chyba stwierdzenie że nie da się tego zrobić na nosql
przykład pierwszy z brzegu:
http://spf13.com/post/augmenting-rdbms-wit...-for-e-commerce

Nosql ma na pewno zaletę w sklepach internetowych - produkty bardziej odpowiadają dokumentom niż wierszom - telefony mają inne cechy niż koszulki i faktycznie lepiej to przeszukiwać w Mongo/Couch niż w MySQL. Ale pisanie twardej logiki dla Mongo to nie jest dobry pomysł. Pewne dane w systemie e-commerce muszą mieć zapewnioną trwałość i integralność. Jak nam się nie wyświetli w wynikach wyszukiwania książka to mała strata - gorzej jak zgubimy zamówienie.

czas realizacji zapytania... hmmm... przy prostych, małych bazach - różnice nie są odczuwalne.
ale jeśli mowa o dużych bazach (czyli wielomilionowych) z mojej perspektywy nosql wygrywa. (odczuwalne juz tak powyżej 1kk)

Zależy od tylu czynników, że szkoda gadać. Jaki nosql? Redis owszem jest strasznie szybki a operacje na Cassandrze potrafią zadziwić wielu fanów Oracle/Olap. Ale jakby porównywać tylko jedną bazę danych do sqla i odwzorować w niej funkcjonalność to już nie jest tak kolorowo. SQL i optymalizatory zapytań oraz techniki organizacji danych to lata doświadczeń świetnych inżynierów. To działa w ogólności szybko.

e, mądrze waść prawisz, ale tu trochę przesadzasz.
link:
http://www.mongodb.org/display/DOCS/Production+Deployments a to tylko dla samego mongo.czytając opisy, dlaczego zdecydowano się na nosql - trudno nie zauważyć pewnych trendów.
myślę że słowa o tym iż używa się nosql tylko i wyłącznie dlatego że jest modny - są na wyrost. poczytaj dlaczego souceforge przeszło na nosql.

Ale widzisz, tam w opisach jest wyraźnie, że w większości wypadków mongo jest którymś z kolei systemem przechowywania danych. Nosql nie zastępuje. Jest obok.

nie twierdzę że nosql to lekarstwo na wszelkie bolączki. wydaje mi się że jest to tak naprawdę początek rewolucji, dajmy tym bazom tak jeszcze parę lat - a z pewnością następne pokolenia programistów, będzie się dziwić, jak można było pisać aplikacje www inaczej niż w nosql...

dlaczego? gdyż wg mnie - te bazy powstały z powodu niewydolności i ograniczeń sql.
dlatego ze nosql jest dedykowany potrzebom jakie niesie internet.

Ale nosql istnieje dłużej niż sql! Nierelacyjna baza danych musi rozwiązać problem referencyjnej integralności. To jest problem po stokroć większy niż nowe-lepsze-szybsze mechanizmy trzymania danych. Zauważ, że nosqlowe bazy danych, które są już długo na rynku by rozwiązywać konkretne problemy i są adoptowane przez duże firmy nie idą w kierunku zastępowania funkcjonalności rdbms. Mongo nie jest jakimś wyznacznikiem tutaj - nie wyróżnia się na tle innych, nieco starszych rozwiązań.


W czasach, gdy backend nie jest homogeniczny, gdzie mamy aplikacje w czterech językach komunikujące się poprzez brokery albo protokoły binarne nierozsądnym byłoby upierać się za rozwiązaniem, które rozwiązuje jeden z wielu problemów. RDBMS rozwiązuje wiele problemów. Rozsądnym jest dołożyć rozwiązania by zmaksymalizować zyski a nie wyrzucać większą część rozwiązań.