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

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).

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.

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.

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ą).

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.

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.

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.