NoSQL — co to jest i kiedy się go używa

NoSQL to rodzina nierelacyjnych baz danych. Przechowują one informacje w innych formach niż tabele relacyjne¹. W tym artykule wyjaśniamy, kiedy takie bazy się przydają i jak ocenić ich dopasowanie do aplikacji. W badaniu Stack Overflow Developer Survey 2024 korzystanie z MongoDB zadeklarowało 24,8% osób odpowiadających na pytanie o bazy danych².

Czym jest NoSQL i jak działa?

W NoSQL sposób zapisu i odczytu zależy od wybranego modelu danych, a nie od wspólnego dla wszystkich baz układu tabel. Aplikacja zapisuje rekord zgodnie z tym modelem, a później pobiera go metodami dostępnymi w danej bazie. W DynamoDB pojedynczy element może mieć maksymalnie 400 KB; limit obejmuje nazwy i wartości atrybutów³.

Model określa, czym jest rekord i jak odnaleźć informacje z nim związane. Projekt warto więc zacząć od pytań aplikacji: czy pobiera cały obiekt, szuka wartości po kluczu, przegląda zakres danych, czy bada powiązania między obiektami⁴.

Jakie są typy baz NoSQL?

Bazy NoSQL dzieli się przede wszystkim według sposobu przechowywania danych i dostępu do nich. Oracle wyróżnia 4 główne typy takich baz¹.

• Baza dokumentowa zapisuje dane w dokumentach opisujących obiekty. Sprawdza się, gdy aplikacja pobiera obiekt razem z jego atrybutami.
• Baza klucz–wartość przypisuje wartość do identyfikującego ją klucza. Pasuje do odczytu, w którym aplikacja zna szukany klucz.
• Baza szerokokolumnowa układa dane z myślą o odczycie wybranych kolumn. Jej strukturę trzeba zaprojektować pod przewidywane zapytania.
• Baza grafowa zapisuje obiekty i relacje między nimi. Pomaga odpowiadać na pytania o połączenia oraz ścieżki między obiektami.

O wyborze modelu decyduje to, jak aplikacja odczytuje dane: jako dokument, wartość pod kluczem, określony układ kolumn lub sieć relacji. Punktem wyjścia są pytania zadawane bazie. W Redis polecenie GET pobiera wartość po kluczu ze złożonością czasową O(1)⁵.

Jak bazy NoSQL organizują i odczytują dane?

Bazy NoSQL organizują rekordy według wybranego modelu, lecz do odczytu używają mechanizmów właściwych dla konkretnego produktu. Najpierw trzeba ustalić, czego aplikacja szuka i jak identyfikuje te dane. MongoDB podczas tworzenia kolekcji automatycznie zakłada unikalny indeks na polu _id, które identyfikuje dokumenty⁶.

• Identyfikator rekordu określa, po czym aplikacja znajduje dane. Może to być klucz, identyfikator dokumentu albo punkt rozpoczęcia przechodzenia po relacjach.
• Układ danych powinien odpowiadać planowanym odczytom. Aplikacja może pobierać cały obiekt lub wybierać rekordy spełniające warunki zapytania.
• Metoda zapytania zależy od możliwości bazy. Produkty NoSQL mogą udostępniać interfejsy API, deklaratywne i strukturalne języki zapytań oraz QBE, czyli zapytania na podstawie przykładów¹.

Odczyt i zapis trzeba zaprojektować razem. Postać rekordu oraz metoda zapytania powinny służyć temu samemu zadaniu aplikacji. Pojedyncze wywołanie Query w DynamoDB odczytuje najwyżej 1 MB danych; większy zbiór wyników wymaga kolejnych wywołań⁷.

Czym są modele danych NoSQL i jakie operacje obsługują?

Model danych NoSQL określa zarówno postać rekordu, jak i sposób jego odnalezienia. Główne modele to klucz–wartość, dokumentowy, grafowy i kolumnowy¹. Każdy pozwala tworzyć, odczytywać, aktualizować i usuwać dane. Różnią się jednak sposobem wskazania rekordu oraz zakresem możliwych zmian.

Podział baz nierelacyjnych według modelu danych

Podział baz nierelacyjnych wynika z tego, co uznają za jednostkę zapisu i jak aplikacja ją wyszukuje. Model należy zestawić z zapytaniami po identyfikatorze, atrybutach obiektu, układzie kolumn lub relacjach. Dokumentacja Apache Cassandra zaleca, aby partycja na dysku nie przekraczała 100 MB⁸.

Tabela zestawia modele NoSQL według jednostki zapisu, sposobu odczytu i zadania aplikacji.

Dane w tabeli: 9

Czym różnią się bazy dokumentowe, klucz–wartość, szerokokolumnowe i grafowe?

