Uprzejma interpretacja „NoSQL” stała się Not Only SQL . Jeśli masz dane, które rzeczywiście są relacyjne lub jeśli twoja funkcjonalność zależy od takich rzeczy, jak złączenia i ACIDity, powinieneś przechowywać te dane w sposób relacyjny. W tym poście wyjaśnię, w jaki sposób używam MySQL obok dwóch Magazyny danych NoSQL. Nowoczesne przechowywanie danych w skali internetowej polega na zrozumieniu, jak wybrać najlepsze narzędzie do pracy.
To powiedziawszy, NoSQL jest tak naprawdę reakcją na fakt, że relacyjna metoda i sposób myślenia zostały zastosowane do problemów, w których nie jest to zbyt dobre dopasowanie (zazwyczaj ogromne tabele z dziesiątkami milionów wierszy lub więcej). Gdy tabele stają się tak duże, typową „najlepszą praktyką” SQL jest ręczne oddzielanie dane -- czyli umieszczenie rekordów od 1 do 10 000 000 w tabeli A, od 10 000 001 do 20 000 001 w tabeli B i tak dalej. Następnie, zazwyczaj w warstwie modelu aplikacji, wyszukiwania są wykonywane według tego schematu. To się nazywa application-aware skalowanie. Jest to czasochłonne i podatne na błędy, ale aby skalować coś w górę przy jednoczesnym utrzymaniu MySQL do przechowywania długich tabel, stało się mniej lub bardziej standardowym MO. NoSQL reprezentuje, według mnie, application-unaware alternatywa.
Wartość klucz-wartość
Kiedy mój prototyp MySQL zaczął stawać się zbyt duży dla własnego dobra, osobiście przeniosłem jak najwięcej danych do błyskawicznej Membase , który przewyższa Memcached i dodaje trwałości. Membase to rozproszony magazyn klucz-wartość, który skaluje się mniej więcej liniowo (na przykład Zynga używa go do obsługi pół miliona operacji na sekundę) poprzez dodanie większej liczby serwerów towarowych do klastra – dlatego jest świetny pasuje do wieku chmur Amazon EC2 , Radość itp.
Powszechnie wiadomo, że rozproszone sklepy typu klucz-wartość to najlepszy sposób na uzyskanie ogromnej, liniowej skali. Słabością pary klucz-wartość jest możliwość odpytywania i indeksowanie. Ale nawet w świecie relacyjnym najlepszą praktyką w zakresie skalowalności jest przeniesienie jak największej ilości wysiłku na serwery aplikacji, wykonując połączenia w pamięci na popularnych serwerach aplikacji, zamiast prosić centralny klaster RDB o obsługę całej tej logiki. Od simple select plus application logic są naprawdę najlepszym sposobem na osiągnięcie masowej skali nawet MySQL, przejście do czegoś takiego jak Membase (lub jego konkurenci, jak Riak
) nie jest tak źle.
Sklepy z dokumentami
Czasami – choć spierałbym się rzadziej niż wielu myśli – projekt aplikacji z natury wymaga indeksów drugorzędnych, możliwości zapytań o zakres itp. Podejście do tego w NoSQL polega na wykorzystaniu document store jak MongoDB
. Podobnie jak Membase, Mongo sprawdza się bardzo dobrze w niektórych obszarach, w których relacyjne bazy danych są szczególnie słabe, np. application-unaware skalowanie, auto-sharding i maintaining flat response times even as dataset size balloons . Jest znacznie wolniejszy niż Membase i nieco trudniejszy do wykonania czystej skali poziomej, ale korzyścią jest to, że jest wysoce dyskusyjny. Możesz wyszukiwać parametry i zakresy w czasie rzeczywistym lub możesz użyć funkcji Map/Reduce do wykonywania złożonych operacji wsadowych na naprawdę ogromnych zestawach danych.
W tym samym projekcie, o którym wspomniałem powyżej, który wykorzystuje Membase do obsługi ton danych graczy na żywo, używamy MongoDB do przechowywania danych analitycznych/metrycznych, co naprawdę jest obszarem, w którym MongoDB błyszczy.
Dlaczego trzymać rzeczy w SQL
Krótko wspomniałem o tym, że „prawdziwie relacyjne” informacje powinny pozostać w relacyjnych bazach danych. Jak zauważa komentator Dan K., przegapiłem część, w której omawiam wady pozostawienia RDBMS, a przynajmniej całkowitego opuszczenia go.
Po pierwsze, sam SQL. SQL jest dobrze znany i od dawna jest standardem branżowym. Niektóre bazy danych „NoSQL”, takie jak App Engine
Google Datastore (zbudowany na Big Table) implementuje własny język podobny do SQL (Google nazywa się słodko GQL od Google Query Language ). MongoDB prezentuje świeże podejście do problemu zapytań dzięki swoim wspaniałym obiektom zapytań JSON
. Mimo to sam SQL jest potężnym narzędziem do wydobywania informacji z danych, co często jest podstawą baz danych.
Najważniejszym powodem pozostania przy RDBMS jest ACID
lub Atomicity, Consistency, Isolation, Durability . Nie będę ponownie haszować stanu Acid-NoSQL, ponieważ jest on dobrze zaadresowany w ten post
Na tak. Wystarczy powiedzieć, że istnieje racjonalny powód Systemy baz danych Oracle
ma tak ogromny rynek, że nigdzie się nie wybiera:niektóre dane wymagają czystej zgodności z ACID . Jeśli twoje dane tak (a jeśli tak, prawdopodobnie dobrze zdajesz sobie z tego sprawę), to samo dotyczy twojej bazy danych. Zachowaj to pH
niski!
Edytuj: Sprawdź post Aaronaughta tutaj. Reprezentuje on perspektywę business-to-business znacznie lepiej niż ja, po części dlatego, że spędziłem całą swoją karierę w przestrzeni konsumenckiej.
