Przy jakim rozmiarze danych przejście z SQL na NoSQL jest korzystne?

24

Jako programista relacyjnych baz danych (przez większość czasu) czytam artykuły o tym, jak relacyjne bazy danych nie skalują się, i rozwiązania NoSQL, takie jak MongoDB. Ponieważ większość baz danych, które do tej pory opracowałem, była mała do średniej, nigdy nie miałem problemu, który nie został rozwiązany przez indeksowanie, optymalizację zapytań lub przeprojektowanie schematu.

Jakiego rozmiaru spodziewałbym się po walce z MySQL. Ile rzędów?

(Wiem, że będzie to zależeć od aplikacji i rodzaju przechowywanych danych. Ta, która mnie dostała, była w zasadzie bazą danych genetyki, więc miałaby jedną tabelę główną z 3 lub 4 tabelami wyszukiwania. Tabela główna będzie zawierać między inne rzeczy, odniesienie do chromosomu i współrzędna pozycji. Prawdopodobnie zostanie zapytany o liczbę wpisów między dwiema miksturami na chromosomie, aby zobaczyć, co tam jest przechowywane).

wobbily_col
źródło
4
Prawdopodobnie nie powinieneś pracować przy założeniu, że MySQL jest górnym limitem liczby wierszy obsługiwanych przez relacyjną bazę danych. Naprawdę zadajesz dwa pytania: Kiedy w MySQL zabraknie ciągu? i jakie są ograniczenia pojemności SQL RDBMS? Na co chcesz odpowiedzieć?
Blrfl

Odpowiedzi:

13

Jak duże dane?

Istnieją dwa znaczące progi:

  1. całe dane mieszczą się w pamięci RAM
  2. całe dane indeksu mieszczą się w pamięci RAM

W przypadku szybkich dysków SSD pierwszy próg stał się nieco mniejszy, chyba że masz szalony duży ruch.

Kwasowość

Jednym z problemów ze skalowaniem RDBMS jest to, że z założenia są one ACID, co oznacza transakcje i blokady na poziomie wiersza (lub nawet na poziomie tabeli w niektórych starszych / prostszych RDBMS). Może to być czynnik ograniczający, jeśli masz wiele zapytań modyfikujących wiele danych jednocześnie. Rozwiązania NoSQL zwykle wybierają ostateczny model spójności .

Jak skaluje się RDBMS według wielkości danych?

Nie jest do końca prawdą, że RDBMS nie może skalować według wielkości danych, istnieją dwie alternatywy: partycjonowanie pionowe i partycjonowanie poziome (inaczej sharding).

Partycjonowanie pionowe zasadniczo utrzymuje niepowiązane tabele na osobnych serwerach DB, a tym samym utrzymuje rozmiar każdego poniżej progów wymienionych powyżej. To sprawia, że ​​dołączanie do tych tabel przy użyciu zwykłego SQL jest mniej proste i mniej wydajne.

Sharding oznacza dystrybucję danych z jednej tabeli między różnymi serwerami w oparciu o określony klucz. Oznacza to, że w przypadku wyszukiwań wiesz, który serwer zapytać na podstawie tego klucza. Jednak komplikuje to zapytania, które nie są wyszukiwane na kluczu fragmentowania.

W przypadku obu rodzajów partycjonowania, jeśli dojdziesz do skrajności, w zasadzie kończy się taka sama sytuacja jak w bazach danych NoSQL.

vartec
źródło
9
Oracle, PostgreSQL, MySQL, MS SQL Server i Sybase są w stanie wykonywać sprzężenia między tabelami na zdalnych serwerach bez konieczności wykonywania pracy przez klienta.
Blrfl
4
O „całych danych w pamięci RAM” pamiętaj, że chodzi o rzeczywisty zestaw roboczy. Często bazy danych są większe niż pamięć, ale większość z nich jest rzadko dostępna, mając to na dysku, nie jest tak źle, o ile indeksy i często pobierane wiersze itp. Są w pamięci
John
2
@vartec Więc chcesz usunąć moją 2-letnią pocztę z mojej bazy danych poczty, gdy przeszukuję ją tylko raz w miesiącu, podczas gdy mój główny zestaw roboczy to tylko ostatnie dziesięć wiadomości e-mail?
johannes
3
@wobbily_col wskazówka: nie jest. chyba że nie dbasz o spójność, niezawodność lub trwałość. w takim przypadku możesz wyłączyć wiele rzeczy, które sprawiają, że jedna jest znacznie szybsza od drugiej, lub odwrotnie, jeśli chcesz. zgadnij, jakie są domyślne konfiguracje na każdym z nich? (oczywiście MySQL też nie jest szczytem bezpieczeństwa danych ...)
Javier
1
@vartec „Automatyczne dzielenie” jest dobre tam, gdzie ma to zastosowanie. Ale nagle nie możesz już połączyć wszystkich danych - och, czekaj, nie możesz tego zrobić, gdy baza danych dokumentów przeszukuje wszystkie dane lub tworzenie raportów staje się nużąca ... tak, bazy danych dokumentów mają swoje miejsce, gdy model danych i operacje są takie same dla innych systemów ... sama ilość danych nie ma znaczenia (wiem o wystarczającej liczbie instancji MySQL działających z danymi w regionie terabajtowym z powodzeniem ... i projektów z kilkoma niepowodzeniami MB)
johannes
13

