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?

Bazy nierelacyjne używa się zazwyczaj do przechowywania danych tymczasowych.
Takie wsparcie dla relacyjnych baz danych.

hm......... chyba nie o to chodzi - bo ja widziałem cały serwis oparty o MongoDB, poza tym tam zapytania w ogóle nie przypominają zapytań sql'owych.

Może to nie odpowiedz na pytanie no ale taki teścik
http://www.progresowi.pl/2011/11/10/porown...vs-mongodb.html

Mimo ,że nirelacyjne bazy danych są szybsze(cechują się szybkością ,szczególnie te oparte o pamięć np.REDS), to uważam że są mniej funkcjonalne od relacyjnych baz danych, w których mozemy wykonać szereg dodatkowych "zadań" takich jak triggery,procedury składowane,shedulery,full text search itp.Dodoatkowo zobacz typy danych ,które relacyjne bazy danych obojętnie jakiej ,są zdolne obsłużyć ,a typy danych, które obsługują relacyjne(przeważnie ,są to text lub binary więc wymagane jest częstsze rzutowanie danych w projekcie).
Dlatego też uważam ,że relacyjne bazy danych raczej nie nadają się do dużych projektów jak główny kontener danych,lecz że względu na szybkość mogą nadać się doskonale jako kontener danych tymczasowych,jako druga linia, która odciąży naszą relacyjną bazę danych.

IMHO pakowanie logiki biznesowej do bazy danych to syf. Co najzwyżej jako optymalizacja niskiego poziomu.


Relacyjne, czy nierelacyjne? Zresztą obie są używane w dużych projektach, więc...

Podstawowa zaletą i wadą baz nosql jest ich nierelacyjność. Czyli wszystko zależy od potrzeb. Na przykład w zastosowaniach typu EAV (atrybuty produktu, karta pacjenta itp) relacyjna baza danych jest bardzo upierdliwa. Natomiast wadą jest brak relacji

A spróbowałeś chociaż wyszukać takie ogólnego porównania RDBMS vs NOSQL? Bo wpisów i artykułów w sieci na ten temat jest dosyć sporo.

Bazy noSQL to szeroki temat, nie ma tam jednego podejscia. Mają różne zastosowania i są alternatywą dla rdbmsa tam gdzie on sobie nie radzi. Można używać przecież wielu baz danych w jednym projekcie - zresztą dużo projektów tak robi.

Są bazy trzymające dane głównie w pamięci ram jak memcache albo redis. Redis jest wyjątkowy bo ma ciekawe struktury danych - ich wybór jest podyktowany ich szybkością, więc może nie ma wszystkich, które by się chciało mieć, ale te co są - są szybkie.
Są bazy nastawione na replikację danych jak CouchDB. Replikacja jest szybsza i pewniejsza niż w rdbms. Do tego CouchDB może trzymać w sobie aplikacje-strony (couchapp). Świetne jest to, że wystarczy zreplikować by zdeployować na nowych klientów (nawet klientów mobilnych) albo zupdateować dane by zupdateować aplikacje.
Są bazy zbudowane wokól fault tolerance jak Riak - można konfigurować bazę według CAP Theorem - wolimy rozproszenie, pewność czy dostępność.
Są ogólnie bazy nastawione na trzymanie dokumentów - też coś z czym rdbmsy sobie nie radzą a skoro indeksy wyszukiwania tworzy się osobno to czemu nie indeksować luźnych struktur.
Są bazy nastawione na workloady typowo zapisujące dane jak Cassandra. Gdy musisz więcej danych zapisywać niż czytać w aplikacji - bardzo przydatne w aplikacjach czasu rzeczywistego gdy interesuje nas tylko część ostatnich danych, ale ogólnie nie możemy sobie pozwolić na przestoje w logowaniu.
Są bazy danych grafowe jak Neo4j. Tam są bardziej zaawansowane "relacje" niż w rdbmsach i pod to są optymalizowane zapytania.
Są bazy danych przygotowane na duże ilości danych do przetwarzania wsadowego jak HBase czy wylęgający się Datomic. W takich zastosowaniach czystość SQL jest takim ograniczeniem jak Obiektowe programowanie w obliczeniach.

Jeśli chcesz spróbować innej bazy danych to może redis: świetny artykuł opisujący może nie działanie ale jak coś uruchomić szybko i przyjemnie: http://antirez.com/post/take-advantage-of-...your-stack.html

