Jak bardzo model danych wpływa na skalowalność i wydajność w tak zwanej bazie danych „NoSQL”?

Nie można nigdy mówić o tak zwanej bazie danych „NoSQL” bez przedstawienia twierdzenia CAP (spójność, dostępność, podział: wybierz dwa). Jeśli musisz wybrać powiedzmy, między MongoDB (partycja, spójność) a CouchDB (dostępność, partycja), najpierw musisz pomyśleć: „Czy potrzebuję poprawnych danych, czy cały czas potrzebuję dostępu?”.

Ci, nowa baza danych zostały wykonane , aby być podzielony. Ale co jeśli nie ? Co jeśli myślę, że fajnie jest mieć klucz / wartość, kolumnę, dokument, dowolną bazę danych zamiast relacyjnej i po prostu utworzyć jedną instancję serwera i nigdy jej nie dzielić? Czy w takim razie nie miałbym zarówno dostępności, jak i spójności? MongoDB nie będzie musiał niczego kopiować, więc będzie dostępny. A CouchDB miałoby tylko jedno źródło danych, więc byłoby dość spójne.

Oznaczałoby to, że w takim przypadku MongoDB i CouchDB miałyby niewielką różnicę w zakresie zastosowania? No cóż, z wyjątkiem wydajności, API i innych, ale byłoby to bardziej jak wybór między PostgreSQL i MySQL niż posiadanie dwóch zasadniczo różnych zestawów wymagań.

Czy ja tu jestem? Czy mogę zmienić bazę danych AP lub CP na AC, nie tworząc więcej niż jednego wystąpienia? Czy jest coś, za czym tęsknię?

Zadajmy pytanie w odwrotnej kolejności. Co jeśli wezmę relacyjną bazę danych, powiedzmy MySQL i ustawię ją w konfiguracji master / slave. Nie używam transakcji ACID Jeśli wymagam natychmiastowej synchronizacji zapisu do urządzenia podrzędnego, czy nie byłoby to bazą danych CP? A co, jeśli zsynchronizuję go w określonych odstępach czasu, i nie ma znaczenia, czy klient odczytuje nieaktualne dane z urządzenia podrzędnego. Czy nie byłoby to bazą danych AP? Czy to nie znaczy, że jeśli zrezygnuję z zgodności z ACID, nadal będę mógł używać modelu powiązań dla partycjonowanej bazy danych?

Zasadniczo: czy skalowalność w kwestii tego, co jesteś gotowy zrezygnować z twierdzenia CAP, to więcej niż podstawowy model danych? Czy posiadanie kolumny, dokumentu, kluczowej wartości w jakikolwiek sposób zwiększa skalowalność w porównaniu z modelem relacyjnym? Czy możemy zaprojektować relacyjną bazę danych zaprojektowaną od podstaw pod kątem tolerancji partycji? (Może już istnieje). Czy możemy uczynić bazę danych NoSQL zgodną z ACID?

Niestety, jest wiele pytań, ale ostatnio dużo czytałem o bazie danych NoSQL i wydaje mi się, że największą zaletą korzystania z nich jest to, że lepiej pasują do „kształtu” twoich danych, a nie tylko do partycji, CAP i rezygnacja z zgodności z ACID. W końcu nie wszyscy mają tyle danych, że muszą je podzielić na partycje. Czy korzyść z wydajności / skalowalności nie polega na korzystaniu z modelu relacyjnego, zanim jeszcze pomyślę o partycjonowaniu danych?

Czy korzystanie z bazy danych NoSQL zwiększa skalowalność, nawet jeśli nie dzielisz danych? Dobrze pozwala zdefiniować skalowalność. Jeśli mówisz o skalowalności jako o systemach baz danych / zaplecza, ponieważ masz skalowanie w pionie i poziomie, w którym skalowanie w poziomie JEST dzieleniem danych, staje się to trywialne pytanie, ponieważ wtedy odpowiedź byłaby absolutnie nie, ponieważ jedyną opcją, którą pozostawiłeś to skalowanie pionowe (tj. uzyskiwanie lepszego sprzętu). Jeśli jednak mówisz o skalowalności w szerszym znaczeniu, odnosząc się do elastyczności aplikacji, wartości danych itp. ... To jest zupełnie inne pytanie z wieloma odpowiedziami. I tak jak wspomniałeś, często sprowadza się to do tego, co robisz z danymi i jak powinny być przechowywane. Pozwólcie, że wszystko tu poprzedzę stwierdzeniem, że w większości przypadków nadal powinieneś używać RDBMS, a NoSQL powinien wypełniać niszę. Poniżej znajduje się opis konkretnego wystąpienia, w którym baza danych NoSQL byłaby bardziej korzystna, biorąc pod uwagę określone wymagania, i gdzie możemy zignorować skalowanie w poziomie.