Bazy dokumentowe, klucz–wartość, szerokokolumnowe i grafowe różnią się głównie sposobem odnajdywania danych. JSON jest tekstowym formatem zapisu pól i wartości. Dokumenty często używają go do przedstawiania obiektów o zmiennych atrybutach, takich jak wpisy w katalogu produktów⁹. Model klucz–wartość odpowiada z kolei buforowaniu danych i wyszukiwaniu po znanym kluczu⁹. RFC 8259 opisuje sześć typów wartości JSON: obiekt, tablicę, liczbę, ciąg znaków, wartość logiczną i null¹⁰.

W bazie szerokokolumnowej układ danych trzeba przygotować pod spodziewane odczyty; baza grafowa służy zaś do poruszania się między powiązanymi obiektami. Wybór zależy od pytania aplikacji: o zawartość obiektu, klucz, zakres danych czy relację. W Neo4j pojedyncza relacja łączy węzeł początkowy z końcowym, przy czym oba mogą być tym samym węzłem¹¹.

Przykłady produktów relacyjnych i nierelacyjnych

Produkt relacyjny układa dane w tabelach i określa powiązania między nimi. Produkt nierelacyjny może natomiast oferować model dokumentowy, klucz–wartość, kolumnowy lub grafowy. Nazwa dostawcy nie mówi, jak działa konkretny produkt; trzeba poznać jego jednostkę zapisu i sposób odczytu. Produkt dokumentowy warto porównywać z relacyjnym pod kątem pracy z obiektami, nie utożsamiając obu kategorii. DynamoDB obsługuje dwa modele danych: klucz–wartość oraz dokumentowy¹².

Jak tworzyć, odczytywać, aktualizować i usuwać dane?

Operacje CRUD obejmują tworzenie (create), odczyt (read), aktualizację (update) i usuwanie (delete) danych. Aplikacja wykonuje je na jednostce właściwej dla danego modelu:

• Tworzenie danych oznacza zapis nowego dokumentu, pary klucza i wartości, rekordu kolumnowego albo węzła lub relacji grafu.
• Odczyt danych wymaga wskazania rekordu identyfikatorem, warunkiem dotyczącym pól, układem kluczy lub ścieżką powiązań.
• Aktualizacja danych zmienia wartość lub atrybut wskazanego obiektu. Zakres zmiany zależy od bazy i przyjętego modelu¹³.
• Usuwanie danych usuwa wskazany rekord bądź powiązanie według reguł konkretnej bazy.

Model NoSQL pasuje do aplikacji, jeśli pozwala jednoznacznie wskazać dane przy każdej wymaganej operacji CRUD. W MongoDB pole _id może zawierać identyfikator ObjectId o rozmiarze 12 bajtów¹⁴.

Czym jest baza NoSQL w architekturze danych i kiedy warto ją wybrać?

Bazę NoSQL warto wybrać, gdy jej sposób zapisu odpowiada danym i odczytom aplikacji. Trzeba przy tym ocenić nie tylko format rekordu, lecz także zapytania, aktualizacje i przekazywanie danych do analizy. DynamoDB Streams przechowuje rekordy zmian przez 24 godziny. Tyle czasu pozostaje na przekazanie ich do dalszych systemów¹⁵.

Wzorzec dostępu opisuje, jak aplikacja wyszukuje i pobiera dane. Projektowanie NoSQL pod takie wzorce oraz denormalizacja – wspólny zapis powiązanych informacji – mogą zmniejszyć potrzebę kosztownych złączeń¹⁶. Odczyt przebiega wtedy zgodnie z planem, ale aktualizacje wymagają uwzględnienia informacji zapisanych w powiązanych miejscach¹⁷.

Jak sposób przechowywania danych wpływa na ich organizację?

Sposób przechowywania decyduje, czy informacje o obiekcie leżą razem, czy aplikacja musi szukać ich powiązań. Układ rekordu powinien wynikać z pytań kierowanych do bazy. W MongoDB dokument BSON może mieć maksymalnie 16 MiB. Ten limit ogranicza ilość powiązanych danych, które można przechowywać razem¹⁸.

• Odczyt całego obiektu przemawia za wspólnym zapisem pól pobieranych przez aplikację jako całość.
• Odczyt po identyfikatorze wymaga jednoznacznego klucza prowadzącego do właściwego rekordu.
• Odczyt powiązań wymaga takiego zapisu relacji, po którym aplikacja potrafi się poruszać.
• Aktualizacja powtarzanych informacji wymaga ustalenia, które zapisy należy zmienić, by zachować spójność danych.

Dobry układ danych obsługuje wymagany odczyt, ale nie utrudnia późniejszych zmian rekordu.

Kiedy model nierelacyjny odpowiada potrzebom aplikacji?