Jak chcesz się bardziej zagłębić to polecam CouchDB (Mongo dla mnie jest za blisko rdbms). Daje dużo nowego, wystawia na document store i map/reduce, czyli kluczowe idee, daje replikacje out of the box a nie zmusza do ogromnych konfiguracji jak Riak/Cassandra albo niezłej maszyny jak Datomic/HBase.

hmm. czytając cześć postów, mam wrażenie ze chyba większość tak naprawdę nie wie co to jest i czym to sie je.
mongodb jest baza danych zorientowana na dokument.
jest także bazą danych pisaną dla potrzeb internetu (stron www)

prosty przykład :

mam usera, i mam do niego `n` nr telefonu (do domu, do pracy tel kom itd.)

w mysql jedynym wyjściem jest trzymanie tego w dwu tabelach `user` oraz `telefon`
w mongo ? w mongo masz to wszystko w jednej tabel( a właściwie kolekcji)i, najzwyczajniej w świecie definiujesz pole telefon jako tablice i wpisujesz wszystkie nr.

w mongo nie można projektować baz wg zasad relacyjnych, w sposób jaki nauczyliśmy się dla baz sql'owych. to nie jest dobrym pomysłem.
wymaga to zrozumienia specyfiki bazy, tego w jaki sposób dane są przechowywane i reprezentowane.
jeśli to zrozumiesz - zrozumiesz także, że jest to baza pisana z myślą o stronach internetowych (czego nie można powiedzieć o żadnej bazie sql !)

trzeba pamiętać że przechowywanie danych jest w formacie BSON, cały interfejs jest zbudowany obiektowo więc jest łatwiej. (i trudniej )


ograniczeniem pewnym jest to że mongo lubi dobry hardware & soft.

nie ma co myśleć o poważnej zabawie na innym OS niż 64.
Jeśli masz duże bazy danych - to zje tyle ramu ile mu przydzielisz, i będzie z apetytem patrzył na pozostały.
w pewnych specyficznych przypadkach okazuje się że wymaga dopracowania (ilość wypychanych danych, offset itp).
w zamian daje niesamowite możliwości replikacji
masz także wbudowane możliwości map reduce (odpowiednik group by i funkcji agregujących)

sumując po kilku miesięcznej zabawie z mongo - stwierdzam że świetny soft.
kolejny wniosek - jeśli będę stawiał strony internetowe zorientowane na treść, jest to właściwy wybór.
jeśli muszę pracować na dużych bazach (wielomilionowych rekordach) - jest to najprawdopodobniej dobra decyzja (lub bardzo dobra)

oczywiście jest to rozwijany i dość młody projekt/produkt w porównaniu do mysql'a czy postgre.

dobrym pytaniem jest : dlaczego powstały, i co z sobą wnoszą bazy nosqlowe ... dlaczego stwierdzono że sql jest niewystarczający dla dalszego rozwoju.


j.

Problem się zaczyna gdy potrzebujemy egzekwować zależności. Relacje pozwalają nam kontrolować dane, mamy dodatkowo contraints i triggery, które dbają o poprawność danych. Sam mechanizm relacyjny zapewnia w pewnym stopniu poprawność danych. Bazy dokumentów nic nie dają w tej kwestii.

Więc trzymanie danych użytkowników wymaganych do działania strony w bazach nosql nie jest dobrym pomysłem a emulowanie wszystkich własności rdbms w takim mongodb to bezsens.


Aplikacja internetowa to taka zwykła aplikacja, tylko ma inny interface. Jak najbardziej SQL jest do stron internetowych.

solificati:: wszystko zależy od przypadku. trudno jest pisać o 'jedynym słusznym' rozwiązaniu, bo dojdziemy niedługo do stwierdzeń typu 'moje rozwiązanie jest słuszne bo jest słuszniejsze od Twojego' co samo w sobie jest prawdą, ale nic nie wnosi do dyskusji.

zastanówmy się jednak nad tym co napisałeś



tak naprawdę w ilu przypadkach potrzebujesz tego typu sprawdzeń ?
kolejnym pytaniem jest, czy jest to tak naprawdę potrzebne, i czy koszt obsługi tego jest tego warty? (czas implementacji, czas realizacji zapytania)

oczywiście że nie twierdzę że sql to przeżytek i nie warto już tego stosować. to by było nadinterpretacją. jeśli jest wymagane wysokie bezpieczeństwo poprawności danych - to owszem bazy sql'owe pewnie są lepszym rozwiązaniem.
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 ?



