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?

[solificati]

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.

[nasty]

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.

[solificati]

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.

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.

Ten post edytował solificati 10.07.2012, 16:32:43

[nasty]

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.

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 (IMG:style_emoticons/default/smile.gif)

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

Ten post edytował nasty 10.07.2012, 16:59:18