2012-01-11 17 views
8

Po prostu chcę lepiej zrozumieć, w tym, czego się nauczyłem od lat jest oparte na dokumentach rozwiązanie jest powolne i wymaga wielu operacji we/wy. Na przykład w projekcie PHP ogólnie mówi się, że znacznie lepiej jest używać pamięci podręcznej, takiej jak Redis, Memecache lub APC, ponieważ są one oparte na pamięci zamiast buforowania danych do rzeczywistego PLIKU.W jaki sposób baza danych oparta na dokumencie jest tak szybka?

Teraz wszystkie te bazy danych NoSQL zostały już dostarczone i przeczytałem o tym, że są one o wiele szybsze niż MySQl i inne i są oparte na dokumentach. Czy ktoś może mi pomóc zrozumieć tę teorię? Jeśli każdy rekord jest dokumentem (FILE), to jak jest tak dobry pod względem wydajności? Ostatnio przeczytałem o facecie, który używał Redisa w projekcie i powiedział, że przeszedł na MongoDB i ma lepsze wyniki niż wtedy, gdy robił z Redis (zdaję sobie sprawę, że porównuję pamięć podręczną z DB, ale to nie jest prawdziwe pytanie, chcesz wiedzieć, jak rozwiązanie oparte na dokumencie jest szybsze niż rozwiązania nie oparte na dokumentach?)

Odpowiedz

4

Oparte na dokumencie niekoniecznie oznacza, że ​​są one przechowywane wyłącznie w systemie plików. Niektóre części mogą nadal być przechowywane w pamięci jak indeks.

Dokument oparty tylko oznacza, że ​​baza danych przechowuje dane w pakietach (takich jak arkusze papieru, gdzie każdy arkusz jest zbiorem danych i można na nim swobodnie pisać) zamiast bardzo specyficznej struktury, takiej jak tabela.

http://en.wikipedia.org/wiki/Document-oriented_database

Ah i dlaczego mogą one być szybsze niż REDiS:
Powiedzmy trzeba przechowywać niektóre nieliniowej informacji w zestawie (czyli nie każdy zbiór danych wygląda tak samo i masz różne typy danych w jednym zestawie Na Redis możesz przechowywać tylko pary klucz-wartość, więc będziesz musiał je połączyć z powrotem do zestawu we własnym kodzie/implementacji.W bazie danych NoSQL jest to obsługiwane przez bazę danych w (prawdopodobnie) znacznie bardziej zoptymalizowany sposób :)

+0

Redis nie tylko przechowuje pary klucz/wartość, może przechowywać znacznie więcej typów danych (Zobacz: http://redis.io/topics/data-types) – Carpetsmoker

0

Po pierwsze - nie można porównywać baz danych NoSQL z bazami danych w pamięci . Bazy danych NoSQL są przeznaczone dla danych, które nie mieszczą się w pamięci.

Teraz, w odniesieniu do baz danych NoSQL, nie są to zwykłe pliki, mają indeksy, które zapewniają szybki dostęp do przesunięć w plikach i tam właśnie jest prędkość.

+4

'Bazy danych NoSQL są przeznaczone dla danych, które nie będą pasuje do pamięci ". To nie w porządku. Dlaczego to mówisz? – jgauffin

+0

OK, poprawiam się, * przez większość czasu * są używane do konstrukcji, które przewyższają rozmiar, który zmieści się w pamięci. Mogą być również używane jako pamięć wewnętrzna i mogą zapewniać lepszą wydajność niż relacyjne tabele w pamięci, ponieważ są prostsze w implementacji. To powiedziawszy, czasami możesz uzyskać jeszcze lepszą wydajność poprzez implementację struktur danych w swoim programie. – thedrs

+1

"Przez większość czasu" nadal jest błędne. Są po prostu alternatywą dla RDBMS, ale są odmiany i mają lepsze rozwiązanie dla zagregowanych korzeni. – jgauffin

2

NoSQL mówić może być skłonny do nieporozumień, ponieważ niektóre z pojęć użyje nazwy, które mają inny sens tradycyjnego:

  • Plik opartą nie (koniecznie) oznaczają, że Datastore zapisze każdy rekord w pliku - ma na celu stwierdzenie, że rekordy w magazynie danych nie muszą być zgodne z predefiniowanym schematem pól, jeśli dany typ danych. Pomyśl o "pliku" jako o XML, JSON lub znajomych.
  • Wygrane wydajności w (większości) magazynach NoSQL ma swoją cenę: Zazwyczaj dobrze rozumiane obietnice ACID są wymieniane z luźniejszym modelem spójności.
  • Siła relacyjnych baz danych SQL wynika w dużej mierze z faktu, że każde zapytanie może być napisane na podstawie istniejącego schematu. Nie jest to prawdą w przypadku magazynów NoSQL: w najbardziej ekstremalnej wersji dostęp do rekordu jest możliwy tylko za pośrednictwem identyfikatora rekordu.
  • Większość NoSQL magazynów danych skaluje się znacznie lepiej niż typowy relacyjnej bazy danych - są odpowiedzią na pytanie: „Co mamy rezygnować z dobrze rozumianym relacyjnej DB” pokonać granice skalowania”
0

aby zorientować się, rozważ to:

  • z MongoDB chcesz zaprojektować schemat w taki sposób, że jeden dokument posiada wszystko, czego potrzeba, aby uczynić stronę
  • z MySQL (lub jakiegokolwiek innego RDBMS) ty. Zmodyfikuj dane i podziel je na wiele tabel, aby renderować to samo stronę, musisz wykonać wiele zapytań SQL.

Chociaż jedno zapytanie mongo może być wolniejsze niż jedno zapytanie mysql, porównanie 1 zapytania mongo do 100 zapytań mysql będzie znacznie szybsze.

0

Magiczny składnik niekoniecznie jest "szybszą" bazą danych, jest to baza danych, która umożliwia projektowanie i wdrażanie "szybszych" systemów. Właśnie dlatego bazy danych NoSQL są uważane za narzędzie do zmiany gry.

Przez kilka dekad relacyjne bazy danych były jedyną grą w mieście. Wiele systemów opartych na języku SQL płaci podwójny podatek od wydajności: raz za pełny zestaw funkcji ACID (który prawdopodobnie i tak nie jest potrzebny), a następnie na ponowne dopasowanie ich danych domeny do modelu tabeli relacyjnej.

Jedną z cech typowych dla większości baz danych NoSQL jest to, że są one łatwiejsze w użyciu niż , ponieważ są bardziej wyspecjalizowane niż podejście "ogólne" w bazie danych SQL. Oznacza to mniej logiki/kodu, który musi działać przy każdej operacji, prostszych strukturach danych (które mogą wymagać mniejszej ilości danych) i ogólnie - mniejszym obciążeniu, lepszej wydajności.

Powiązane problemy