Baza danych dokumentów a relacyjna baza danych: jak wybrać?


16

Jestem facetem od SQL, ale wiem, że istnieją nie tylko bazy danych SQL - głównie baza danych dokumentów. Jak w przypadku większości technologii, istnieją zalety i wady każdej technologii.

Przeczytałem kilka artykułów, ale były one zbyt teoretyczne. Chciałbym dwóch prawdziwych przypadków:

  1. gdy zmiana z relacyjnej na bazę danych dokumentów poprawiła się
  2. gdy zmiana z dokumentu na relacyjną bazę danych dała poprawę

Ulepszenie to dowolna rzecz, która sprawia, że ​​lepsze programy - krótszy czas opracowywania, skalowalność, wydajność, wszystko, co jest związane z programowaniem. Jest zastrzeżenie dla 2.: historie takie jak „powrót do relacyjnej bazy danych, ponieważ wszyscy wiedzą, że SQL” nie jest dobre


8
Niewłaściwe podejście. Nie chodzi o „wydajność” ani „skalowalność”. Chodzi o to, który model pasuje do problemu, który próbujesz rozwiązać. Możesz zaktualizować swoje pytanie, aby uwzględnić pomysł, że relacyjna baza danych nie jest odpowiednia dla wielu rodzajów problemów.
S.Lott,

2
@ S.Lott, wybór często zależy od wydajności. należy wziąć pod uwagę, że dowolny relacyjny DB może być użyty jako prosty DB dokumentu - tylko wydajność byłaby cechą wyróżniającą.
edA-qa mort-ora-y

Przeredagowałem moje pytanie, aby nie zostało w żaden sposób załadowane.
Johan Buret,

2
@ edA-qa mort-ora-y: „dowolny relacyjny DB może być użyty jako prosty DB dokumentu”. To musi być nieprawda, bo ludzie nie wymyśliliby alternatywy. „tylko wydajność byłaby cechą wyróżniającą”. Jest to prawdą tylko wtedy, gdy założymy, że model relacyjny robi wszystko równie dobrze. Gdyby zrobił wszystko, nie byłoby alternatywy. Jeszcze. Mamy alternatywy. Istnieje wiele problemów (jak hierarchie), które nie pasują do modelu relacyjnego doskonale i wymagające sprytnych sztuczek. Lub alternatywny model danych.
S.Lott,

„czytasz artykuły”? Proszę podać linki lub tytuły, referencje lub cytaty. Nie wiemy, co dla ciebie oznacza „zbyt teoretyczny”.
S.Lott,

Odpowiedzi:


15

Głównym powodem wyboru bazy danych NoSQL w ostatnich latach była dostępność . W przypadku firm takich jak Amazon, Google i Facebook godzina przestoju jest niedopuszczalna. Aby osiągnąć wysoką dostępność, musisz zmniejszyć pojedynczy punkt awarii, co oznacza, że ​​musisz użyć systemu rozproszonego z wieloma komputerami na wypadek awarii komputera, usługa jest nadal dostępna.

Tradycyjne bazy danych Relatione nie są zbyt dobre w rozproszonej konfiguracji multi-master. Właśnie dlatego NoSQL jest ostatnio tak popularny. Jeśli więc potrzebujesz wysokiej dostępności, możesz wybrać bazę danych NoSQL, taką jak Riak, Cassandra, HBase, S3 lub BigTable.

Jest dobry post na blogu o Dynamo Amazon, który jest dobrym wprowadzeniem do rozproszonych baz danych NoSQL.

Teraz termin NoSQL jest bardzo szeroki, więc istnieje wiele baz danych NoSQL, które nie są dystrybuowane. Ale rozwiązują inne problemy. Np. Neo4j - baza danych grafów jest dobra w przypadku zapytań, dla których tradycyjne RDBMS nie są zoptymalizowane. Lub jak w twoim przypadku baza danych dokumentów, w której nie musisz zmieniać schematu, jeśli chcesz dodać pola dla niektórych dokumentów. Innymi słowy, baza danych dokumentów jest dobra, gdy większość postów (dokumentów) ma różne pola, więc tabela relacyjna ze wstępnie zdefiniowanymi kolumnami nie jest użyteczna.

