Słyszałem wiele rzeczy o NoSQL i że może on w końcu stać się zamiennikiem metod przechowywania danych SQL DB, ponieważ interakcja z DB często ogranicza szybkość w Internecie.
Mam więc tylko kilka pytań:
Co to właściwie jest?
Jak to działa?
Dlaczego miałoby to być lepsze niż korzystanie z bazy danych SQL? A o ile lepiej?
Czy technologia jest zbyt nowa, aby rozpocząć wdrażanie, czy też warto się jej przyjrzeć?
Odpowiedzi:
Co to właściwie jest?
Z jednej strony konkretny system , ale stało się też ogólnym określeniem dla różnych nowych backendów do przechowywania danych , które nie są zgodne z relacyjnym modelem bazy danych.
Jak to działa?
Każdy z systemów oznaczonych nazwą ogólną działa inaczej, ale podstawową ideą jest zaoferowanie lepszej skalowalności i wydajności przy użyciu modeli bazy danych, które nie obsługują wszystkich funkcji ogólnego systemu RDBMS, ale są wystarczająco funkcjonalne, aby były przydatne. W pewnym sensie przypomina MySQL, który kiedyś nie obsługiwał transakcji, ale właśnie z tego powodu radził sobie lepiej niż inne systemy baz danych. Gdybyś mógł napisać swoją aplikację w sposób, który nie wymagałby transakcji, było świetnie.
Dlaczego miałoby to być lepsze niż korzystanie z bazy danych SQL? A o ile lepiej?
Byłoby lepiej, gdyby Twoja witryna musiała skalować się tak masowo, że najlepszy RDBMS działający na najlepszym sprzęcie, na jaki możesz sobie pozwolić i zoptymalizowany w jak największym stopniu, po prostu nie nadąża za obciążeniem. To, o ile jest lepsze, zależy od konkretnego przypadku użycia (duża aktywność aktualizacji połączona z dużą liczbą złączeń jest bardzo trudna w przypadku „tradycyjnych” systemów RDBMS) - w skrajnych przypadkach może to być współczynnik 1000.
Czy technologia jest zbyt nowa, aby rozpocząć wdrażanie, czy też warto się jej przyjrzeć?
Zależy głównie od tego, co próbujesz osiągnąć. Z pewnością jest wystarczająco dojrzały, aby go używać. Ale niewiele aplikacji naprawdę wymaga tak dużej skali. W większości przypadków wystarczy tradycyjny system RDBMS. Jednak w miarę jak korzystanie z Internetu staje się coraz bardziej wszechobecne, jest całkiem prawdopodobne, że aplikacje, które to robią, staną się bardziej powszechne (choć prawdopodobnie nie dominujące).
źródło
transaction?Nie ma czegoś takiego jak NoSQL!
NoSQL to modne hasło.
Przez dziesięciolecia, kiedy ludzie mówili o bazach danych, mieli na myśli relacyjne bazy danych. A kiedy ludzie mówili o relacyjnych bazach danych, mieli na myśli tych, których kontrolujesz za pomocą Structured Query Language Edgara F. Codda. Przechowywanie danych w inny sposób? Szaleństwo! Wszystko inne to zwykłe pliki.
Ale w ciągu ostatnich kilku lat ludzie zaczęli kwestionować ten dogmat. Ludzie zastanawiali się, czy tabele z wierszami i kolumnami są naprawdę jedynym sposobem reprezentowania danych. Ludzie zaczęli myśleć i kodować, a także wymyślili wiele nowych koncepcji, jak organizować dane. Zaczęli tworzyć nowe systemy baz danych przeznaczone do tych nowych sposobów pracy z danymi.
Filozofie wszystkich tych baz danych były różne. Ale jedną wspólną cechą wszystkich tych baz danych było to, że Structured Query Language nie nadawał się już do ich używania. Dlatego każda baza danych zastąpiła SQL własnym językiem zapytań. I tak narodził się termin NoSQL, jako etykieta dla wszystkich technologii baz danych, które są sprzeczne z klasycznym modelem relacyjnej bazy danych.
Co więc mają wspólnego bazy danych NoSQL?
Właściwie niewiele.
Często słyszysz takie zwroty jak:
Czy to prawda? Cóż, niektóre z tych stwierdzeń mogą być prawdziwe w przypadku niektórych baz danych powszechnie nazywanych NoSQL, ale każda z nich jest fałszywa przynajmniej dla jednej innej. Właściwie jedyną wspólną cechą baz danych NoSQL jest to, że są to bazy danych, które nie używają SQL. Otóż to. Jedyne, co je definiuje, to to, co je od siebie różni.
Co więc wyróżnia bazy danych NoSQL?
Dlatego wyjaśniliśmy, że wszystkie te bazy danych, powszechnie określane jako NoSQL, są zbyt różne, aby oceniać je razem. Każdy z nich wymaga oddzielnej oceny, aby zdecydować, czy dobrze nadaje się do rozwiązania konkretnego problemu. Ale od czego zaczynamy? Na szczęście bazy danych NoSQL można pogrupować w określone kategorie, które są odpowiednie dla różnych przypadków użycia:
Zorientowany na dokumenty
Przykłady: MongoDB, CouchDB
Mocne strony: heterogeniczne dane, praca zorientowana obiektowo, zwinny rozwój
Ich zaletą jest to, że nie wymagają spójnej struktury danych. Są przydatne, gdy Twoje wymagania, a tym samym układ bazy danych, stale się zmieniają, lub gdy masz do czynienia z zestawami danych, które należą do siebie, ale nadal wyglądają zupełnie inaczej. Jeśli masz wiele tabel z dwiema kolumnami zwanymi „klucz” i „wartość”, warto się tym przyjrzeć.
Grafowe bazy danych
Przykłady: Neo4j, GiraffeDB.
Mocne strony: eksploracja danych
Podczas gdy większość baz danych NoSQL porzuca koncepcję zarządzania relacjami danych, bazy te obejmują ją nawet bardziej niż tzw. Relacyjne bazy danych.
Skupiają się na definiowaniu danych na podstawie ich relacji do innych danych. Jeśli masz wiele tabel z kluczami podstawowymi, które są kluczami podstawowymi dwóch innych tabel (i być może jakieś dane opisujące relacje między nimi), może to być coś dla Ciebie.
Magazyny klucz-wartość
Przykłady: Redis, Cassandra, MemcacheDB
Mocne strony: Szybkie wyszukiwanie wartości za pomocą znanych kluczy
Są bardzo uproszczone, ale dzięki temu są szybkie i łatwe w użyciu. Jeśli nie potrzebujesz procedur składowanych, ograniczeń, wyzwalaczy i wszystkich tych zaawansowanych funkcji bazy danych, a potrzebujesz tylko szybkiego przechowywania i pobierania danych, to są one dla Ciebie.
Niestety zakładają, że dokładnie wiesz, czego szukasz. Potrzebujesz profilu User157641? Żaden problem, zajmie to tylko mikrosekundy. Ale co, jeśli chcesz, aby nazwiska wszystkich użytkowników w wieku od 16 do 24 lat miały „gofry” jako swoje ulubione jedzenie i zalogowały się w ciągu ostatnich 24 godzin? Pech. Kiedy nie masz określonego i unikalnego klucza do określonego wyniku, nie możesz go tak łatwo wyciągnąć ze swojego sklepu KV.
Czy SQL jest przestarzały?
Niektórzy zwolennicy NoSQL twierdzą, że ich ulubiona baza danych NoSQL to nowy sposób robienia rzeczy, a SQL należy do przeszłości.
Czy mają rację?
Nie, oczywiście, że nie. Chociaż istnieją problemy, do których język SQL nie jest odpowiedni, nadal ma swoje mocne strony. Wiele modeli danych najlepiej przedstawia się jako zbiór tabel, które odnoszą się do siebie nawzajem. Zwłaszcza, że większość programistów baz danych przez dziesięciolecia była szkolona w myśleniu o danych w sposób relacyjny, a próby narzucenia tego sposobu myślenia nowej technologii, która nie została stworzona do tego celu, rzadko kończy się dobrze.
Bazy danych NoSQL nie zastępują SQL - są alternatywą.
Większość ekosystemów oprogramowania wokół różnych baz danych NoSQL nie jest jeszcze tak dojrzała. Chociaż są postępy, nadal nie masz dodatkowych narzędzi, które byłyby tak dojrzałe i wydajne, jak te dostępne dla popularnych baz danych SQL.
Ponadto istnieje znacznie więcej wiedzy na temat języka SQL. Pokolenia informatyków spędzały dziesięciolecia swojej kariery na badaniach koncentrujących się na relacyjnych bazach danych i pokazuje: Literatura napisana na temat baz danych SQL i modelowania danych relacyjnych, zarówno praktyczna, jak i teoretyczna, mogłaby wypełnić wiele bibliotek pełnych książek. Jak zbudować relacyjną bazę danych dla swoich danych, to temat tak dobrze zbadany, że trudno jest znaleźć przypadek narożny, w którym nie ma ogólnie przyjętej najlepszej praktyki.
Z drugiej strony większość baz danych NoSQL jest wciąż w powijakach. Wciąż szukamy najlepszego sposobu ich wykorzystania.
źródło
Ponieważ ktoś powiedział, że mój poprzedni post był poza tematem, spróbuję to zrekompensować :-) NoSQL nie jest i nigdy nie był przeznaczony do zastąpienia bardziej popularnych baz danych SQL, ale wystarczy kilka słów, aby uzyskać rzeczy z właściwej perspektywy.
W samym sercu filozofii NoSQL leży założenie, że prawdopodobnie ze względów komercyjnych i przenośnych silniki SQL mają tendencję do ignorowania ogromnej mocy systemu operacyjnego UNIX i jego pochodnych.
Dzięki bazie danych opartej na systemie plików możesz natychmiast skorzystać z ciągle rosnących możliwości i mocy podstawowego systemu operacyjnego, które od wielu lat stale rosną, zgodnie z prawem Moore'a. Przy takim podejściu wiele poleceń systemu operacyjnego staje się automatycznie także „operatorami baz danych” (pomyśl o „ls”, „sort”, „find” i innych niezliczonych narzędziach powłoki UNIX).
Mając to na uwadze i odrobinę kreatywności, możesz rzeczywiście opracować bazę danych opartą na systemie plików, która jest w stanie przezwyciężyć ograniczenia wielu popularnych silników SQL, przynajmniej w przypadku określonych wzorców użycia, co jest głównym celem filozofii NoSQL, tak to widzę.
Prowadzę setki witryn internetowych i wszystkie używają NoSQL w mniejszym lub większym stopniu. W rzeczywistości nie przechowują one ogromnych ilości danych, ale nawet gdyby niektóre z nich tak było, prawdopodobnie mógłbym pomyśleć o kreatywnym wykorzystaniu NoSQL i systemu plików do pokonania wszelkich wąskich gardeł. Coś, co prawdopodobnie byłoby trudniejsze w przypadku tradycyjnych „więzień” SQL. Zachęcam do wyszukania w wyszukiwarce „unix”, „manis” i „shaffer”, aby zrozumieć, co mam na myśli.
źródło
Jeśli dobrze pamiętam, odnosi się do typów baz danych, które niekoniecznie mają formę relacyjną. Przychodzą na myśl bazy danych dokumentów, bazy danych bez określonej struktury i które nie używają SQL jako określonego języka zapytań.
Generalnie lepiej nadaje się do aplikacji internetowych, które opierają się na wydajności bazy danych i nie wymagają bardziej zaawansowanych funkcji silników relacyjnych baz danych. Na przykład magazyn Klucz-> Wartość zapewniający proste zapytanie przez interfejs id może być 10-100x szybszy niż odpowiadająca mu implementacja serwera SQL, przy niższych kosztach utrzymania dewelopera.
Jednym z przykładów jest ten dokument dotyczący magazynu krotek OLTP , który poświęcił transakcje na potrzeby przetwarzania jednowątkowego (brak problemu z współbieżnością, ponieważ współbieżność nie jest dozwolona) i zachował wszystkie dane w pamięci; osiągając 10-100x lepszą wydajność w porównaniu z podobnym systemem opartym na RDBMS . Zasadniczo odchodzi od widoku „Jeden rozmiar pasuje do wszystkich” SQL i systemów baz danych.
źródło
W praktyce NoSQL jest systemem baz danych, który obsługuje szybki dostęp do dużych obiektów binarnych (dokumenty, pliki jpg itp.) Przy użyciu strategii dostępu opartej na kluczach. Jest to odejście od tradycyjnego dostępu SQL, który jest wystarczający tylko dla wartości alfanumerycznych. Nie tylko wewnętrzna strategia przechowywania i dostępu, ale także składnia i ograniczenia formatu wyświetlania ograniczają tradycyjny SQL. Implementacje BLOB tradycyjnych relacyjnych baz danych również cierpią z powodu tych ograniczeń.
Za kulisami jest to pośrednie przyznanie się, że model SQL nie obsługuje jakiejkolwiek formy OLTP lub wsparcia dla nowych formatów danych. „Wsparcie” oznacza nie tylko przechowywanie, ale także pełny dostęp - programistyczny i oparty na zapytaniach przy użyciu modelu standardowego.
Entuzjaści relacji relacyjnych szybko zmienili definicję NoSQL z Not-SQL na Not-Only-SQL, aby SQL nadal był widoczny! Nie jest to dobre, zwłaszcza gdy widzimy, że większość programów Java korzysta obecnie z mapowania ORM bazowego modelu relacyjnego. Nowa koncepcja musi mieć jasną definicję. W przeciwnym razie skończy się jak SOA.
Podstawą systemów NoSQL jest losowa para klucz-wartość. Ale to nie jest nowe. Tradycyjne systemy baz danych, takie jak IMS i IDMS, obsługiwały zaszyfrowane klucze ramdom (bez użycia jakiegokolwiek indeksu) i nadal to obsługują. W rzeczywistości IDMS ma już słowo kluczowe NONSQL, które obsługuje dostęp SQL do ich starszej sieciowej bazy danych, którą nazwali NONSQL.
źródło
To jak jacuzzi: zarówno marka, jak i ogólna nazwa. Nie jest to tylko konkretna technologia, ale raczej określony typ technologii, w tym przypadku odnoszący się do dużych (często rzadkich) „baz danych”, takich jak BigTable Google czy CouchDB.
źródło
NoSQL rzeczywisty program wydaje się być relacyjną bazą danych zaimplementowaną w awk przy użyciu płaskich plików na zapleczu. Chociaż twierdzą, że „NoSQL zasadniczo nie ma arbitralnych ograniczeń i może działać tam, gdzie inne produkty nie mogą. Na przykład nie ma ograniczeń co do rozmiaru pola danych, liczby kolumn lub rozmiaru pliku”, nie sądzę, że tak jest wielkoskalowa baza danych przyszłości.
Jak mówi Joel, masowo skalowalne bazy danych, takie jak BigTable czy HBase , są znacznie bardziej interesujące. GQL to język zapytań powiązany z BigTable i App Engine. Jest w dużej mierze zmodyfikowany w języku SQL, aby uniknąć funkcji, które Google uważa za wąskie gardła (takie jak łączenia). Jednak nie słyszałem wcześniej o tym jako „NoSQL”.
źródło
NoSQL to system bazy danych, który nie używa zapytań SQL opartych na ciągach znaków do pobierania danych.
Zamiast tego tworzysz zapytania za pomocą API, które zapewnią, na przykład Amazon DynamoDB jest dobrym przykładem bazy danych NoSQL.
Bazy danych NoSQL są lepsze w przypadku dużych aplikacji, w których ważna jest skalowalność.
źródło
Tak, NoSQL różni się od RDBMS i OLAP. Wykorzystuje luźniejsze modele spójności niż tradycyjne relacyjne bazy danych.
Modele spójności są używane w systemach rozproszonych, takich jak rozproszone systemy pamięci współużytkowanej lub rozproszone magazyny danych.
Systemy baz danych NoSQL są często wysoce zoptymalizowane pod kątem operacji pobierania i dołączania i często oferują niewiele funkcji poza przechowywaniem rekordów (np. Magazyny wartości klucza). Zmniejszona elastyczność w czasie wykonywania w porównaniu z pełnymi systemami SQL jest kompensowana przez znaczny wzrost skalowalności i wydajności niektórych modeli danych.
Może działać na danych strukturalnych i nieustrukturyzowanych. Używa kolekcji zamiast tabel
Obejrzyj SQL vs NoSQL: Battle of the Backends ; to wszystko wyjaśnia.
źródło