Model nierelacyjny pasuje do aplikacji, gdy jej dane i odczyty odpowiadają dokumentom, kluczom, układowi kolumn lub relacjom grafowym. Elastyczny schemat pozwala różnicować pola między rekordami, co przydaje się przy obiektach o zmiennych atrybutach. Sama zmienność pól nie wystarcza jednak do wyboru bazy. Aplikacja musi jeszcze odnajdywać rekordy i poprawnie je aktualizować¹⁹.

Jak ocenić dopasowanie bazy do danych i sposobu ich użycia?

Ocena bazy NoSQL wymaga zestawienia struktury danych z działaniami aplikacji. Ta lista prowadzi od potrzebnych zapytań do skutków wybranego sposobu zapisu:

• Zapytania aplikacji warto opisać przez dane wejściowe i oczekiwany wynik, na przykład identyfikator obiektu oraz pola zwracane użytkownikowi.
• Jednostka zapisu powinna odpowiadać danym pobieranym razem: dokumentowi, wartości pod kluczem, rekordowi kolumnowemu albo węzłowi i relacji.
• Zmiany danych trzeba prześledzić dla pól edytowanych przez aplikację, szczególnie gdy ta sama informacja występuje w różnych zapisach.
• Potrzeby analityczne należy uwzględnić obok odczytów operacyjnych, jeżeli baza ma zasilać raporty lub dashboardy.

O dopasowaniu świadczy zgodność modelu zapisu z zapytaniami, aktualizacjami i dalszym wykorzystaniem danych.

Jaki produkt może posłużyć za przykład bazy nierelacyjnej?

Oracle NoSQL Database jest produktem z kategorii baz nierelacyjnych. Nazwy produktu nie należy jednak mylić z modelem danych: nie opisuje ona ani postaci rekordu, ani wymagań aplikacji. Przykład pomaga rozpoznać kategorię. O wyborze konkretnej bazy nadal rozstrzygają potrzebne operacje na danych.

Czym jest model relacyjny, a czym nierelacyjny?

Model relacyjny układa dane w tabelach połączonych kluczami. Model nierelacyjny korzysta z innej jednostki zapisu, choćby dokumentu albo pary klucza i wartości. Różnica dotyczy struktury danych oraz sposobu odczytywania powiązań. Decyzję warto oprzeć na danych i zapytaniach aplikacji, a nie na nazwie kategorii.

Co definiuje relacyjną i nierelacyjną bazę danych?

Bazę relacyjną opisują tabele, wiersze i relacje określone kluczami. Bazę nierelacyjną wyróżnia wybrany model organizacji rekordów poza układem tabel relacyjnych. W tej pierwszej identyfikator może łączyć wiersze z różnych tabel. W drugiej sposób wskazania rekordu i jego powiązań zależy od modelu.

Jak różnią się schematy i relacje między danymi?

Schemat danych opisuje strukturę rekordów, a relacje wskazują powiązania między nimi. Porównując modele, trzeba ustalić, jak definiują pola, gdzie zapisują powiązania i jak aplikacja je odczytuje.

Tabela porównuje model relacyjny i nierelacyjny pod względem definicji pól oraz zapisu powiązań.

Dane w tabeli: 1,20

Elastyczny schemat nie zwalnia aplikacji z określenia pól potrzebnych przy zapisie i odczycie. Zmienia się miejsce definiowania struktury: może nią zarządzać schemat bazy albo reguły przyjęte dla rekordów i aplikacji.

Co oznaczają pojęcia SQL i NoSQL?

SQL to Structured Query Language, język służący między innymi do tworzenia zapytań do relacyjnych baz danych. NoSQL oznacza kategorię nierelacyjnych sposobów przechowywania danych, nie wspólny język takich baz. Jedno pojęcie nazywa więc język, a drugie – kategorię modeli.

Czy NoSQL jest językiem zapytań, tak jak SQL?

NoSQL nie jest językiem zapytań na wzór SQL. Sposób odczytu trzeba poznać dla konkretnej bazy nierelacyjnej i jej modelu danych.

• Model danych wskazuje jednostkę odczytywaną przez aplikację, na przykład dokument lub wartość przypisaną do klucza.
• Warunek odczytu określa, po czym aplikacja znajdzie potrzebny rekord.
• Interfejs bazy określa, jak przekazać warunek i odebrać wynik.

SQL nazywa język; NoSQL nie narzuca wszystkim bazom jednego sposobu zadawania pytań.

Czym jest baza danych SQL i jakie są jej przykłady?

Baza danych SQL to zwykle baza relacyjna: przechowuje dane w tabelach, a język SQL pozwala je wyszukiwać i zmieniać. O zaliczeniu produktu do tej kategorii powinien decydować jego model danych. Sama obsługa SQL nie wystarczy.

Jak działa baza danych oparta na tabelach?

Baza oparta na tabelach zapisuje rekordy w wierszach, a ich atrybuty w kolumnach. Odczyt opiera się na następujących elementach:

• Tabela grupuje rekordy tego samego rodzaju, na przykład zamówienia.
• Klucz główny jednoznacznie identyfikuje wiersz, który aplikacja chce pobrać lub zmienić.
• Klucz obcy wskazuje powiązany wiersz innej tabeli, na przykład klienta przypisanego do zamówienia.
• Zapytanie SQL wybiera potrzebne wiersze i kolumny, a także może łączyć dane z powiązanych tabel.

Wynik zawiera informacje wybrane według warunków określonych przez aplikację.

Jakie produkty są przykładami relacyjnych baz danych?

Produkt relacyjnej bazy danych to system, którego podstawowy model opiera się na tabelach i relacjach. Przy jego klasyfikacji trzeba ustalić, czy zapisuje rekordy w wierszach, definiuje kolumny i łączy tabele kluczami. Możliwość wykonania zapytania podobnego do SQL nie dowodzi jeszcze, że produkt ma model relacyjny.

Zalety, ograniczenia i wydajność obu podejść do baz danych

SQL i NoSQL mają odmienne zalety oraz ograniczenia. O wydajności decydują zapytania, model danych i obciążenie, nie nazwa kategorii. Odczyt, zapis i aktualizacje warto oceniać osobno. Przykładowe parametry wydajności nie są wynikiem porównania obu podejść.

Jakie korzyści może dać baza nierelacyjna?

Baza nierelacyjna może uprościć odczyt, jeśli przechowuje razem dane pobierane razem przez aplikację. Model dokumentowy pozwala odczytać obiekt jako całość; klucz–wartość pomaga znaleźć wartość po znanym identyfikatorze. Rzeczywista korzyść zależy od zapytań. Taki sam układ może utrudnić aktualizację informacji powielonej w różnych rekordach.

Czy baza nierelacyjna jest bardziej zaawansowana od relacyjnej?

Baza nierelacyjna nie jest z natury bardziej zaawansowana niż relacyjna. Porównanie powinno uwzględniać odczyt, obsługę powiązań i koszt zmiany danych.

Tabela zestawia oba modele według odczytu, powiązań i ograniczeń dla aplikacji.

Różnica tkwi w przygotowaniu danych do zapytań, a nie w stopniu zaawansowania bazy. Model relacyjny odpowiada projektowi opartemu na powiązanych tabelach; nierelacyjny sprawdza się tam, gdzie odczyty pasują do wybranego rekordu.

Od czego zależy szybkość bazy relacyjnej i nierelacyjnej?

Szybkość baz relacyjnych i nierelacyjnych zależy od operacji, struktury danych, zapytań oraz obciążenia. Przepustowość to liczba operacji w jednostce czasu, a opóźnienie oznacza czas wykonania operacji. Oracle przedstawia ilustrację z parametrami odczytu i zapisu. Nie jest to jednak test porównawczy SQL i NoSQL¹.

Tabela przedstawia przepustowość i opóźnienia odczytów oraz zapisów z ilustracji Oracle.

Dane w tabeli: 21

Dane w tabeli opisują obciążenie przedstawione w ilustracji Oracle¹. Rzetelna ocena wydajności wymaga porównania baz przy jednakowych operacjach, danych i warunkach obciążenia.

Jakie mocne i słabe strony mają bazy SQL?

Bazy SQL ułatwiają tworzenie zapytań do powiązanych tabel, a schemat pozwala kontrolować strukturę danych. Trzeba jednak zaprojektować same tabele, klucze i zapytania odpowiadające aplikacji. W ocenie projektu należy uwzględnić złożone łączenie tabel oraz zmiany schematu. Wybór SQL sam w sobie nie przesądza o szybkości.

Decyzję między SQL a NoSQL należy oprzeć na wymaganych zapytaniach, aktualizacjach i pomiarze wydajności przy konkretnym obciążeniu.

Przykłady baz nierelacyjnych w konkretnych zastosowaniach

Bazy nierelacyjne przydają się wtedy, gdy ich model odpowiada zadaniu aplikacji: przechowywaniu obiektów, wyszukiwaniu treści lub analizie powiązań. Wykorzystuje się je w aplikacjach internetowych i mobilnych, handlu elektronicznym, analizie danych w czasie rzeczywistym oraz systemach IoT⁹. Sama branża nie rozstrzyga jednak wyboru. Liczą się wymagane odczyty i aktualizacje.

Do jakich zadań wykorzystuje się bazy nierelacyjne?

Baza nierelacyjna sprawdza się, gdy aplikacja odczytuje dane w postaci zgodnej z jej modelem. Katalog sklepu może pobierać opis produktu jako obiekt, wyszukiwarka szukać tekstu, a system rekomendacji przechodzić między powiązanymi obiektami. Przy danych z urządzeń IoT trzeba jeszcze rozróżnić odczyt ostatniego zapisu od odczytu zakresu zdarzeń²².