i tak i nie.
owszem jest to aplikacja o takim a nie innym interfejsie - tutaj zgoda.
tyle że specyfika funkcjonowania tegoż interfejsu sprawia że sqlowe bazy się nie sprawdzają.


proste pytanie, ile razy, po wykonaniu serwisu, a zwłaszcza po jakimś czasie jego funkcjonowania usłyszałeś,
no ok, niby działa, ale dlaczego to tak wolno działa ?
lub: dlaczego do prostego wyświetlenia wszystkich komentarzy pod postem trzeba tyle czekać ?

po sprawdzeniu, i wykonaniu rachunku sumienia, dochodzimy do ściany - już bardziej nie da się zoptymalizować tego zapytania, tej tabeli, tej aplikacji... stwierdzamy : po prostu serwer nie wyrabia.. kup pan nową maszynę...

idę o zakład ze dla pewnej części problemów (nie napiszę że dla wszystkich) - da się wybrać odpowiednie rozwiązanie, właśnie w nosql.
dlatego, między innymi właśnie powstały te bazy. bo stwierdzono że SQL nie daje rady w internecie.

j.

edit:
chwila refleksji nad tym co napisalem.
tak naprawdę ostatnio pracuje na hybrydach (mongo + mysql a nie wykluczam i inne silniki). nie używam jednej bazy danych, jednego jedynego 'słusznego' softu czy maszyny... okazuje się że tworząc hybrydy baz sql i nosql - otrzymamy wydajną i bezpieczną aplikację.
że stosując rozdział dla serwerów aplikacyjnych i na serwery serwujące kontent - osiąga się większą wydajność na maszynie, da się obsłużyć większy ruch. że warto czasem olać uznane frameworki i napisać cos dedykowanego dla problemu....
okazuje się ze np samo przejście na silnik percony - daje wymierny efekt
tak naprawdę okazuje się że warto szukać nowych, innych rozwiązań... czasem stracisz tylko czas, ale często udaje się urwać kilka procent mocy, czasu.... a to sprawia - ze warto

W ilu przypadkach? Ilu na co? W aplikacjach e-commerce czy choćby crm (a to prosty sklep internetowy już jest) relacje są potrzebne. Jest ogromna różnica w komforcie pisania logiki biznesowej gdy mamy zagwarantowaną poprawność danych. Oszczędzamy na czasie implementacji. A czas realizacji zapytania? Jeśli w takiej aplikacji baza danych jest wąskim gardłem to robimy coś bardzo, bardzo źle.


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



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.


Ale wiesz jaki jest problem - że żadne rozwiązanie nosql nie rozwiązuje więcej problemów niż stary dobry oracle. MongoDB ma te dokumenty, ale z dużymi plikami radzi sobie gorzej niż rdbms. GridFS powoduje, że szlag trafia całe piękno replikacji MongoDB. Rozwiązania nosqlowe są rozwiązaniami problemów sql. Ale pojedynczych (niech będzie, że kilku) problemów, ale nie nawet większości.


Konkluzja jest taka - nosql świetnie uzupełnia w pewnych zastosowaniach rdbms. Tylko tyle i aż tyle. Relacyjne bazy nigdzie się nie wybierają - są i jeszcze troche będą standardem aplikacji internetowych.

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)



nie rozumiem argumentu.


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.

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.



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.


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.


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

hmm. chyba nie ma o czym dyskutować, dlatego ze w dużej części zgadzam się z twoimi wnioskami, a różnice chyba wynikają z innego podejścia do tematu.
osobiście także poważnie bym się zastanawiał nad postawieniem sklepu na nosql, - ale przynajmniej wiem(y) ze istnieje taka możliwość, znam(y) możliwości i ograniczenia tej technologii.

hmmm bazy nosqlowe starsze od sql ?
no chyba czegoś nie wiem, wg mej wiedzy historia tego zaczyna sie w okolicach 2000 ? może kilka lat wcześniej... jeśli wierzyć wiki http://en.wikipedia.org/wiki/NoSQL to jest to około 1998 rok.
zdaje sobie sprawę ze trzeba czasu by ta technologia okrzepła, ale tutaj także widać jakie molochy (facebook! google! amazon!)z tego korzystają... widać, ze firmy które maja kasę nawet na najlepszy sprzęt i soft szukają innych rozwiązań, stwierdziły ze dla dalszego ich rozwoju zwykły sql jest ślepą uliczka. (piszę o technologii, nie o teorii)