Nie sądzę, że rozmiar danych jest jedynym czynnikiem. „Model danych” jest również bardzo ważną częścią.

Strony katalogu e-commerce (Solr, ElasticSearch), dane analityki internetowej (Riak, Cassandra), ceny akcji (Redis), połączenia relacji w sieciach społecznościowych (Neo4J, FleetDB) to tylko niektóre przykłady, w których naprawdę świeci rozwiązanie NoSQL.

IMHO, model danych ma ważniejszą rolę niż rozmiar danych, gdy rozważa się rozwiązanie NoSQL lub RDBMS.

Chiron
źródło
9
Dokładnie. wszystkie te bla bla bla „big data” to marketing, a całe „NoSQL dla big data”! rzeczy też są. NoSQL jest dobry dla dużych zestawów danych, ponieważ jest szybszy niż tradycyjny RDBMS, ale jest szybszy z powodu ogromnych kompromisów funkcji, które powoduje. Wiele modeli danych znacznie ucierpi z powodu tych kompromisów, podczas gdy niektóre będą działać poprawnie. Chodzi o to, aby wiedzieć, co tracisz, gdy przechodzisz do NoSQL i tylko używać NoSQL do danych, które mogą ponieść takie straty.
Jimmy Hoffa
1
Chociaż to prawda, nie jest to odpowiedź na zadane pytanie.
vartec
To nie tylko NIE jest odpowiedź, ale także NIE jest to prawda. Możesz utworzyć dokument taki jak tabela w bazie danych SQL, używając tylko typu danych JSON i sprawić, że baza danych SQL będzie świecić nad NoSQL.
Jewgienij Afganijew
6

Jeśli relacyjne bazy danych nie skalują się, nic nie robi. Nie martw się problemami ze skalowaniem.

SQL ma problemy z niektórymi rodzajami analiz, ale do uruchomienia problemu nie potrzeba dużo danych. Rozważmy na przykład pojedynczą tabelę z kolumną, która odwołuje się do innych wierszy na podstawie unikalnego klucza. Zwykle można tego użyć do stworzenia struktury drzewa. Możesz pisać szybkie instrukcje SQL, które odwołują się do odpowiedniego wiersza. Lub powiązany wiersz. W rzeczywistości możesz wykonać dowolną liczbę skoków. Ale jeśli dla każdego wiersza chcesz wybrać pole w pierwszym pokrewnym wierszu w łańcuchu, który spełnia pewne kryterium, komplikuje się.

Rozważ tabelę lokalizacji biur na poziomie kraju, prowincji, województwa, miasta i wsi, przy czym każde biuro odnosi się do biura, do którego się zgłosi. Nie ma gwarancji, że biuro sprawozdawcze każdego biura jest tylko o jeden poziom wyżej. W przypadku wybranego zestawu biur, nie wszystkich na jednym poziomie, chcesz podać listę powiązanych biur krajowych. Wymaga to pętli instrukcji SQL i zajmie to dużo czasu nawet dzisiaj. (Kiedyś otrzymywałem 30 sekund w wybranych 30 biurach, ale to było dawno temu - i przejście do procedur przechowywanych trochę pomogło.)

Alternatywą jest więc umieszczenie całej struktury w jednym dużym bloku danych, oznaczenie jej i przechowanie. Kiedy chcesz przeanalizować dane, odczytaj je wszystkie do pamięci za jednym razem, konfigurując wskaźniki do śledzenia struktury, i możesz przetworzyć kilka milionów biur w mgnieniu oka.

Nic z tego nie ma wiele wspólnego z ilością danych. Kluczem jest charakter organizacji danych. Jeśli układ relacyjny pomaga, to RDBMS jest tym, czego potrzebujesz. Jeśli nie, jakiś rodzaj magazynowania masowego będzie szybszy od nieco do biliardów razy.