Jakie produkty reprezentują różne modele baz nierelacyjnych?

Apache CouchDB, Elasticsearch i Neo4j pokazują różne zastosowania baz nierelacyjnych. Warto porównać ich modele, sposób pracy oraz zadania, do których nie pasują.

Tabela zestawia produkty według modelu danych, sposobu pracy i niedopasowanego zadania.

Dane w tabeli: 16,23

Jak zastosowanie wpływa na wybór między bazą relacyjną a nierelacyjną?

Przed wyborem modelu trzeba opisać operacje wykonywane na danych. Oba podejścia warto oceniać według tych samych kryteriów:

• Odczyt pokazuje, czy aplikacja pobiera obiekt, przeszukuje treść, analizuje powiązania czy łączy dane z tabel.
• Aktualizacja wskazuje informacje zmieniane razem oraz miejsca, w których trzeba zachować spójność.
• Zapytania analityczne określają, czy dane będą później agregowane do raportów.

Taka ocena wskazuje model pasujący do operacji aplikacji, nie uniwersalną bazę dla branży.

Które bazy nierelacyjne warto znać jako przykłady?

Produkty z tabeli ilustrują różne zadania: pracę z dokumentami, wyszukiwanie tekstu i analizę relacji. Przy porównywaniu wdrożeń trzeba jeszcze uwzględnić strukturę własnych danych oraz zapytania aplikacji. Przykład bazy NoSQL pomaga zrozumieć model, lecz nie zastępuje doboru produktu do obciążenia.

Co oznacza „Not only Structured Query Language”?

„Not only Structured Query Language” znaczy „nie tylko SQL”. Nazwa NoSQL wskazuje, że dostęp do baz nierelacyjnych nie ogranicza się do języka SQL¹. Nie oznacza braku zapytań ani wspólnego interfejsu dla wszystkich takich baz. Przy wyborze trzeba oddzielić model przechowywania od sposobu formułowania zapytań przez aplikację²⁴.

Porównanie baz SQL i nierelacyjnych według potrzeb projektu

SQL i bazę nierelacyjną należy porównywać przez wymagane zapytania, zmiany danych oraz sposób skalowania. SQL odpowiada projektowi korzystającemu z powiązanych tabel. NoSQL może pasować tam, gdzie odczyt wynika z wybranego modelu rekordu. Żadna z tych cech nie gwarantuje wydajności wdrożenia.

Tabela zestawia oba podejścia według organizacji danych, zapytań, skalowania i ograniczeń.

Jakie różnice mają największe znaczenie przy wyborze bazy?

Baza SQL i baza nierelacyjna różnią się przede wszystkim sposobem zapisu powiązań i formułowania odczytu. Jeśli użytkownik potrzebuje przekrojowych zapytań do powiązanych danych, trzeba uwzględnić możliwość ich łączenia. Gdy aplikacja pobiera głównie gotowe obiekty, warto ocenić model zapisujący je w postaci odpowiadającej odczytowi.

Jak porównać sposób pracy z danymi w obu podejściach?

SQL i NoSQL należy porównać na tych samych danych oraz operacjach. Lista kontrolna obejmuje cały przebieg pracy aplikacji:

• Odczyt pokazuje, jakie dane zwraca aplikacja i czy musi łączyć informacje o różnych obiektach.
• Zapis wskazuje tworzoną jednostkę: wiersz tabeli lub rekord właściwy dla modelu nierelacyjnego.
• Zmiana pozwala znaleźć wszystkie miejsca wymagające aktualizacji po edycji informacji.
• Raportowanie pokazuje, czy dane trzeba zestawiać przekrojowo poza operacyjnym odczytem aplikacji.

Wynik powinien wskazać podejście, które obsłuży potrzebne operacje bez nadmiernego komplikowania zmian danych.

Czym różnią się schemat, zapytania i skalowanie?

SQL i NoSQL inaczej definiują strukturę oraz zapytania. Skalowanie trzeba jednak oceniać dla produktu i jego obciążenia. W modelu relacyjnym schemat tabel organizuje wiersze, a SQL pozwala pytać o powiązane dane. Składnia dostępu w NoSQL może różnić się między bazami¹. Skalowanie oznacza zwiększanie zdolności systemu do obsługi danych i operacji; nie wynika automatycznie z wybranej kategorii²⁵.

Jak model relacyjny i nierelacyjny wpływają na projekt aplikacji?

Wybór modelu relacyjnego lub nierelacyjnego wpływa na kod zapisujący rekordy, tworzący zapytania i obsługujący aktualizacje. Projekt aplikacji powinien wyznaczać granice obiektów, potrzebne powiązania i sposób przygotowania raportów. SQL i NoSQL w jednym systemie mają sens, gdy zadania wymagają odmiennych modeli. Trzeba wtedy ustalić źródło każdej informacji oraz sposób przekazywania jej zmian.

