NoSQL (od Not Only SQL) to klasa nierelacyjnych baz danych, które rezygnują ze sztywnego, z góry zdefiniowanego schematu tabel na rzecz elastycznego modelu danych i łatwego skalowania w poziomie. Zamiast wciskać wszystko w wiersze i kolumny połączone relacjami, NoSQL pozwala trzymać dane w formie, która pasuje do tego, jak realnie ich używasz: dokumentów, par klucz-wartość, kolumn lub grafów. Nazwa nie znaczy „precz z SQL-em” — wiele z tych baz ma własne języki zapytań, a niektóre nawet dialekt SQL-a.
Jak to działa i do czego służy
Cztery główne rodziny to: bazy dokumentowe (MongoDB, Couchbase) trzymające dokumenty JSON/BSON, klucz-wartość (Redis, DynamoDB) działające jak gigantyczna mapa, kolumnowe (Cassandra, HBase) zoptymalizowane pod ogromne zapisy, oraz grafowe (Neo4j) do danych mocno powiązanych relacjami. Łączy je brak wymogu, by każdy rekord miał identyczną strukturę — jeden dokument może mieć pole, którego sąsiedni nie ma.
Sięgasz po NoSQL, gdy masz dużo danych o luźnej lub zmiennej strukturze, potrzebujesz skalować na wiele serwerów (sharding) i akceptujesz, że nie zawsze dostaniesz natychmiastową spójność. Wiele baz NoSQL stawia na eventual consistency — dane „dogonią się” za chwilę, w zamian za dostępność i szybkość.
Przykład z praktyki
Robisz profil użytkownika, gdzie jedni mają telefon i adres, a inni tylko e-mail. W relacyjnej bazie kombinujesz z nullami albo dodatkowymi tabelami. W MongoDB po prostu wrzucasz dokument:
db.users.insertOne({ name: "Ania", email: "[email protected]", tags: ["pro", "newsletter"] })
Pole tags to tablica w środku dokumentu — żadnych JOIN-ów, żadnej tabeli pośredniej. Odczyt po kluczu jest błyskawiczny, a strukturę zmieniasz bez migracji całej tabeli.
Częste błędy i mity
Mit pierwszy: „NoSQL jest szybszy”. Bywa, ale tylko w scenariuszach, do których go zaprojektowano — przy złożonych relacjach i agregacjach klasyczny PostgreSQL często wygra. Mit drugi: „brak schematu = brak myślenia o modelu”. Odwrotnie — w NoSQL projektujesz dane pod konkretne zapytania (schema-on-read), a zły dobór klucza partycjonującego potrafi zabić wydajność. Uważaj też na transakcje: nie każda baza NoSQL daje pełne ACID across wielu dokumentów (MongoDB dodało transakcje wieloskładnikowe dopiero w wersji 4.0). I nie traktuj tego jako „zamiennik SQL-a” — to inne narzędzie do innych problemów.
Pojęcia powiązane
Baza relacyjna (RDBMS), SQL, teoremat CAP, eventual consistency, ACID i BASE, sharding, denormalizacja, JSON, MongoDB, Redis, Cassandra.