Jednak większość baz danych NoSQL nie jest tak elastyczna jak tradycyjne bazy danych RDBMS, więc dobrym wyborem jest użycie tradycyjnej bazy danych RDBMS, dopóki nie rozwiąże ona problemów.


+1, Uzgodniony, elastyczność to ogromna cena do zapłacenia, jeśli nie musisz.
wałek klonowy

12

Mam proste podejście do określenia bazy danych, która najlepiej pasuje do danych.

Po prostu zadaję sobie pytanie: zakładając, że nie mam bazy danych, wolałbym zapisać najważniejsze i najważniejsze dane jako dokument, czy też zapisać je w arkuszu kalkulacyjnym.

Gdy odpowiedź brzmi „Arkusz kalkulacyjny”, jest to wyraźny znak, że model relacyjny i tradycyjny RDBMS najlepiej odpowiadają zadaniom przez większość czasu. Jeśli dane są naprawdę proste, jak tylko pary klucz-wartość lub proste tabele, a integralność referencyjna nie jest tematem, baza danych NoSQL prawdopodobnie najlepiej nadaje się do tego zadania i może znacznie zwiększyć wydajność!

Ponadto, gdy nie możesz w ogóle znaleźć wspólnej struktury, baza danych NoSQL najlepiej nadaje się do tego zadania.

Kiedy dane są bardziej podobne do dokumentów, np. Hierarchicznie ustrukturyzowane dane tekstowe bez wyraźnych relacji, natychmiast myślę o bazie danych XML, która z łatwością pozwala przechowywać hierarchicznie ustrukturyzowane dokumenty. Czasami jednak najlepiej jest korzystać z oprogramowania do zarządzania dokumentami.

Aby udzielić konkretnej i prostej odpowiedzi na oba pytania: Zależy to od danych.

gdy zmiana z relacyjnej na bazę danych dokumentów poprawiła się

Kiedy musisz zachować hierarchicznie ustrukturyzowane dane tekstowe, Baza danych Xml może być dużym ulepszeniem pod względem łatwości konserwacji i prawdopodobnie także skalowalności.

gdy zmiana z dokumentu na relacyjną bazę danych dała poprawę

Na przykład, gdy dane są w większości w formie tabelarycznej z wyraźnymi relacjami i trzeba zagwarantować integralność.


2
+1 za arkusz kalkulacyjny vs analogię dokumentu - ogromna pomoc - dzięki.
HDave

10

Musieliśmy zrezygnować z modelu relacyjnego, ponieważ otrzymywane dane nie miały prostego, oczywistego, stałego, statycznego schematu.

Użytkownicy - i historie użytkowników - nie mieli ustalonego, statycznego schematu.

Próbowaliśmy narzucić stały, statyczny schemat RDBMS, ale to był błąd.

Każda zewnętrzna dostawa danych (od klientów i od dostawców) była podobna, ale nie identyczna. Próbowaliśmy odwzorować go na ustalony schemat relacyjny, ale zmienność była zbyt duża. Musieliśmy albo dodawać pola do każdego pliku (kilka tygodniowo), albo musieliśmy odstąpić od ustalonego, statycznego schematu relacyjnego.

Gdybyśmy postrzegali każdy rekord jako „dokument” ze wspólnym podzbiorem elementów i unikalnym (jak również źle zdefiniowanym) zbiorem dodatkowych elementów danych, byliśmy znacznie bardziej zadowoleni.

Źle zdefiniowany zbiór elementów danych jest tym, czego użytkownicy naprawdę potrzebowali w swoich przypadkach użycia.

Naprawiony, statyczny schemat modelu relacyjnego nie pasował do naszych przypadków użycia.


Widziałem, że inne projekty nie spełniają wymagań z powodu dokładnie opisanych wymagań. Do tego właśnie były przeznaczone bazy danych dokumentów.
wałek klonowy
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.