Rozdział 22 · Tworzenie stron internetowych z Python

NoSQL: głównych typów baz danych nierelacyjnych

NoSQL łączy kilka modeli pamięci nierelacyjnej: key-value, dokumenty, szerokokolumnowe przechowywanie oraz wykresy.

NoSQL to powszechna nazwa dla systemów zarządzania bazami danych nierelacyjnymi danych wykorzystujących modele danych inne niż klasyczny model tabeli relacyjnej.

NoSQL to "nie tylko SQL", a nie "nigdy SQL"

Termin NoSQL często interpretowany jest jako Not Only SQL – „nie tylko SQL”

Relacyjne bazy danych (sekcje 22.21-22.24) przechowują dane w tabelach z predefiniowaną struktura. Czasami taka struktura jest niewygodna, na przykład, jeśli forma wpisów jest bardzo Różni się to w zależności od dokumentu, musisz bardzo szybko pracować nad kluczem lub danymi są naturalnie reprezentowane jako węzły i połączenia. Poniżej przedstawiono cztery główne rodziny NoSQL-dbms, Każdy ma swój własny model danych.

Klucz – Wartość

Każdy wpis jest dostępny pod unikalnym kluczem. Wartością może być łańcuch znaków, liczba, struktura danych lub inny obiekt, w zależności od DBMS.

Przykład: Redis jest serwerem struktur danych, w którym każdy obiekt ma klucz; Redis obsługuje łańcuch znaków tekstów, list, zbiory, skróty, strumienie i inne struktury danych.

primer_redis.txt

SET session:42 '{{"user_id": 42, "expires": "2026-08-24"}}'
GET session:42

Typowe zastosowania: cache, liczniki, przechowywanie sesji/stanów, kolejki i strumienie danych — często jako uzupełnienie głównej bazy, a nie jej zamiennik.

Bazy danych zorientowane na dokumenty

Dane są przechowywane w dokumentach składających się z pól i wartości. Dokumenty mogą zawierać zagnieżdżone struktury.

Przykład: MongoDB przechowuje dokumenty w BSON formacie, który jest strukturyzowany przez Blisko JSON.

primer_dokument.json

{{
  "name": "Механическая клавиатура",
  "price": 8900,
  "characteristics": {{"switches": "red", "layout": "ru"}}
}}

Wygodne, gdy forma zapisów może różnić się w zależności od dokumentu.

Bazy danych kolumn szerokich

Dane są zorganizowane wokół kluczy partycji (partition keys) oraz wierszy z zestawem kolumn. Model ten został zaprojektowany do rozproszonego przechowywania dużych ilości danych i z wyprzedzeniem Zaawansowane szablony zapytań.

Przykład: Apache Cassandra jest rozproszonym systemem DBMS o szerokich kolumnach, dostępny w swoim własnym języku zapytań CQL.

primer_wide_column.txt

Партиция: device_id = 42
Строки внутри партиции упорядочены по date

Typowe zastosowanie: zdarzenia i metryki z prędkością zapisu, rozproszone według urządzenia, użytkownika lub innego klucza partycji.

Bazy danych grafów

Dane są reprezentowane przez węzły, połączenia między nimi oraz właściwości. Model ten jest użyteczny, gdy Same połączenia są ważną częścią zadania.

Przykład: Neo4j jest grafowym DBMS, gdzie zapytania eksplicitnie działają na węzłach i Kontakty.

primer_graf.txt

(Ада)-[:ДРУГ]->(Борис)-[:ДРУГ]->(Вера)

Typowe zastosowanie: powiązania społeczne, rekomendacje, sieci zależności, analiza powiązań przy wykrywaniu oszustw.

Specjalistyczne systemy przechowywania i odzyskiwania

Istnieją systemy wyszukiwania pełnego tekstu, bazy danych wektorowe i czasowe osobno — nie są Należą do czterech wymienionych powyżej rodzin kanonicznych. Te kategorie mogą się nakładać oraz z już wymienionymi modelami, a niektóre produkty łączą kilka modeli w jeden DBMS (multi-model).

Ogólne cechy systemów NoSQL-

Wiele NoSQL-D baz danych ma bardziej elastyczny schemat danych niż model relacyjny, który nie jest oznacza, że w ogóle nie ma obwodu. Wiele NoSQL-D jest zaprojektowanych z Praca rozproszona i skalowanie poziome, ale konkretne gwarancje (spójność, wsparcie transakcyjne, odporność na błędy) zależą od produktu i jego ustawienia. Wydajność zależy od modelu danych, konkretnego DBMS oraz rodzaju zapytania — Nie ma zasady „NoSQL zawsze jest szybsze.”

Kryteria	Relacyjny DBMS	NoSQL- Systemy
Model danych	Tabele, wiersze, kolumny	Zależy od typu: dokumenty, klucz-wartość, wide-column, wykres
Schemat	Zwykle określane jawnie	Często bardziej elastyczne; Specyficzne dla DBMS
Powiązania	Klucze zewnętrzne, JOIN i inne operacje relacyjne	Implementowane różnie: linki, dokumenty zagnieżdżone, połączenia grafowe i inne
Język zapytań	SQL i jego dialekty	Natywne języki zapytań, polecenia lub API; niektóre obsługują interfejsy podobne do SQL-
Transakcje	Zależą od DBMS, zwykle rozwinięta obsługa transakcji	Zależy od konkretnego DBMS; wiele nowoczesnych systemów obsługuje również transakcje
Skalowanie	Możliwe architektury pionowe i rozproszone	Wiele systemów początkowo projektuje się do pracy rozproszonej
Kiedy wybrać	Gdy model relacyjny dobrze dopasowuje dane i zapytania	Gdy dany model nierelacyjny lepiej odpowiada danym i obciążeniu

Co wybrać

Relacyjną bazę danych warto rozważyć, gdy dane mają naturalną strukturę relacyjną, istotne są związki i ograniczenia, zapytania dobrze pasują do SQL, a integralność transakcyjna jest ważna dla zadania. Konkretną NoSQL-BD relacyjną warto brać pod uwagę, gdy jeden z modeli — dokumentowy, klucz-wartość, szerokolumnowy lub grafowy — naturalnie pasuje do zadania, wzorzec dostępu do danych jest dobrze znany z góry, a wymagania dotyczące dystrybucji i skalowania skłaniają wybór ku konkretnej nierelacyjnej architekturze.

Dla prostego zastosowania wystarczy jeden odpowiedni DBMS

Duże systemy rzeczywiste często wykorzystują więcej niż jedną technologię pamięci masowej, ale powinieneś rozpocząć projekt szkoleniowy od najprostszej i najbardziej odpowiedniej. W typowym CRUD- zastosowaniu, takim jak lista zadań, nie potrzebujesz jednocześnie PostgreSQL, MongoDB, Redis ani bazy wektorowej, co zwiększa złożoność działania bez realnych korzyści. Ostateczny szkic tego rozdziału (Rozdział 22.35) to jedna tabela na SQLite.

Oficjalna dokumentacja: MongoDB, Redis, Apache Cassandra, Neo4j.

← Back

PostgreSQL, MySQL/MariaDB i SQLite: główne różnice

Następny →

ORM: pracy z bazą danych za pomocą Python obiektów