nie chodzi mi o to ze sql to przeżytek. najzwyczajniej w świecie, trzeba go wykorzystywać do tego został wymyślony, czyli odwzorowania relacji miedzy danymi.
i tutaj wszelkiego typu skomplikowane relacje, zależności, wyliczenia - zawsze z samej choćby definicji będą lepiej zorganizowane.

to tak, jakbyś nadal robił front-end oparty na tabelkach... dlatego ze działa, zostało to już wypróbowane, posiada spora historie...
to jednak nie było wymyślone w tym celu.

dla mnie, najzwyczajniej w świecie strona www - nie jest strukturą relacyjną danych. jest to struktura dokumentu (obiektu??).
w związku z powyższym, baza danych zorientowana w ten sposób będzie działać lepiej. być może jeszcze kwestia czasu dla dopracowania technologii. ale jak dla mnie jest to kierunek rozwoju.

tak naprawdę - trzeba znać ta technologie i nie bać się po nie sięgać, jeśli tylko ma to sens.
j.

PS pisząc sql mam na myśli relacyjne bazy danych
edit: pisząc o dacie noSQL chodzi mi o rozwój technologii, niekoniecznie samą teorię.

Heh,

Czegos takiego jak REDS nie ma - jest REDIS. Redis z Mongo ma niespecjalnie wiele wspolnego pozatym ze sa NoSQL. Redis to key-value store trzymany w pamieci, ktory jest narzedziem przewaznie sluzacym do cache'owania i wspoldzielenia pamieci pomiedzy wieloma maszynami. Natomiast MongoDB czy CouchDB to bazy danych, tyleze oparte na dokumentach.

Funkcjonalnosc bazy danych dobiera sie w zaleznosci od projektu lub specyfiki zastosowan. Bzdura jest relacyjne bazy danych nie nadaja sie do duzych projektow - jest ich wiele i dzialac zawsze beda - AFAIK Twitter korzysta z MySQLa bez problemow. NoSQL to wygoda - nie ma czegos takiego jak definiowanie struktur czy aktualizowanie tabeli, rowniez skalowanie to nieco bajka. Pozatym samo dobieranie sie do dokumentow jest zdecydowanie prostsze etc etc. NoSQL w wielu miejscach dostaly czkawki http://www.zopyx.com/blog/goodbye-mongodb jak i kilka innych jednak sie poprawiaja i wielu normalnych projektach sa swobodnie uzywalne.

Co do zadan - trzymanie logiki wewnatrz bazy danych to wiecej problemow niz korzysci. Po jakims czasie malokto sie orientuje w tym wszystkim co sie dzieje w DB. A full text-search mozna miec w Mongo.

Bo jak się nie wie co z czym to tak jest.Ja uważam np.T-SQL w MSSQL za świetną rzecz, rozwiązuje wiele problemów,które okazały by się trudne do rozwiązania w naturalnym języku programowania.I absolutnie nie zgodzę się z zacytowaną przez ze mnie wypowiedzią.Jeśli baza danych udostępnia narzędzia, które mogą ułatwić pracę i zaoszczędzić setki linii pisanego kodu to czego z nich nie korzystać.

Wątpię czy w MongoDB będziesz mógł zrzucić za jednym razem dane z całej htmlowej tabeli tak jak w niektórych relacyjnych bazach danych za pomocą procedury składowej,wątpię czy MongoDB ma wewnętrzne narzędzia jak np.Shedulded Job, raczej będziesz musiał puszczać Crona, aby po pewnym czasie odpalił skrypt i updatował konkretne dane. Nie wiem jak w takich bazach wygląda archiwizacja danych i wogóle czy takie coś w nich wykonasz. FULL TEXT SEARCH w MongDB?-no chyba ,że sphinxa zaprzegniesz. Co niektórzy na relacyjne bazy danych patrzą z pryzmatu MySQL, a są przecierz inne lepsze pod względem funkcjonalnym bazy danych.
Wydaje mi się, że nie należy patrzeć tylko na szybkość wykonywanych operacji i stwierdzić ta baza jest ok bo jest prędka, ale także co dana baza danych ma nam do zaoferowania.