Werdykt: wybór między SQL a NoSQL wynika z operacji aplikacji; połączenie obu podejść wymaga jasnego przepływu danych.

Ograniczenia NoSQL w chmurze, mikrousługach i projektach AI

Chmura, mikrousługi ani AI nie są same w sobie powodem do wyboru NoSQL. W takich projektach decydują zapytania, reguły spójności oraz obowiązki związane z utrzymaniem bazy.

Kiedy nie wybierać bazy nierelacyjnej?

Baza nierelacyjna może nie pasować do aplikacji wymagającej przede wszystkim złożonych złączeń i zapytań przekrojowych. Możliwości złączeń i podzapytań zależą od konkretnej bazy NoSQL: MongoDB obsługuje złączenia, wiele warunków złączenia oraz podzapytania skorelowane i nieskorelowane¹. Transakcje ACID obejmują atomowość, spójność, izolację i trwałość operacji. Niektóre systemy NoSQL stawiają dostępność ponad spójnością danych, a obsługa transakcji ACID zależy od konkretnego systemu NoSQL²⁰. Jeśli projekt ich wymaga, zakres obsługi transakcji staje się kryterium wyboru produktu²⁶.

Czym różni się usługa zarządzanej bazy od samodzielnego wdrożenia?

Usługa zarządzanej bazy przenosi część obowiązków infrastrukturalnych na dostawcę. Przy samodzielnym wdrożeniu bierze je na siebie zespół utrzymujący system. Zakres odpowiedzialności wynika z konkretnej usługi, a nie z modelu NoSQL. W opisywanej ofercie OVHcloud umożliwia bezpłatne testowanie zarządzanej infrastruktury danych przez 3 miesiące; kod DBAAS pozwala przetestować 12 baz danych²⁰. Oferta dotyczy usługi, nie właściwości wszystkich objętych nią produktów.

Jak dopasować bazę danych do architektury mikrousług?

Baza w architekturze mikrousług powinna odpowiadać operacjom usługi, która z niej korzysta. Podział aplikacji na usługi nie oznacza konieczności stosowania wszędzie tego samego modelu.

• Granica danych mikrousługi wskazuje usługę odpowiedzialną za zapis i zmianę danej informacji.
• Wzorzec zapytań mikrousługi określa, czy odczyt dotyczy obiektu, powiązanych rekordów czy przekroju danych.
• Wymiana danych między mikrousługami określa, jak inne usługi otrzymują zmiany bez bezpośredniej modyfikacji cudzej bazy.

O doborze bazy decyduje odpowiedzialność mikrousługi za dane i jej komunikacja z resztą systemu.

Jakie potrzeby obciążeń AI wpływają na wybór bazy?

W projekcie AI trzeba określić, jakie dane system zapisuje, jak je wyszukuje i co aktualizuje po zmianie danych źródłowych. Wyszukiwanie podobnych treści wymaga innych zapytań niż pobieranie rekordu po identyfikatorze. Sama etykieta „projekt AI” nie wskazuje modelu bazy. Rozstrzyga sposób dostępu do danych.

NoSQL ma w takiej architekturze sens tylko wtedy, gdy konkretny model spełnia wymagania dotyczące zapytań, spójności i utrzymania.

Nauka baz nierelacyjnych na przykładzie Oracle NoSQL Database

Oracle NoSQL Database Cloud Service pozwala poznawać pracę z konkretnym produktem. Zakres nauki zależy od celu: modelowania danych, pisania zapytań lub zarządzania wdrożeniem. Usługa oferuje transakcje ACID, skalowanie bezserwerowe oraz modele dokumentowy, kolumnowy i klucz–wartość¹. Znajomość tego produktu nie oznacza znajomości każdej bazy NoSQL²⁷.

Od czego zależy czas potrzebny na naukę?

Czas nauki Oracle NoSQL Database Cloud zależy od wcześniejszego doświadczenia i umiejętności potrzebnych w projekcie. Opanowanie zapisu oraz odczytu wybranego modelu to inne zadanie niż projektowanie transakcji i zarządzanie usługą. Oracle NoSQL Database Cloud należy do Oracle Cloud Free Tier. Oferta obejmuje ograniczoną czasowo wersję próbną oraz usługi bez terminu wygaśnięcia bezpłatnego dostępu¹. Plan nauki warto powiązać z operacjami wykonywanymi później w aplikacji²⁸.

Język SQL a struktura tabeli relacyjnej

SQL służy do definiowania tabel relacyjnych i pracy z zapisanymi w nich danymi. Struktura tabeli wyznacza kolumny oraz ich typy. Zapytanie wskazuje wiersze i pola, które mają znaleźć się w wyniku. Klucze pozwalają powiązać rekordy z różnych tabel.

