Co to jest mongodb?
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: MongoDB to dokumentowa baza danych: przechowuje informacje w strukturach przypominających obiekty JSON, zamiast organizować je wyłącznie w tabelach z wierszami i kolumnami. Sprawdza się między innymi w aplikacjach, w których dane mają zagnieżdżoną strukturę lub różne zestawy cech. Nie jest jednak automatycznie szybszą ani prostszą alternatywą dla baz SQL — wybór zależy przede wszystkim od sposobu zapisywania i odczytywania danych.
Jak MongoDB przechowuje dane
MongoDB należy do baz NoSQL, czyli grupy systemów, które nie opierają się wyłącznie na tradycyjnym modelu relacyjnym. Podstawową jednostką danych jest dokument: zestaw pól i wartości opisujący na przykład produkt, użytkownika lub zamówienie. Dokumenty są grupowane w kolekcje, które pełnią funkcję zbliżoną do tabel, ale nie narzucają wszystkim rekordom identycznego układu pól.
Dokument można przedstawić w czytelnej postaci JSON:
{
"_id": "produkt-101",
"nazwa": "Plecak miejski",
"cenaGrosze": 18900,
"kolory": ["czarny", "granatowy"],
"parametry": {
"pojemnoscLitry": 20,
"wodoodporny": true
}
}
Pole _id jest unikalnym identyfikatorem dokumentu. Jeśli aplikacja go nie poda, przy standardowym dodawaniu dokumentu zwykle zostanie nadany identyfikator typu ObjectId. Pozostałe pola mogą zawierać między innymi tekst, liczby, listy i kolejne dokumenty.
Wewnętrznie MongoDB używa BSON, czyli binarnego formatu dokumentów obsługującego także typy danych niewystępujące bezpośrednio w JSON, na przykład daty. Stwierdzenie, że MongoDB „przechowuje JSON”, jest więc użytecznym uproszczeniem, a nie dokładnym opisem formatu zapisu.
Czym MongoDB różni się od bazy SQL
Relacyjne bazy danych, takie jak PostgreSQL czy MySQL, organizują dane w tabelach i pozwalają łączyć je na podstawie wspólnych pól. Przykładowo tabela zamówień może odwoływać się do tabeli klientów. SQL to język służący między innymi do zadawania pytań takim bazom.
W MongoDB powiązane informacje często umieszcza się wewnątrz jednego dokumentu. Zamówienie może zawierać listę pozycji i adres dostawy z momentu zakupu. Dzięki temu aplikacja pobiera komplet potrzebnych danych bez składania ich z wielu osobnych struktur.
| Obszar | MongoDB | Relacyjna baza danych |
|---|---|---|
| Główna struktura | Dokumenty w kolekcjach | Wiersze w tabelach |
| Model danych | Naturalne zagnieżdżenia i listy | Jawnie zdefiniowane kolumny i relacje |
| Powiązania | Osadzanie danych lub odwołania | Klucze obce i złączenia |
| Zapytania | Operacje na dokumentach i potoki agregacji | Zapytania SQL |
To porównanie nie oznacza sztywnego podziału możliwości. Bazy relacyjne mogą obsługiwać JSON, a MongoDB pozwala łączyć dane z kolekcji, między innymi operacją $lookup. Obsługuje również transakcje obejmujące wiele dokumentów, choć ich koszt i wymagania wdrożeniowe trzeba uwzględnić w projekcie.
Elastyczny schemat nie oznacza braku zasad
Dokumenty w jednej kolekcji mogą mieć różne pola. W katalogu sklepu plecak może mieć pojemność w litrach, a monitor przekątną ekranu i rozdzielczość. Nie trzeba tworzyć dla każdego rodzaju produktu identycznego zestawu pustych kolumn.
Elastyczność nie zwalnia jednak z projektowania modelu danych. Jeżeli jedna część aplikacji zapisuje cenę jako liczbę, a druga jako tekst, filtrowanie i obliczenia stają się trudniejsze. MongoDB oferuje walidację schematu, czyli reguły sprawdzające między innymi wymagane pola i ich typy.
Trzeba też zdecydować, co osadzać w dokumencie, a do czego przechowywać odwołanie. Adres dostawy zapisany w zamówieniu powinien zwykle pozostać historyczną kopią. Aktualny profil klienta lepiej przechowywać osobno, zamiast aktualizować jego kopie we wszystkich zamówieniach.
Nie należy bez ograniczeń dopisywać danych do jednego dokumentu. MongoDB ma limit rozmiaru dokumentu BSON wynoszący 16 MiB, dlatego stale rosnąca historia zdarzeń zwykle wymaga osobnej kolekcji.
Kiedy wybrać MongoDB, a kiedy rozważyć PostgreSQL
MongoDB jest sensownym kandydatem, gdy aplikacja pracuje na rozbudowanych obiektach, a ich zawartość często jest odczytywana razem. Przykłady to katalog produktów o różnych atrybutach, system zarządzania treścią lub konfiguracje urządzeń. Sam fakt, że aplikacja korzysta z JavaScriptu, nie jest wystarczającym powodem wyboru.
Bazę relacyjną warto rozważyć w pierwszej kolejności, gdy najważniejsze są liczne powiązania, ograniczenia integralności między tabelami i raporty łączące wiele rodzajów danych. Dotyczy to na przykład systemu rozliczeń, w którym łatwość kontrolowania zależności może mieć większe znaczenie niż swoboda struktury dokumentów.
Przed decyzją zapisz trzy najczęstsze operacje aplikacji, na przykład wyszukanie produktu, pobranie koszyka i zapis zamówienia. Następnie przygotuj przykładowy model w obu bazach. Sprawdź, ile odczytów i aktualizacji wymaga każda operacja oraz gdzie powstają kopie tych samych informacji.
Jak zacząć i o czym pamiętać przy wdrożeniu
MongoDB można uruchomić na własnej infrastrukturze lub skorzystać z MongoDB Atlas, zarządzanej usługi chmurowej. Do pracy z danymi służą między innymi narzędzie graficzne MongoDB Compass, powłoka mongosh i sterowniki dla języków programowania. Aktualne ceny, limity oraz zakres kopii zapasowych w Atlas należy sprawdzić w oficjalnej dokumentacji i cenniku wybranego planu.
Na początek utwórz testową kolekcję, dodaj kilkanaście dokumentów i wykonaj typowe zapytania. Następnie dobierz indeksy, czyli dodatkowe struktury przyspieszające wyszukiwanie, do rzeczywistych filtrów i sortowania. Nadmiar indeksów zajmuje miejsce i zwiększa koszt zapisu.
Przed wdrożeniem produkcyjnym skonfiguruj uwierzytelnianie, ograniczenia dostępu sieciowego i kopie zapasowe oraz przetestuj odtwarzanie danych. Pierwszy prototyp wykorzystaj do sprawdzenia modelu i zapytań — dopiero ich pomiar na reprezentatywnych danych pozwoli ocenić, czy MongoDB pasuje do konkretnej aplikacji.
Zobacz też: Co to jest 2FA?
Przeczytaj także