to zależny od projektu.
dla mnie, w obecnych projektach jest nie do przyjęcia, jeśli nie dostane zwrotu w mniej niż 0,05 <= jest to wartość graniczna. dla baz relacyjnych - często jest to koszmar, dlatego trzeba stosować różne sztuczki i kruczki, które naprawdę niewiele mają wspólnego z normalizacją danych. po jakimś czasie człowiek się zaczyna zastanawiać gdzie w tym jest sens..
jeśli możesz sobie pozwolić na większe oczekiwanie - wtedy jest ok, ale nie zawsze jest to możliwe. ot, zależy od projektu.
dlatego też - szukam innych rozwiązań, i dlatego nosql.

co do wykorzystywaniu skryptów i mechanizmów w samej bazie danych - ja osobiście jestem za, sporo ułatwia, choć wymaga niezłej znajomości i dyscypliny (a przy rozpraszaniu na inne serwery często z tego robi się mały koszmar :/ )
kolejnym problemem jest wersjonowanie zmian, to także nie jest łatwym zagadnieniem, i czasem warto się zastanowić nad tym.

j.

Full-text search można mieć wszędzie i zewnętrzny program indeksujący będzie zwykle lepszy.
Co do logiki - przy dobrym opisie danych i deklaratywności DDL można osiągnąć ogromne korzyści. To coś jak silne typy danych - przy dużym projekcie strasznie opłacalne.



Abstrahując od sql vs nosql - takie podejście jest niebezpieczne. Jeśli robisz coś w jednej technologii i brakuje Ci wydajności i druga, podobna technologia daje Ci tą szybkość out of the box najczęściej oznacza, że była po prostu lepiej ustawiona - doraźnie to lepiej, ale już wracając do przykładu, może się okazać, że dla t<0,005 łatwiej będzie stuningować sql niż mongo ze względu na większe doświadczenie technologii i większe community a samo mongo będzie już pod ścianą.

Co do historii nosql - ten termin jest może całkiem świeży ale bazy inne niż relacyjne istniały już wcześniej. Szczególnie jak weźmiemy pod uwagę chwalone przez Ciebie szybkie bazy - operujące jak klasyczne k-v store. Tylko się to wtedy nosql nie nazywało bo nie było sql.

Widzę, że muszę interweniować bo tu niektórzy Panowie nie za bardzo rozumieją pojęcia bazy relacyjnej ;-)

Weźmy sobie jako prosty przykład bazę danych która ma dane o użytkownikach, podzieloną na kilka tabel: Użytkownik, Adresy użytkownika, Kupione produkty. Żeby takie coś zaprojektować w relacyjnej bazie danych muszę przechować dane mniej-więcej w takiej strukturze:

- Tabela "Użytkownik"
- Tabela "AdresyUżytkowników"
- Tabela "Produkty"
- Tabela "KupioneProdukty"

Teraz - jeśli wykonamy zapytanie: Zwróć mi wszystkie adresy użytkowników którzy kupili produkty o cenie wyższej niż 100zł. Co silnik bazy danych zrobi z takim zapytaniem?

1. Przeleci po całej tabeli "Produkty" i przefiltruje ją pod względem ceny i zwróci kolekcję produktów która ma kolumnę "Cena" > 100 zł.
2. Listę produktów z podzapytania numer 1, wykorzysta, żeby przelecieć po tabeli "KupioneProdukty" i będzie porównywać elementy kolumny "Identyfikator Produktu" i sprawdzać czy należy do zbioru szukanych danych następnie utworzy nową kolekcję i dla każdego pozytywnego wyniku porównania identyfikatorów produktu, wrzuci do tej kolekcji wartość kolumny "Identyfikator Użytkownika".
3. Kolekcję identyfikatorów użytkownika uzyskaną z podzapytania numer 2, wykorzysta aby przeskanować tabelę AdresyUżytkownika i będzie porównywać każdy wiersz tamtej tabeli i sprawdzać czy wartość kolumny identyfikator użytkownika należy do tego zbioru.
4. Utworzy nową kolekcję do której będzie wrzucać wszystkie wiersze które pomyślnie przejdą porównanie w kroku numer 3.

(faktyczny query plan jest ciut bardziej skomplikowany - to jest delikatne uproszczenie)

