Widzę wiele nieporozumień dotyczących miejsca i celu wielu nowych rozwiązań baz danych („NoSQL databases”) w porównaniu do rozwiązań relacyjnych baz danych, które istnieją od wielu lat. Postaram się więc wyjaśnić różnice i najlepsze przypadki użycia dla każdego z nich.
Początkowo podzielmy te rozwiązania bazodanowe na dwie grupy:
1) Relacyjne bazy danych, które mogą być również nazywane relacyjnymi systemami zarządzania bazą danych (RDBMS) lub bazami danych SQL. Najpopularniejsze z nich to Microsoft SQL Server, Oracle Database, MySQL oraz IBM DB2. Te RDBMS są używane głównie w dużych przedsiębiorstwach, z wyjątkiem MySQL, który jest używany głównie do przechowywania danych dla aplikacji internetowych, zwykle jako część popularnego stosu LAMP (Linux, Apache, MySQL, PHP / Python / Perl).
2) Nierelacyjne bazy danych, zwane również bazami NoSQL, z których najpopularniejsze to MongoDB, DocumentDB, Cassandra, Coachbase, HBase, Redis i Neo4j. Te bazy danych są zazwyczaj pogrupowane w cztery kategorie: Key-value stores, Graph stores, Column stores i Document stores (zobacz Rodzaje baz danych NoSQL).
Wszystkie relacyjne bazy danych mogą być używane do zarządzania aplikacjami zorientowanymi na transakcje (OLTP), a większość nierelacyjnych baz danych, które znajdują się w kategoriach Document stores i Column stores, może być również używana do OLTP, co dodatkowo zwiększa zamieszanie. O bazach OLTP można myśleć jako o bazach „operacyjnych”, charakteryzujących się częstymi, krótkimi transakcjami, które zawierają aktualizacje i które dotykają niewielkiej ilości danych i gdzie współbieżność tysięcy transakcji jest bardzo ważna (przykłady obejmują aplikacje bankowe i rezerwacje online). Integralność danych jest bardzo ważna, więc obsługują one transakcje ACID (Atomicity, Consistency, Isolation, Durability). Jest to przeciwieństwo hurtowni danych, które są uważane za „analityczne” bazy danych charakteryzujące się długimi, złożonymi zapytaniami, które dotykają dużej ilości danych i wymagają wielu zasobów. Aktualizacje są rzadkie. Przykładem jest analiza sprzedaży w ciągu ostatniego roku.
Relacyjne bazy danych zazwyczaj pracują z danymi ustrukturyzowanymi, podczas gdy nierelacyjne bazy danych zazwyczaj pracują z danymi półstrukturalnymi (tj. XML, JSON).
Przyjrzyjrzyjmy się każdej z grup bardziej szczegółowo:
Relacyjne bazy danych
Relacyjna baza danych jest zorganizowana w oparciu o relacyjny model danych, zaproponowany przez E.F. Codda w 1970 roku. Model ten organizuje dane w jedną lub więcej tabel (lub „relacji”) wierszy i kolumn, z unikalnym kluczem dla każdego wiersza. Generalnie, każdy typ podmiotu, który jest opisany w bazie danych ma swoją własną tabelę z wierszami reprezentującymi instancje tego typu podmiotu i kolumnami reprezentującymi wartości przypisane do tej instancji. Ponieważ każdy wiersz w tabeli ma swój unikalny klucz, wiersze w tabeli mogą być powiązane z wierszami w innych tabelach poprzez przechowywanie unikalnego klucza wiersza, z którym powinien być powiązany (gdzie taki unikalny klucz jest znany jako „klucz obcy”). Codd pokazał, że relacje danych o dowolnej złożoności mogą być reprezentowane przy użyciu tego prostego zestawu pojęć.
Prawie wszystkie systemy relacyjnych baz danych używają języka SQL (Structured Query Language) jako języka zapytań i utrzymywania bazy danych.
Powody dominacji relacyjnych baz danych to: prostota, solidność, elastyczność, wydajność, skalowalność i zgodność w zarządzaniu danymi ogólnymi.
Ale aby zaoferować to wszystko, relacyjne bazy danych muszą być niewiarygodnie złożone wewnętrznie. Na przykład, stosunkowo prosta instrukcja SELECT może mieć dziesiątki potencjalnych ścieżek wykonania zapytania, które optymalizator zapytań będzie oceniał w czasie pracy. Wszystko to jest ukryte dla użytkowników, ale pod maską, RDBMS określa najlepszy „plan wykonania”, aby odpowiedzieć na żądania, używając takich rzeczy jak algorytmy oparte na kosztach.
Dla dużych baz danych, szczególnie tych używanych dla aplikacji internetowych, głównym problemem jest skalowalność. Ponieważ coraz więcej aplikacji jest tworzonych w środowiskach, które mają ogromne obciążenia (np. Amazon), ich wymagania dotyczące skalowalności mogą zmieniać się bardzo szybko i rosnąć bardzo duże. Relacyjne bazy danych skalują się dobrze, ale zazwyczaj tylko wtedy, gdy to skalowanie odbywa się na pojedynczym serwerze („scale-up”). Kiedy pojemność tego pojedynczego serwera zostanie osiągnięta, trzeba „przeskalować” i rozłożyć to obciążenie na wiele serwerów, przechodząc do tak zwanego przetwarzania rozproszonego. To właśnie wtedy złożoność relacyjnych baz danych zaczyna powodować problemy z ich potencjałem skalowania. Jeśli próbujesz skalować do setek lub tysięcy serwerów, złożoność staje się przytłaczająca. Cechy, które sprawiają, że relacyjne bazy danych są tak atrakcyjne, są tymi samymi, które również drastycznie zmniejszają ich opłacalność jako platformy dla dużych systemów rozproszonych.
Nierelacyjne bazy danych
Baza danych NoSQL zapewnia mechanizm przechowywania i pobierania danych, które są modelowane w sposób inny niż relacje tabelaryczne używane w relacyjnych bazach danych.
Motywacje dla tego podejścia obejmują:
- Prostotę projektowania. Brak konieczności radzenia sobie z „niedopasowaniem impedancji” między obiektowym podejściem do pisania aplikacji a opartymi na schemacie tabelami i wierszami relacyjnej bazy danych. Na przykład, przechowywanie wszystkich informacji o zamówieniach klientów w jednym dokumencie, w przeciwieństwie do konieczności łączenia wielu tabel razem, co skutkuje mniejszą ilością kodu do napisania, debugowania i utrzymania
- Lepsze „poziome” skalowanie do klastrów maszyn, co rozwiązuje problem, gdy liczba współbieżnych użytkowników gwałtownie wzrasta dla aplikacji, które są dostępne przez Internet i urządzenia mobilne. Używanie dokumentów znacznie ułatwia skalowanie, ponieważ wszystkie informacje dotyczące zamówienia klienta znajdują się w jednym miejscu, a nie są rozproszone w wielu tabelach. Bazy danych NoSQL automatycznie rozkładają dane na serwery bez konieczności zmiany aplikacji (auto-sharding), co oznacza, że natywnie i automatycznie rozkładają dane na dowolną liczbę serwerów, nie wymagając od aplikacji nawet świadomości składu puli serwerów. Dane i obciążenie zapytaniami są automatycznie równoważone na serwerach, a gdy serwer ulegnie awarii, można go szybko i przejrzyście zastąpić bez zakłóceń w pracy aplikacji
- Dokładniejsza kontrola nad dostępnością. Serwery mogą być dodawane lub usuwane bez przestojów w pracy aplikacji. Większość baz danych NoSQL obsługuje replikację danych, przechowując wiele kopii danych w całym klastrze lub nawet w różnych centrach danych, aby zapewnić wysoką dostępność i odzyskiwanie po awarii
- Łatwe przechwytywanie wszystkich rodzajów danych „Big Data”, które obejmują dane nieustrukturyzowane i półstrukturalne. Umożliwienie elastycznej bazy danych, która może łatwo i szybko pomieścić każdy nowy typ danych i nie jest zakłócana przez zmiany struktury zawartości. Dzieje się tak dlatego, że bazy danych dokumentów są pozbawione schematów, co pozwala na swobodne dodawanie pól do dokumentów JSON bez konieczności wcześniejszego definiowania zmian (schema-on-read zamiast schema-on-write). Możesz mieć dokumenty z inną liczbą pól niż inne dokumenty. Na przykład, rekord pacjenta, który może lub nie może zawierać pola, które wymieniają alergie
- Prędkość. Struktury danych używane przez bazy danych NoSQL (tj. Dokumenty JSON) różnią się od tych używanych domyślnie w relacyjnych bazach danych, dzięki czemu wiele operacji jest szybszych w NoSQL niż w relacyjnych bazach danych ze względu na brak konieczności łączenia tabel (kosztem zwiększonej przestrzeni dyskowej ze względu na duplikację danych – ale przestrzeń dyskowa jest obecnie tak tania, że zazwyczaj nie stanowi to problemu). W rzeczywistości, większość baz danych NoSQL nawet nie obsługuje złączeń
- Koszt. Bazy danych NoSQL zwykle wykorzystują klastry tanich serwerów klasy commodity, podczas gdy RDBMS zwykle polegają na drogich serwerach własnościowych i systemach pamięci masowej. Ponadto licencje na systemy RDBMS mogą być dość drogie, podczas gdy wiele baz danych NoSQL jest otwartych, a zatem darmowych
Szczególna przydatność danej bazy danych NoSQL zależy od problemu, który musi ona rozwiązać.
Bazy danych NoSQL są coraz częściej wykorzystywane w aplikacjach internetowych typu big data i czasu rzeczywistego. Stały się one popularne wraz z wprowadzeniem sieci WWW, kiedy to bazy danych przeszły z maksimum kilkuset użytkowników na wewnętrznej aplikacji firmowej do tysięcy lub milionów użytkowników na aplikacji internetowej. Systemy NoSQL są również nazywane „Nie tylko SQL”, aby podkreślić, że mogą one również obsługiwać języki zapytań podobne do SQL.
Wiele sklepów NoSQL rezygnuje ze spójności (w sensie twierdzenia CAP) na rzecz dostępności i tolerancji na partycje. Niektóre powody, które blokują przyjęcie sklepów NoSQL, to użycie niskopoziomowych języków zapytań, brak ustandaryzowanych interfejsów i ogromne inwestycje w istniejący SQL. Ponadto, większość sklepów NoSQL nie posiada prawdziwych transakcji ACID lub obsługuje transakcje tylko w pewnych okolicznościach i na pewnych poziomach (np. poziom dokumentów). Wreszcie, RDBMS są zwykle dużo prostsze w użyciu, ponieważ mają GUI, podczas gdy wiele rozwiązań NoSQL korzysta z interfejsu wiersza poleceń.
Porównanie tych dwóch
Jednym z najpoważniejszych ograniczeń relacyjnych baz danych jest to, że każdy element może zawierać tylko jeden atrybut. Jeśli posłużymy się przykładem banku, każdy aspekt relacji klienta z bankiem jest przechowywany jako oddzielne pozycje wierszy w oddzielnych tabelach. Tak więc główne dane klienta są w jednej tabeli, dane konta są w innej tabeli, dane pożyczki w jeszcze innej, inwestycje w innej tabeli, i tak dalej. Wszystkie te tabele są połączone ze sobą za pomocą relacji, takich jak klucze podstawowe i klucze obce.
Nierelacyjne bazy danych, a konkretnie magazyny kluczy lub pary klucz-wartość, różnią się radykalnie od tego modelu. Pary klucz-wartość pozwalają na przechowywanie kilku powiązanych elementów w jednym „wierszu” danych w tej samej tabeli. Umieszczamy słowo „rząd” w cudzysłowie, ponieważ rząd tutaj nie jest tak naprawdę tym samym, co rząd w tabeli relacyjnej. Na przykład, w nierelacyjnej tabeli dla tego samego banku, każdy wiersz zawierałby dane klienta, jak również jego konto, kredyt i szczegóły inwestycji. Wszystkie dane odnoszące się do jednego klienta byłyby wygodnie przechowywane razem jako jeden rekord.
Wydaje się to oczywiście lepszą metodą przechowywania danych, ale ma poważną wadę: sklepy z kluczami-wartościami, w przeciwieństwie do relacyjnych baz danych, nie mogą wymuszać relacji między elementami danych. Na przykład, w naszej kluczowo-wartościowej bazie danych, dane klienta (imię i nazwisko, ubezpieczenie społeczne, adres, numer konta, numer obsługi kredytu, itd.) byłyby przechowywane jako jeden rekord danych (zamiast w kilku tabelach, jak w modelu relacyjnym). Transakcje klienta (wypłaty z konta, depozyty na koncie, spłaty kredytu, opłaty bankowe itp.) byłyby również przechowywane jako inny pojedynczy rekord danych.
W modelu relacyjnym istnieje wbudowana i niezawodna metoda zapewniania i egzekwowania logiki biznesowej i zasad w warstwie bazy danych, na przykład, że wypłata jest obciążana na właściwym koncie bankowym, poprzez klucze podstawowe i klucze obce. W sklepach z kluczami wartości, ta odpowiedzialność spada na logikę aplikacji i wiele osób czuje się bardzo niekomfortowo pozostawiając tę kluczową odpowiedzialność tylko aplikacji. Jest to jeden z powodów, dla których relacyjne bazy danych będą nadal używane.
Jednakże, jeśli chodzi o aplikacje internetowe, które korzystają z baz danych, aspekt rygorystycznego egzekwowania logiki biznesowej często nie jest najwyższym priorytetem. Najwyższym priorytetem jest zdolność do obsługi dużej liczby żądań użytkowników, które są zazwyczaj zapytaniami tylko do odczytu. Na przykład, na stronie takiej jak eBay, większość użytkowników po prostu przegląda i przegląda wystawione przedmioty (operacje tylko do odczytu). Tylko ułamek tych użytkowników faktycznie składa oferty lub rezerwuje przedmioty (operacje tylko do odczytu i zapisu). I pamiętaj, że mówimy tu o milionach, a czasem miliardach odsłon dziennie. Administratorzy witryny eBay są bardziej zainteresowani szybkim czasem odpowiedzi, aby zapewnić szybsze ładowanie strony dla użytkowników witryny, a nie tradycyjnymi priorytetami egzekwowania reguł biznesowych lub zapewnienia równowagi między odczytami i zapisami.
Relacyjne modelowe bazy danych mogą być dostosowane i skonfigurowane do przeprowadzania operacji na dużą skalę tylko do odczytu poprzez hurtownie danych, a tym samym potencjalnie obsługiwać dużą ilość użytkowników, którzy pytają o dużą ilość danych, zwłaszcza gdy używają relacyjnych architektur MPP, takich jak Analytics Platform System, Teradata, Oracle Exadata lub IBM Netezza, które wszystkie obsługują skalowanie. Jak wspomniano wcześniej, hurtownie danych różnią się od typowych baz danych tym, że są wykorzystywane do bardziej złożonej analizy danych. Różni się to od transakcyjnej (OLTP) bazy danych, której głównym zastosowaniem jest wspieranie systemów operacyjnych i oferowanie codziennego raportowania na małą skalę.
Prawdziwym wyzwaniem jest jednak brak skalowalności modelu relacyjnego, gdy mamy do czynienia z aplikacjami OLTP lub jakimkolwiek rozwiązaniem z dużą ilością indywidualnych zapisów, co jest domeną relacyjnych architektur SMP. To właśnie tutaj modele nierelacyjne mogą naprawdę zabłysnąć. Mogą one z łatwością rozdzielać obciążenia danymi na dziesiątki, setki, a w skrajnych przypadkach (pomyśl o wyszukiwarce Google) nawet tysiące serwerów. Z każdym serwerem obsługującym tylko niewielki procent całkowitych żądań od użytkowników, czas odpowiedzi jest bardzo dobry dla każdego indywidualnego użytkownika. Chociaż ten model obliczeń rozproszonych może być zbudowany dla relacyjnych baz danych, jest to prawdziwy ból do wdrożenia, zwłaszcza gdy istnieje wiele zapisów (tj. OLTP), wymagających technik takich jak sharding, który zwykle wymaga znacznego kodowania poza logiką biznesową aplikacji. Dzieje się tak dlatego, że model relacyjny nalega na integralność danych na wszystkich poziomach, które muszą być utrzymywane, nawet gdy dane są dostępne i modyfikowane przez kilka różnych serwerów. Jest to powód, dla którego model nierelacyjny jest architekturą z wyboru dla aplikacji internetowych, takich jak cloud-computing i sieci społecznościowe.
Podsumowując, RDBMS-y cierpią z powodu braku skalowania poziomego dla wysokich obciążeń transakcyjnych (miliony odczytów-zapisów), podczas gdy bazy NoSQL rozwiązują wysokie obciążenia transakcyjne, ale kosztem integralności danych i złączeń.
Pamiętaj, że wiele rozwiązań będzie korzystać z kombinacji relacyjnych i nierelacyjnych baz danych (zobacz What is Polyglot Persistence?).
Pamiętaj również o tym, że możesz nie potrzebować wydajności nierelacyjnej bazy danych i zamiast tego po prostu iść z przechowywaniem plików w HDFS i używać Apache Hive będzie wystarczające (Apache Hive jest infrastrukturą hurtowni danych zbudowaną na Hadoop w celu zapewnienia podsumowania danych, zapytań i analiz, które zapewnia za pośrednictwem języka podobnego do SQL o nazwie HiveQL).
I aby zakończyć na notatce, która dodaje do zamieszania, mamy inną kategorię tworzącą się o nazwie NewSQL: NewSQL jest klasą nowoczesnych systemów RDBMS, które starają się zapewnić taką samą skalowalną wydajność systemów NoSQL dla obciążeń OLTP typu odczyt-zapis przy jednoczesnym zachowaniu gwarancji ACID tradycyjnego systemu relacyjnej bazy danych. Ich wadą jest to, że nie nadają się do zapytań w stylu OLAP i są nieodpowiednie dla baz danych powyżej kilku terabajtów. Przykłady obejmują VoltDB, NuoDB, MemSQL, SAP HANA, Splice Machine, Clustrix i Altibase.
Zdjęcie przedstawiające kategorie, do których pasuje wiele produktów:
Doskonała grafika, która pokazuje, jak wszystkie technologie pasują do chmury Azure, pochodzi z książki Understanding NoSQL on Microsoft Azure:
Dolna linia dla korzystania z rozwiązania NoSQL jest, jeśli masz aplikację OLTP, która ma tysiące użytkowników i ma bardzo dużą bazę danych wymagającą rozwiązania scale-out i / lub używa danych JSON, w szczególności jeśli te dane JSON mają różne struktury. Otrzymujesz również korzyści z wysokiej dostępności, ponieważ rozwiązania NoSQL przechowują wiele kopii danych. Należy jednak pamiętać, że ze względu na wydajność można poświęcić spójność danych, a także możliwość łączenia danych, używania języka SQL i szybkich aktualizacji masowych.
Więcej informacji:
MySQL vs MongoDB
MySQL vs. MongoDB: Looking At Relational and Non-Relational Databases
10 rzeczy, które powinieneś wiedzieć o bazach danych NoSQL
Wprowadzenie do baz danych
Różnica między SQL a NoSQL: Porównanie
Różnice między bazami danych SQL a NoSQL wyjaśnione na kilku przykładach
NoSQL, NewSQL czy RDBMS: How To Choose
NewSQL – RDBMS on Steroids
NoSQL vs NewSQL Bazy danych Choose the Right Tool for the Right Job
SQL vs NoSQL: you do want to have a relational storage by default
Oracle Defends Relational DBs Against NoSQL Competitors
Understanding NoSQL on Microsoft Azure
Meet the Avant-Garde of New Relational Databases
To SQL or NoSQL? Oto jest pytanie dotyczące baz danych
CAP Theorem: Revisited
Co jest naprawdę nowego w NewSQL?
MongoDB vs MySQL: Porównanie baz danych
Cechy i różnice między bazami danych MySQL i NoSQL
Więcej o