Odpowiedzi:
Sklep klucz-wartość zapewnia najprostszy możliwy model danych i jest dokładnie to, co sugeruje nazwa: jest to system pamięci masowej, który przechowuje wartości indeksowane przez klucz. Jesteś ograniczony do zapytań według klucza, a wartości są nieprzejrzyste , sklep nic o nich nie wie . Pozwala to na bardzo szybkie operacje odczytu i zapisu (prosty dostęp do dysku) i postrzegam ten model jako rodzaj nieulotnej pamięci podręcznej (tj. Dobrze dopasowany, jeśli potrzebujesz szybkiego dostępu za pomocą klucza do danych o długiej żywotności).
Bazie dokument zorientowanych rozszerza poprzedni model i wartości są przechowywane w uporządkowany formacie (dokument, stąd nazwa), że baza danych może zrozumieć. Na przykład dokument może być postem na blogu, a komentarze i tagi przechowywane w zdenormalizowany sposób. Ponieważ dane są przezroczyste , sklep może wykonać więcej pracy (np. Indeksowanie pól dokumentu) i nie musisz ograniczać się do zapytań według klucza. Jak już wspomniałem, takie bazy danych pozwalają na pobranie danych całej strony za pomocą jednego zapytania i są dobrze przystosowane do aplikacji zorientowanych na treść (dlatego lubią je duże serwisy, takie jak Facebook czy Amazon).
Inne rodzaje baz danych NoSQL obejmują magazyny kolumnowe , graficzne bazy danych, a nawet bazy danych obiektów . Ale to nie podlega dyskusji.
Cóż, sam badałem NoSQL przez ostatni miesiąc. Myślę, że ogólnie można by powiedzieć coś takiego
Baza danych zorientowana na dokumenty lub magazyn dokumentów służy do przechowywania, wyszukiwania i zarządzania informacjami zorientowanymi na dokumenty, które są danymi częściowo ustrukturyzowanymi. Magazyn wartości kluczowej jest dziedziczony po bazie danych zorientowanej na dokumenty. Różnica polega na sposobie przetwarzania danych; w magazynie klucz-wartość dane są uważane za z natury nieprzejrzyste dla bazy danych, podczas gdy system zorientowany na dokumenty opiera się na wewnętrznej strukturze dokumentu w celu wyodrębnienia metadanych, które silnik bazy danych wykorzystuje do dalszej optymalizacji.
Jeśli zajmiemy się różnicą między MOngoDb i Cassandra. MongoDB działa podobnie jak relacyjna baza danych. Jego model danych składa się z bazy danych na najwyższym poziomie, następnie kolekcji, które są jak tabele w MySQL (na przykład), a następnie dokumentów zawartych w kolekcji, takich jak wiersze w MySQL. Każdy dokument ma pole i wartość, która jest podobna do kolumn i wartości w MySQL. Pola mogą być prostymi kluczami / wartościami, np. {'Name': 'David Mytton'}, ale mogą również zawierać inne dokumenty, np. {'Name': {'first': David, 'last': 'Mytton'}}. W Cassandrze dokumenty są nazywane „kolumnami”, które w rzeczywistości są tylko jednym kluczem i wartością. np. {'klucz': 'nazwa', 'wartość': 'David Mytton'}. Istnieje również pole sygnatury czasowej, które służy do wewnętrznej replikacji i spójności. Wartość może być pojedynczą wartością, ale może również zawierać inną „kolumnę”. Te kolumny istnieją następnie w rodzinach kolumn, które porządkują dane na podstawie określonej wartości w kolumnach, do których odwołuje się klucz.
Ale na najwyższym poziomie znajduje się przestrzeń kluczy, która jest podobna do bazy danych MongoDB.