Żeby zrealizować takie zapytanie, wszystkie wiersze wszystkich tych tabel muszą znajdować się w "zasięgu" tego silnika bazy danych - w zasięgu znaczy, że musi mieć szybki dostęp do wszystkich tych wartości - więc albo dysk albo RAM. Tak się dzieję, ponieważ takie zapytania wymagają scanu po wszystkich dostępnych danych. To nie skaluję się dobrze/łatwo jeśli mamy miliony sprzedanych produktów, miliony użytkowników i miliony adresów (jak np. Amazon.com czy podobnych rozmiarów bazy danych).

W takich przypadkach jedna maszyna nie jest w stanie udźwignąć całość danych z rożnych względów - czy to pojemnościowych czy wydajnościowych. Wtedy stosuję się bazy danych NoSQL.

Bazy danych NoSQL przechowałyby te dane w inny sposób, zależnie od rodzaju bazy NoSql (jest ich mnóstwo - t.j grafowe, klucz/wartosc, dokumentowa, drzewiasta/hierarchiczna, itd..) i np. przechowałaby:



W tak ułożonych danych, nie ma zależności pomiędzy różnymi zestawami danych, dlatego, nie muszą one być natychmiastowo dostępne do zwrócenia wyniku zapytania: Zwróć mi listę wszystkich produktów kupionych przez użytkownika o nazwisku "Kowalski". Koszt jaki płaci się przy takiej strukturze danych to mocno ograniczona elastyczność zapytań. Żeby zwrócić wartość zapytania z wyżej podanego przykładu: "Adresy użytkowników którzy kupili produkty > 100zł", musimy własnoręcznie wykonać te wszystkie kroki podzapytania.

Co to nam daję? Daje to możliwość łatwego skalowania. Jak przechowujemy niezależne dane, to możemy zaprogramować farmę serwerów load-balancerów w taki sposób: Jeśli będzie zapytanie o użytkownia i ten użytkownik będzie miał nazwisko zaczynające się na literkę "K", to przekieruj to zapytanie to farmy serwerów znajdującej się w tu i tu. Jeśli będzie zapytanie o użytkownika o nazwisku zaczynającego się na "M" to przekieruj do serwerowni gdzieś indziej. I w taki sposób można bardzo łatwo odciążyć serwery i znieść potrzebę dostępu do całego zestawu danych na raz. Daję stabilność i fault-tolerance. Jeśli panie nam serwer z użytkownikami na literkę "J" to nam padnie tylko mała część danych, zapytania o "K", "G", "F" dalej będą działać poprawnie i będą zwracać poprawne i pełne wyniki.

Czego to nam nie daję? Nie daję nam elastyczności zapytań - możemy zadawać tylko takie zapytania do bazy danych jakie przewidzieliśmy podczas jej projektowania pod daną aplikację i pod dany przypadek (chyba, że chcemy, żeby nam zapytanie wykonywało się bardzo wolno). Nie daję nam łatwego sprawdzania konsystencji danych. Jasio Kowalski może mieć w swojej liście kupionych produktów produkt o nazwie "Nazwa produktu 2" który zmienił nazwę na "Nazwa Produktu 7". Żeby ten update odzwierciedlił się wszędzie, musimy ręcznie pozmieniać te wartości w zestawie użytkowników (przelecieć po zbiorze użytkowników i zobaczyć czy tam jest nasz szukany produkt i jeśli tak to zmienić jego nazwę).

Bazy NoSQL istnieją od bardzo dawna. Powstały dużo wcześniej niż relacyjne. Bardzo dobrym przykładem nierelacyjnej bazy danych jest wasz system plików - zapytania możecie zadawać tylko i wyłącznie podając ścieżkę do pliku. Inne typy zapytań są bardzo wolne (np szukanie plik po pliku).

NoSQL przydaję się zazwyczaj wtedy kiedy zwykła relacyjna baza danych nie wyrabia (powyżej kilka Terabyte).

Ten mały tekst jest chyba najważniejszy tutaj. Można go poprawić w kilku miejscach i należy pamiętać, że mając sztywne typy danych jest o wiele łatwiej implementować i optymalizować przeszukiwania.


I tak i nie. Jeśli weźmiemy generalny przypadek to może być ciężko, ale nie zawsze są nam potrzebne wszystkie dane. Z drugiej strony NoSQL nie rozwiązuje tutaj żadnego problemu, którego nie rozwiązuje rdbms. Dodajmy, że w prawdziwych zastosowaniach jak właśnie Amazon nikt nie trzyma w jednym obiekcie/wierszu towaru i ceny. Historia cen, ceny specjalne i tak dalej. Tutaj algebra relacyjna i integralność danych to ogromne ułatwienie. I tu jest pytanie jak chcemy skalować. Bo może lepiej mieć wielomilionową tabelę z kilkoma numerami na wiersz, które można analizować a opis na stronę pobierać z zewnętrznej bazy - sql pozwala na coś takiego - bo w nosql musielibyśmy dzielić całe obiekty i w momencie gdy chcemy produkty za $50 to musimy odpytać n serwerów.