Weźmy na przykład pomysł, że tworzysz system przechowywania plików w chmurze podobny do Google Drive, Dropbox lub Box, ale zamiast używać rzeczywistego systemu plików, zdecydowałeś, że wirtualizacja systemu plików byłaby dla Ciebie korzystniejsza. Teraz masz problem, ponieważ twój model danych nagle staje się drzewiastą strukturą, która będzie strasznie nieefektywna w RDBMS (pomimo tego, że w ten sposób wszystko jest indeksowane). Ponieważ teraz masz 3-kolumnową tabelę z nazwami, użytkownikami i rodzicami. Użytkownik jest kluczem obcym do tabeli użytkowników, a element nadrzędny to samowywoływający się klucz obcy z dopuszczalnym dopuszczeniem wartości zerowej (zerowany, ponieważ katalog główny nie może mieć elementu nadrzędnego). Więc jaki jest klucz podstawowy? W tym przypadku jest to złożony klucz we wszystkich kolumnach ... Co nagle sprawia, że ​​Parent jest naszym największym wrogiem.

Zastanów się teraz, jak umieścić to w jakiejś formie magazynu dokumentów? Zamiast walczyć z danymi, możesz z nimi pracować i przechowywać je jako strukturę drzewa, co z kolei skróci czas programowania i obniży koszty utrzymania. Jeśli zmniejszasz koszty, czy nie pozwala to na inny rodzaj skalowalności? Dodatkowo w tym przypadku tworzysz system od podstaw, co powinno dać większą elastyczność samej aplikacji. Obecnie korzystam z tego na jednym serwerze za pomocą MongoDB, co, jak wyjaśniłeś, daje mi dostępny, spójny model, który niewiele różni się od patrzenia na różnicę w MySQL lub Postgres.

Za pomocą MongoDB możesz przynajmniej określić, z iloma serwerami musisz się komunikować, aby zapytanie zakończyło się powodzeniem, więc tak, możesz przekonwertować go na spójny, dostępny model, jeśli powiesz wszystkim zapytaniom, aby komunikowały się ze wszystkimi instancjami serwera.

Myślę więc, że masz do tego prawo, ponieważ istnieje duża korzyść ze sposobu przechowywania danych. Są rzeczy, które nie pasują dobrze do modelu relacyjnego, które dobrze pasują do innych modeli (jako kolejny krótki przykład, Amazon używa jakiejś formy Graficznej Bazy Danych dla ich silnika rekomendacji dla produktów).

Czy poprawnie zrozumiałem twoje pytanie?

Edycja: czy więcej danych spowolni? Tak. Jak bardzo to spowolni? Szczerze mówiąc, nie mam wystarczającego doświadczenia, aby udzielić właściwej odpowiedzi. Klucz / wartość: Zasadniczo tabela odnośników z dużą ilością danych powiązanych z kluczem odnośników. To będzie naprawdę bardzo szybkie, ponieważ możesz sprawdzić rzeczy tylko za pomocą klucza. Kolumna / rodzina: Zasadniczo dużo bardziej uporządkowany magazyn kluczy / wartości. Możesz wysyłać zapytania tylko w oparciu o Kolumnę, więc to też powinno być naprawdę szybkie. Dokument: Schemat stylu agregacji. Tutaj będziesz chciał zebrać podobne dane razem. Denormalizacja jest dobra i oczekuje się w przypadku tego rodzaju bazy danych. W zależności od tego, czy wykonujesz dużo zapisów lub odczytów, możesz uporządkować swoje dane, tak aby były one rozdzielane na wiele odłamków w celu dystrybucji zapisów lub odczytów (pamiętaj, że możesz stworzyć hybrydowe podejście, które jest dobre dla obu, ale ogólnie dla ciebie trzeba wybrać optymalizację dla jednego lub drugiego) Wykres: Siłą tego jest to, że może on bardzo szybko tworzyć i burzyć relacje. Jeśli masz jakieś dane, w których istnieją relacje, które muszą się zmieniać między danymi (pomyśl jakąś formę mechanizmu rekomendacji), powinieneś tego użyć.

Sposób przechowywania danych w którejkolwiek z tych baz danych wpłynie na wydajność (podobnie jak w przypadku nieprawidłowego przechowywania danych w niektórych RDBMS wpłynie to na wydajność). Więc mam nadzieję, że wyjaśnię to bardziej: Musisz wiedzieć, z którego systemu bazy danych powinieneś korzystać, a także jak przechowywać dane w tym systemie baz danych.