Do czego służy Structured Query Language?

Structured Query Language umożliwia tworzenie i zmianę struktury bazy, dodawanie, aktualizowanie oraz usuwanie rekordów, a także pobieranie danych. Zapytanie może filtrować wiersze, wybierać kolumny, agregować wartości i łączyć tabele. Nie każdy odczyt z tabel wymaga jednak złączenia. Zakres zapytania zależy od informacji potrzebnych aplikacji²⁹.

Relacyjne bazy danych i znaczenie struktury danych

Relacyjne bazy porządkują informacje według schematu określającego znaczenie pól i powiązań. Dzięki temu można rozdzielić dane o różnych obiektach, a potem zestawić je w zapytaniu. Projekt schematu powinien uwzględniać zarówno zapisy aplikacji, jak i informacje potrzebne w raportach.

Jak tabele i relacje organizują dane?

Tabele przechowują dane o określonych rodzajach obiektów, a klucze wskazują relacje między nimi. Schemat można przedstawić na przykładzie zamówienia:

• Tabela klientów zawiera informacje o klientach, do których odwołują się zamówienia.
• Tabela zamówień zawiera dane o zamówieniach i identyfikator powiązanego klienta.
• Relacja między tabelami pozwala zestawić zamówienie z danymi właściwego klienta.

Schemat relacyjny wskazuje miejsce zapisu informacji oraz drogę do jej powiązań.

Czy relacyjne bazy przechowują wyłącznie dane strukturalne?

Relacyjna baza nie musi ograniczać się do wartości rozdzielonych między kolumny. Zależnie od produktu może też przechowywać tekst, pliki lub dokumenty JSON. Ważne jest to, czy aplikacja wyszukuje i łączy poszczególne pola, czy pobiera całą zawartość.

Tabela porównuje sposoby zapisu w bazie relacyjnej pod kątem odczytu i ograniczeń projektowych.

Werdykt: baza relacyjna może przechowywać różne rodzaje danych, ale sposób zapisu powinien odpowiadać potrzebnemu odczytowi.

Modele przechowywania danych: od tabel po dokumenty i grafy

Model przechowywania określa, czy aplikacja zapisuje informacje w wierszach tabel, dokumentach czy obiektach połączonych relacjami. Bazy NoSQL mogą obsługiwać dane nieustrukturyzowane i częściowo ustrukturyzowane, w tym JSON oraz XML²⁰. Sam format nie przesądza jednak o wyborze bazy. Liczy się również sposób odczytu.

Bazy wielomodelowe łączą różne modele NoSQL w jednym systemie i mogą obsługiwać odmienne dane oraz obciążenia¹⁶. Nadal trzeba ustalić, jak aplikacja zapisuje każdy rodzaj danych i jakie wykonuje na nim zapytania.

Tabela zestawia tabele, dokumenty i grafy według jednostki zapisu oraz pytań aplikacji.

Model warto dobierać do pytań zadawanych danym, nie tylko do ich formatu.

Zastosowania baz SQL w procesach biznesowych i analityce

Bazy SQL obsługują procesy biznesowe, w których aplikacja zapisuje powiązane dane w tabelach i zestawia je w zapytaniach. Wiele tradycyjnych aplikacji finansowych, księgowych i ERP korzysta z wysoce znormalizowanych danych. Informacje są tam rozdzielane między powiązane tabele, aby ograniczyć ich powielanie. Według Oracle takie aplikacje zwykle nie nadają się do zastosowania baz NoSQL¹.

Analityka biznesowa może używać SQL do łączenia danych o transakcjach, klientach i produktach na potrzeby raportów. Projekt raportowania wymaga wskazania potrzebnych tabel i sposobu powiązania rekordów. SQL przydaje się tam, gdzie zarówno proces, jak i analiza opierają się na relacjach między danymi.

Kiedy korzystać z SQL?

SQL warto rozważyć, gdy aplikacja zadaje złożone pytania powiązanym tabelom, a proces wymaga integralności transakcyjnej. Przy stabilnych relacjach i takich wymaganiach baza relacyjna może pasować lepiej niż nierelacyjna^1,9. Integralność transakcyjna oznacza poprawne zatwierdzanie powiązanych zmian zgodnie z regułami procesu.

Decyzję o użyciu SQL powinny wyznaczać zapytania oraz zasady aktualizacji. System zapisujący powiązane operacje wymaga innej oceny niż aplikacja pobierająca gotowy obiekt po identyfikatorze.

Baza szerokokolumnowa: sposób organizacji i odczytu danych

Baza szerokokolumnowa układa dane w wierszach, których zestawy kolumn mogą się różnić. Strukturę zapisu projektuje się pod spodziewane odczyty. Model ten bywa stosowany przy dużych wolumenach danych i obciążeniach wymagających wydajnego zapisu⁹. Aplikacja powinna wiedzieć, jak wskazać potrzebne wiersze.

