Dlaczego warto używać baz danych opartych na dokumentach zamiast relacyjnych baz danych?

188

Dlaczego powinienem używać baz danych opartych na dokumentach, takich jak CouchDB zamiast relacyjnej bazy danych. Czy istnieją typowe aplikacje lub domeny, w których baza danych oparta na dokumentach jest bardziej odpowiednia niż relacyjna baza danych?

Bartosz Blimke
źródło
Być może baza danych zorientowana na dokument może być pod pewnymi względami podobna do bazy danych „podmiot-wartość-wartość” (EAV).
ChrisW

Odpowiedzi:

167

Prawdopodobnie nie powinieneś :-)

Drugą najbardziej oczywistą odpowiedzią jest to, że powinieneś jej użyć, jeśli twoje dane nie są relacyjne. Zwykle objawia się to brakiem łatwego sposobu opisania danych jako zestawu kolumn. Dobrym przykładem jest baza danych, w której faktycznie przechowujesz dokumenty papierowe, np. Skanując pocztę biurową. Dane to zeskanowany plik PDF i masz pewne metadane, które zawsze istnieją (skanowane przy, skanowane przez, rodzaj dokumentu) oraz wiele możliwych pól metadanych, które istnieją (numer klienta, numer dostawcy, numer zamówienia, przechowuj do momentu, OCRed pełny tekst itp.). Zwykle nie wiesz z góry, które pola metadanych dodasz w ciągu najbliższych dwóch lat. Rzeczy takie jak CouchDB działają znacznie lepiej dla tego rodzaju danych niż relacyjne bazy danych.

Osobiście uwielbiam fakt, że nie potrzebuję żadnych bibliotek klienta dla CouchDB, z wyjątkiem klienta HTTP, który jest obecnie zawarty w prawie każdym języku programowania.

Prawdopodobnie najmniej oczywista odpowiedź: jeśli nie odczuwasz bólu podczas korzystania z RDBMS, pozostań przy nim. Jeśli zawsze musisz obejść RDBMS, aby wykonać swoje zadanie, warto zorientować się w bazie danych zorientowanej na dokumenty.

Aby uzyskać bardziej rozbudowaną listę, sprawdź ten wpis Richarda Jonesa .

max
źródło
1
Nigdy nie widziałem żadnego schematu bazy danych od dwóch lat przypominającego oryginalny schemat, od którego zaczęliśmy ... więc wszystko jest równe (co nie jest ...), zawsze powinieneś używać bazy danych bez schematu = zorientowanej na dokument; co wydaje mi się dość mylące imię ...
6 ᆺ ᆼ
3
@ int3 Jeśli nie możesz opisać swoich danych jako zestawu kolumn, jak powinieneś napisać inteligentne zapytania na te dane?
Clay Smith,
46

CouchDB (z ich strony internetowej )

  • Serwer bazy danych dokumentów, dostępny za pośrednictwem RESTful JSON API. Zasadniczo dostęp do relacyjnych baz danych nie jest po prostu uzyskiwany za pośrednictwem usług REST, ale wymaga znacznie bardziej złożonego interfejsu API SQL. Często te API (JDBC, ODBC itp.) Są dość złożone. REST jest dość prosty.

  • Ad-hoc i bez schematu z płaską przestrzenią adresową. Relacyjne bazy danych mają złożony, stały schemat. Definiujesz tabele, kolumny, indeksy, sekwencje, widoki i inne rzeczy. Kanapa nie wymaga tego poziomu złożonego, kosztownego, delikatnego zaawansowanego planowania.

  • Rozproszony, z solidną, przyrostową replikacją z dwukierunkowym wykrywaniem konfliktów i zarządzaniem. Niektóre komercyjne produkty SQL to oferują. Ze względu na SQL API i stałe schematy jest to złożone, trudne i kosztowne. Dla kanapy wydaje się proste i niedrogie.

  • Obsługa zapytań i indeksów, wyposażony w silnik raportowania zorientowany na tabelę, który używa Javascript jako języka zapytań. Podobnie SQL i relacyjne bazy danych. Nic nowego tutaj.

Więc. Dlaczego CouchDB?

  • REST jest prostszy niż JDBC lub ODBC.
  • Żaden schemat nie jest prostszy niż schemat.
  • Rozmieszczone w sposób, który wydaje się prosty i niedrogi.
S.Lott
źródło
12
Chociaż jestem wielkim fanem baz danych NoSQL, pierwsze twierdzenie (REST jest prostsze niż JDBC) jest bardzo wątpliwe.
ᆼ ᆺ ᆼ
2
Protokół REST wydaje mi się dość prosty, ponieważ jest to po prostu HTTP: bezstanowy, kilka metod itp. Itp. Być może JDBC jest (pod maską) prosty; nie wydaje się to prostsze, oparte jedynie na byciu stanowczym.
S.Lott,
5
@ S.Lott Czy odpowiedź nie powinna być bardziej „ogólna” niż skierowana wyłącznie na CouchDb?
Pacerier,
„delikatne zaawansowane planowanie” vs co? Z mojego doświadczenia wynika, że ​​alternatywą jest brak planowania, co prowadzi do struktur danych spaghetti, które są modyfikowane według kaprysu.
Tejay Cardon
26