Pamiętaj, że jeśli jeden z tych zestawów danych stanie się zbyt duży, aby zmieścił się w pamięci, baza danych inna niż SQL nie będzie działać. Kolejnym problemem jest to, że potrzebujesz danych z więcej niż jednego bloku naraz; można to zrobić , jeżeli i tylko jeżeli wszystkie bloki zmieścić się w pamięci na raz. I użytkownik musi poczekać, aż je załadujesz.

Jeśli twoja relacyjna baza danych spowoduje problemy, zrobi to przed włożeniem do niej dużej ilości danych. Jedyny problem ze skalowaniem, jaki możesz mieć, to problem z programem, gdy blok danych, który gromadzisz dla bazy danych nosql - jeśli musisz go użyć - staje się dla niego za duży. (Przeczytaj o błędach braku pamięci. Nowsze języki czasami robią dziwne rzeczy z pamięcią).

RalphChapin
źródło
0

Myślę, że pierwszym powodem, aby przejść do rozwiązania NoSQL lub rozproszonego, jest nie tyle rozmiar wszystkich danych, co rozmiar tabel. Rozwiązania rozproszone dobrze dzielą dzielenie tabel na różne węzły, a następnie, gdy trzeba wykonać zapytanie do tabel, każdy węzeł przetworzy ich część tabeli.

RDBMS mogą to zrobić, ale została do tego stworzona nowa fala baz danych NoSQL. Oracle, MSSQL, MySQL wzięły swój scentralizowany model i poprawiły go, aby działał w środowisku rozproszonym. Nadal jednak stosują się one do ścisłych reguł ACID, podczas gdy niektóre nowe bazy danych nie przestrzegają ścisłych zasad, takich jak ostateczna spójność.

Nie ma określonej ilości danych, w których należy wybrać jedną z nich. To, co należy wziąć pod uwagę, to potrzeby bazy danych i wielkość korzystania z niej. Bazy danych NoSQL mogą szybciej przetwarzać większe zbiory danych, a relacyjne bazy danych dają pewność, że Twoje dane są poprawne z zasadami ACID.

DFord
źródło
0

Warto również wspomnieć, że Twój model danych ma duży wpływ na rzeczy. Jeśli potrzebujesz stworzyć jakąś formę struktury drzewa (tj. Masz samodzielnie odwołujący się klucz obcy w tabeli zawierającej wspomniany klucz obcy w złożonym kluczu podstawowym), prawdopodobnie powinieneś rozważyć zrobienie tego w jakiejś formie bazy danych, która obsługuje te klucze typy danych naprawdę dobrze (takie jak mongodb lub couchdb).

Podobnie jak inni powiedzieli, powinieneś również wziąć pod uwagę to, co dzieje się w Twojej aplikacji. jeśli naprawdę potrzebujesz ACID w wielu tabelach, to naprawdę musisz trzymać się RDBMS, ale jeśli masz coś, w czym możesz mieć trochę nieco przestarzałe dane i potrzebujesz elastyczności schematu NoSQL (nazwij to schematem, jeśli chcesz, ale to nadal ma jakąś formę niejawnego schematu), możesz rozważyć pobranie sklepu NoSQL ( http://www.10gen.com/customers/craigslist) Oto przykład, dlaczego craigslist się zmienił ... ale trzeba przyznać, że archiwizują ~ 10 TB dane, o których wiem, że w ogóle nie mieszczą się w twojej małej i średniej wielkości bazie danych. Ale przypadek użycia może być pomocny).

Należy pamiętać, że systemy NoSQL niekoniecznie są w stanie zastąpić RDMS, ale w wielu przypadkach można uzupełnić RDBMS dzięki idei Polyglot Persistence i można przechowywać większość danych w RDBMS, ale w konkretnych niszowych przypadkach możesz odciążyć część swoich dane do jakiejś formy sklepu NoSQL.

harageth
źródło
0

Mongomożna zainstalować na wielu komputerach / węzłach. PostgreSQLnie zapewnia wbudowanego narzędzia do dzielenia na fragmenty, jednak citus jest w pobliżu.

MongoDB obsługuje bazy danych do 64 terabajtów, a rozmiar dokumentu to 16 megabajtów.

MySQL ma limit bazy danych 256 terabajtów, 64 terabajty maksymalny rozmiar tabeli i limit rekordów 4 gigabajty

PostgreSQL nie ma limitu bazy danych (gdzieś istnieją 4 terabajty do testowania) i ma limit 1 gigabajta dla rozmiaru dowolnego pola w tabeli i ponownie 64 terabajty maksymalnego rozmiaru dla tabeli.

Jewgienij Afanasiew
źródło