![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 247 Pomógł: 11 Dołączył: 5.09.2009 Ostrzeżenie: (0%) ![]() ![]() |
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?
|
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 26 Pomógł: 10 Dołączył: 17.03.2012 Ostrzeżenie: (0%) ![]() ![]() |
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.
|
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 634 Pomógł: 14 Dołączył: 27.05.2006 Skąd: Berlin Ostrzeżenie: (0%) ![]() ![]() |
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. |
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 26 Pomógł: 10 Dołączył: 17.03.2012 Ostrzeżenie: (0%) ![]() ![]() |
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 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 6.10.2025 - 12:22 |