Za głupie przechowywanie i serwowanie danych innych serwerów.

W ciągu ostatnich kilku tygodni bawiłem się aplikacją lifestream, która sonduje moje kanały (pyszne, Flickr, Github, Twitter ...) i przechowuje je w couchdb. Zaletą couchdb jest to, że pozwala mi zachować oryginalne dane w oryginalnej strukturze bez narzutów. Dodałem pole „klasy” do każdego dokumentu, przechowując serwer źródłowy, i napisałem klasę renderowania javascript dla każdego źródła.

Uogólniając, za każdym razem, gdy Twój serwer komunikuje się z innym serwerem, najlepiej jest przechowywać bez schematu, ponieważ nie masz kontroli nad schematem. Jako bonus, couchdb używa natywnych protokołów serwerów i klientów - JSON do reprezentacji i HTTP REST do transportu.

daonb
źródło
Dlaczego nie przechowywać ich w pliku lub pliku na kanał?
j_random_hacker
6
ponieważ couchdb pozwala także tworzyć ciekawe widoki za pomocą mapy / zmniejszania. Na przykład mogę utworzyć widok na podstawie źródła danych lub obliczyć sumy dla każdego źródła.
daonb
4
To genialny punkt ... jeśli konsumujesz dane i nie masz kontroli nad schematem danych przychodzących - skorzystaj z magazynu dokumentów.
Joshua Robinson
1
To pierwszy naprawdę przekonujący argument na temat wartości baz danych NoSQL
Caleb McNevin
20

Przychodzi mi na myśl szybkie tworzenie aplikacji.

Kiedy ciągle rozwijam swój schemat, ciągle jestem sfrustrowany koniecznością utrzymania schematu w MySQL / SQLite. Chociaż nie zrobiłem jeszcze zbyt wiele z CouchDB, podoba mi się, jak łatwo jest ewoluować schemat podczas procesu RAD.

Przypadek, w którym możesz nie chcieć korzystać z nierelacyjnej bazy danych, występuje wtedy, gdy masz wiele relacji wiele do wielu; Muszę się zastanowić, jak stworzyć dobre funkcje MapReduce wokół tego rodzaju relacji, szczególnie jeśli potrzebujesz metadanych w relacji łączenia. Nie jestem pewien, ale nie sądzę, że funkcje CouchDB Map mogą wywoływać własne zapytania w bazie danych, ponieważ może to potencjalnie powodować nieskończone pętle.

pixelcort
źródło
1
Doskonały punkt Magazyny danych (i inne schematy) świetnie nadają się do szybkiego rozwoju na wczesnym etapie. Jednak z tych samych powodów doskonale nadają się do prototypowania na wczesnym etapie, stanowią problem dla niezawodnych aplikacji produkcyjnych.
Tejay Cardon
6

Użyj bazy danych opartej na dokumentach, gdy nie musisz przechowywać danych w tabelach z polami o jednolitym rozmiarze dla każdego rekordu. Zamiast tego musisz przechowywać każdy rekord jako dokument, który ma określone cechy. Dowolna liczba pól o dowolnej długości może być dynamicznie dodawana do dokumentu w dowolnym momencie bez potrzeby „modyfikowania tabeli”. Pola oparte na dokumentach mogą również zawierać wiele fragmentów danych.

smdelfin
źródło
1

Aby rozwinąć na smdelfin: elastyczność. Możesz przechowywać dane w dowolnej strukturze (bez struktury i wszystkich), a każdy dokument może być zupełnie inny. CouchDB jest szczególnie przydatny, ponieważ dzięki ich indeksom „widoku” możesz odfiltrować określone dokumenty i zapytać tylko o ten widok, kiedy chcesz tych podzbiorów bazy danych.

Mój największy zwycięski punkt w bazach danych dokumentów, które przechowują dane w formacie JSON: jest to macierzysty format JavaScript. Dlatego aplikacje JavaScript obsługujące CouchDB działają niesamowicie dobrze. Niedawno stworzyłem aplikację internetową, która wykorzystuje CouchDB i jest szybka jak rakieta, a jednocześnie jest w stanie obsłużyć ciągle zmieniającą się strukturę danych.

MitchB
źródło
0

Bazy danych oparte na dokumentach mają dużą przewagę nad relacyjnymi bazami danych, ponieważ nie wymagają wcześniejszego zdefiniowania schematu, zanim będą mogły wprowadzić jakiekolwiek dane.

Powinieneś również użyć bazy danych dokumentów, jeśli dane nie są relacyjne i nie można ich przechowywać w tabeli, ale raczej jako zestaw obrazów lub na przykład artykułów prasowych.

Kolejną zaletą jest łatwość korzystania z baz danych opartych na dokumentach podczas tworzenia stron internetowych. Aby uzyskać bardziej szczegółowe porównanie modeli baz danych NoSQL, sprawdź to źródło: https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf

evidrascu
źródło