Tak, mam nazwy produktów, ale już nie mam ścieżki do obrazka produktu. A jak dodamy ścieżki i ceny i aktualne rabaty to mamy ogromną nadmiarowość danych. A jak będe tutaj trzymał id produktu? Też, jak w rdbms, muszę odpytać drugą baze/tabelę, ale nie mam zagwarantowanej integralności danych. Jak anuluje zamówienie to usuwam id, ale jak zmienie cenę? W sekcji "Twój znajomy kupił też:" wyświetlę buty, ale żeby pobrać cenę muszę odpytać inną bazę. Żadnego zysku.



Problem jest w podziale danych na niezależne części. Technologie nie dają odpowiedzi na to a to nie jest trywialne zadanie. Jeśli jest zapytanie o przyjaciół Marcina, którzy są znajomymi Karola? NoSQL to nie jest żadna odpowiedź i musimy być świadomi co poświęcamy.



Zależy od bazy. Ale zakładając, że dalej się trzymamy baz typu dokumentowego to powiem, że racja. Co więcej - w sqlu istnieją techniki, które taką prędkość nam dadzą. Zmaterializowane widoki pozwalają tworzyć szybkie zapytania o skomplikowane relacje.
Sharding pozwala tak samo skalować bazy.
Polimorfizm wielotabelaryczny pozwala modelować zmienność rekordów.


Po raz kolejny dziwna estymacja. Rozmiar danych to jeden z wielu czynników.



Wiem, że to wygląda jakbym uważał, że sql to najlepsze co jest. Ale polecam mojego pierwszego posta w tym wątku - wymieniłem zalety baz nosql, których doświadczyłem sam w mojej pracy. Po prostu nie jestem zwolennikiem poglądu, że nosql jest odpowiedzią kompletną. To są rozwiązania budowane wokól jakieś (jednej!) idei lub bolączki rdbms.

Z drugiej strony data-mining dla rozwiązań nosql jeszcze raczkuje, więc spore możliwości pracy dla mnie.

Poprawisz?

Mój błąd. Przez poprawić go miałem na myśli poprawić plan zapytania.

To samo miałem na myśli Gdzie jest błąd w moim uproszczonym planu zapytania?

Och, jeszcze raz. Twój plan zapytania jest dobry, jeśli założymy, że dane są ot-tak wrzucone i odpalone zapytanie. Ale jeśli przygotujemy indeksy to zamiast jak to określać wyszukiwać po całej tabeli możemy mieć range scan, merge join i hash join. Możemy oczywiście potem dyskutować czy aby range scan jest najlepszym wyjściem ze względu na kardynalność zbioru cen (o ile faktycznie cene trzymamy przy produkcie - niezbyt dobry pomysł), nested loop join może być lepszy od hash, jeśli jednak liczebność jest po stronie adresów - ale należy zauważyć, że optymalizator załatwia dużą część tych spraw sam.

O ile w przypadku range scan to w niewielkim stopniu mozna zminimalizować konieczność dostepnosci wszystkich danych na raz na jednej maszynie, to pozostałe joiny wymagają pełnej dostepnosci całego zbioru. Co oznacza, ze nie możesz latwo rozproszyc ta bazę danych na kilka farm - rozproszyc, nie replikowac.

Wcale nie uważam, ze NoSql, jest rozwiązaniem na wszystkie problemy skalowalnosci. Ale jest pewna klasa zastosowań (szczególnie przy danych diagnostycznych lub zdarzeniowych) gdzie taki model bazy danych jest nie do zastąpienia.

Ale żaden nosql też tego nie daje. Znaczy daje tak samo jak rdbms - możliwe, ale o wiele wolniejsze.
Pewnie, można przygotować taki schemat dokumentu, że w trzech wypadkach zadziała szybciej, ale w pozostałych o wiele gorzej. A ja, w rdbms mam jeszcze narzędzie jakim są widoki zmaterializowane.
Scenariusze skalowania nosql są inne. Po prostu ten przykład ma silne relacje, więc to on się kiepsko skaluje a nie technologia.

