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

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?

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 .

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.

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.

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.

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.

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.

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