Bazy szerokokolumnowej nie należy mylić z kolumnową bazą analityczną. Podobna nazwa nie oznacza identycznego układu ani sposobu odczytu. Przy wyborze trzeba ustalić, jak aplikacja odnajduje wiersze i które kolumny pobiera. Struktura powinna odpowiadać jej zapytaniom.

Otwarte bazy rozproszone a zarządzanie danymi na wielu węzłach

Otwarta baza rozproszona wymaga zarządzania rozmieszczeniem danych i kopiami na serwerach. Otwarta licencja sama nie zapewnia skalowania ani dostępności. Skalowanie w poziomie polega na dodawaniu serwerów, lecz wykorzystanie nowych maszyn zależy od architektury bazy.

• Sharding rozdziela dane lub obciążenie między maszyny i służy skalowaniu poziomemu baz NoSQL¹. Podział trzeba uwzględnić przy projektowaniu odczytu, by aplikacja trafiała do właściwych danych.
• Replikacja tworzy kopie danych na serwerach i pomaga utrzymać dostęp po awarii części infrastruktury²³. Nie zastępuje rozdzielania danych między maszyny.

Zarządzanie taką bazą wymaga wiedzy, gdzie leżą dane, jak aktualizują się kopie i co następuje po awarii serwera. Wysoka dostępność oznacza utrzymanie dostępu mimo awarii części infrastruktury. Potrzebuje konfiguracji i obsługi, nie tylko wyboru otwartego produktu.

Apache Cassandra jako przykład rozproszonej bazy szerokokolumnowej

Apache Cassandra jest rozproszoną bazą NoSQL o modelu szerokokolumnowym. Przechowuje dane na wielu węzłach, czyli serwerach biorących udział w pracy bazy. Tabele i klucze trzeba projektować pod zapytania wykonywane przez aplikację.

Cassandra wymaga zaplanowania odczytów przed ułożeniem danych. Nie pasuje do projektu zakładającego swobodne łączenie tabel w dowolnych zapytaniach. Może natomiast odpowiadać aplikacji o przewidywalnych wzorcach dostępu zgodnych z modelem szerokokolumnowym, której dane obsługuje wiele węzłów.

Zarządzanie bazami nierelacyjnymi z Instaclustr: zakres usługi i kryteria wyboru

Instaclustr to dostawca usługi zarządzania bazą, a nie model danych ani nazwa bazy NoSQL. Przy wyborze usługi trzeba oddzielnie ocenić produkt bazodanowy i obowiązki pozostające po stronie zespołu.

• Produkt bazodanowy powinien obsługiwać wymagany zapis, zapytania i zasady spójności danych.
• Zakres zarządzania powinien jasno rozdzielać odpowiedzialność za konfigurację, aktualizacje, kopie zapasowe i obsługę awarii.
• Architektura wdrożenia musi odpowiadać wymaganiom dotyczącym lokalizacji danych, dostępu do bazy oraz połączenia z aplikacją.
• Warunki usługi powinny pasować do potrzeb projektu w zakresie dostępności, wsparcia i rozliczania zasobów.

Instaclustr pasuje do projektu, jeśli zakres usługi oraz wybrany produkt bazodanowy odpowiadają wymaganiom aplikacji i zespołu utrzymującego dane.

Najczęściej zadawane pytania

Co obejmuje limit 400 KB pojedynczego elementu w DynamoDB?

Limit obejmuje zarówno nazwy, jak i wartości atrybutów.

Co zrobić, gdy zapytanie Query w DynamoDB zwraca ponad 1 MB danych?

Pojedyncze wywołanie odczytuje najwyżej 1 MB, więc większy wynik wymaga kolejnych wywołań.

Jak długo DynamoDB Streams przechowuje rekordy zmian?

Rekordy zmian są dostępne przez 24 godziny na przekazanie do dalszych systemów.

Czy MongoDB automatycznie tworzy indeks dla pola _id?

Tak. Podczas tworzenia kolekcji MongoDB automatycznie zakłada na _id unikalny indeks.

Jaki jest maksymalny rozmiar dokumentu BSON w MongoDB?

Dokument BSON może mieć maksymalnie 16 MiB, co ogranicza ilość powiązanych danych przechowywanych razem.

Jaką wielkość partycji na dysku zaleca dokumentacja Apache Cassandra?

Zaleca, aby partycja na dysku nie przekraczała 100 MB.

Czy relacja w Neo4j może łączyć węzeł z samym sobą?

Tak. Węzeł początkowy i końcowy relacji mogą być tym samym węzłem.

Jakie typy wartości obsługuje JSON?

RFC 8259 wymienia sześć typów: obiekt, tablicę, liczbę, ciąg znaków, wartość logiczną i null.