Ja używam MSSQL i świetny T-SQL, jednakże ze względu na szybkoć samej bazy(jest jedna z wolniejszych baz) nie pcham do niej danych tymczasowych.Do tego celu używam z uniwersyteckiej technologii Turple Spaces.Początkowo myślałem ,że to nierelacyjna baza danych ze względu na sposób implementacji,zapisu do bazy danych(brak standardowych SQL-owych zapytań do bazy) i sposobu filtrowania danych,zapis do pamięci, jednakże się myliłem.Ja bym radził się przyglądnąć co niektórym technologiom- co relacyjne bazy danych potrafią , a raczej co z relacyjnymi bazami danych można jeszcze zrobić.Ja bym porównując Redis vs TurpleSpace wybrałbym to drugie choć sposób zapisu wydaje się być podobny (key-value(redis),key-values[Turple Spaces]).A szybkości mozna także pozazdrościć.

Technologię wybiera się pod projekt, nie projekt pod technologię kto czego używa to jego indywidualna sprawa i nie można jednoznacznie określić ,czy jedno rozwiązanie będzie lepsze od drugiego.

I tak i nie. Mniej-wiecej rok temu pracowałem nad Azure Table Storage, co jest baza NoSql. W ATS, masz coś takiego co się nazywa "partition key", co jest analogicznym odpowiednikiem pierwszej litery nazwiska w moim poprzednim przykładzie. I dzięki temu baza danych moze być rozproszona po całym centrum danych i po kilku centrach danych na świecie w sposób niewidoczny dla użytkownika. Wysylasz tylko zapytanie: "Daj mi rekordy gdzie partition key = a i row key= b" i algorytm bazy danych sam znajduje odpowiednie serwery które maja te dane.

I tu dochodzimy do sedna sprawy. NoSql jest używany wtedy kiedy masz bardzo określone i wąskie rodzaje zapytań które zwsze bedą zapisywać i odczytywać dane w ten sam sposób - w ten pod który baza została zaprojektowana.

Bazę relacyjna nie możesz podzielić na kilka maszyn, bo wtedy stracisz to co jest w niej najważniejsze - integralnosc relacji. Nie będziesz mógł mapować kolumny z jednej tabeli do kolumn innej tabeli na innej maszynie na w innej bazie - co zamieni bazę relacja w nierelacyjna i tym samym będziesz miał bardzo droga i niewydajna implementacje NoSql

Przypominam, ze mowa tutaj o gigantycznej skali - takiej której dzisiejsze pojedyncze maszyny nie są w stanie pomieścić, jak np systemy które generują kilka GB danych na minutę.

Zobacz SQl Spaces- to rozwiązanie oparte o relacyjne bazy danych.

To nie jest relacyjna baza danych. Fakt, ze wykorzystuje silnik relacyjny do zapisu danych nie różni się niczym od np tego ze mongomdb zapisuje dane w plikach. Co nie czyni z mongomdb systemu plików ani z Twojego przykładu relacyjnej bazy.

Wbrew pozorom sharding w rdbms też działa bardzo dobrze. Nawet są techniki zapewnienia części integralności, ale odbija się to na wydajności. Dyrektywa Contraint potrafi odpytać wszystkie serwery. I oczywiście masz rację - takie traktowanie nosql ma zastosowanie tylko w określonych rodzajach zapytań.

Sam używałem HBase i tworzyłem takie bazy ad hoc. Do zadań właśnie były przerzucane ogromne ilości danych z baz relacyjnych, obliczano różne rzeczy i dane często lądowały spowrotem. Relacje okazały się błogosławieństwem jako pierwsza walidacja obliczeń.

Sharding bazy relacyjnej zamienia ja w nierelacyjna
Wtedy zaczynamy mieć do czynienia z bardzo drogim NoSql

To jest relacyjna baza danych.A sposobem nawiązywania połączenie ,filtrowania danych jest kreowana przez klienta(TurpleSpaces).To tak jakbyś powiedział ,że baza MSSQL nie jest już relacyjną bo ktoś użył linq to sql w swoim projekcie.
Wystarczy,że doinstalowałbym conector do HSQLDB ,w web.config zdefiniował connectionstringa i śmiało mógłbym używać standardowych sqlowych poleceń.

Z Tobą chciałbym już skończyć na tym dyskusje