SQL czy NoSQL — kiedy co ma sens
Bazy relacyjne mają czterdzieści lat i nadal obsługują większość świata. NoSQL nie przyszedł ich zastąpić, tylko rozwiązać kilka konkretnych problemów, z którymi radzą sobie gorzej.
Pytanie wraca w każdym projekcie i zwykle pada za wcześnie. Zanim się na coś zdecydujesz, warto wiedzieć, czym te bazy naprawdę się różnią — bo nie chodzi o to, która jest nowocześniejsza.
Relacyjne: tabele i twarde reguły
MySQL, PostgreSQL, MariaDB. Dane siedzą w tabelach o z góry ustalonych kolumnach, a baza sama pilnuje, żeby się zgadzały: zamówienie nie może wskazywać na nieistniejącego klienta, kwota musi być liczbą, adres e-mail musi być unikalny.
Największą zaletą są transakcje. Przelew to zdjęcie kwoty z jednego konta i dopisanie do drugiego. Baza gwarantuje, że albo wykonają się obie operacje, albo żadna — nawet jeśli w połowie zabraknie prądu. Tam, gdzie w grę wchodzą pieniądze albo stany magazynowe, to argument, który kończy dyskusję.
NoSQL: dokumenty i swoboda
MongoDB, Redis, Elasticsearch. Zamiast tabel — dokumenty, które mogą się między sobą różnić. Jeden produkt ma rozmiar i kolor, drugi moc i napięcie, i żadnego z nich nie trzeba wcześniej deklarować.
Drugą zaletą jest łatwiejsze rozłożenie danych na wiele serwerów. Baza relacyjna też to potrafi, ale wymaga to znacznie więcej pracy.
Wybór w praktyce
| Co budujesz | Co zwykle pasuje |
|---|---|
| Sklep, rezerwacje, faktury | relacyjna — liczą się transakcje |
| Strona z treścią, blog, CMS | relacyjna — struktura jest przewidywalna |
| Logi, zdarzenia, statystyki | NoSQL — dużo zapisów, luźna struktura |
| Wyszukiwarka pełnotekstowa | Elasticsearch obok bazy głównej |
| Sesje, kolejki, cache | Redis |
| Katalog produktów o bardzo różnych cechach | dokumentowa albo relacyjna z kolumną JSON |
Trzeci wariant, o którym się zapomina
Nowoczesne bazy relacyjne mają typ kolumny JSON. Można w jednej tabeli trzymać sztywną część danych — identyfikator, cenę, stan magazynowy — a zmienne cechy produktu wrzucić do kolumny JSON i przeszukiwać ją zapytaniem.
W praktyce to najczęściej najrozsądniejszy wybór: dostajesz swobodę tam, gdzie jest potrzebna, i twarde reguły tam, gdzie chodzi o pieniądze.
Zacznij od bazy relacyjnej. Dołóż coś innego dopiero wtedy, gdy poczujesz konkretny ból, a nie zanim.
Warto też pamiętać, że w typowym projekcie te bazy nie konkurują — MySQL trzyma zamówienia, Redis sesje, a Elasticsearch obsługuje wyszukiwarkę. Każde narzędzie robi to, w czym jest najlepsze.
Komentarze (9)
-
Przemek
Rada, żeby zacząć od bazy relacyjnej i dokładać dopiero przy konkretnym bólu, oszczędziłaby mojemu poprzedniemu zespołowi pół roku.
Odpowiedz -
Przemek
Rada, żeby zacząć od bazy relacyjnej i dokładać dopiero przy konkretnym bólu, oszczędziłaby mojemu poprzedniemu zespołowi pół roku.
Odpowiedz -
Justyna
Kolumna JSON w MySQL to faktycznie niedoceniany kompromis. Mamy tak zrobiony katalog produktów i sprawdza się od dwóch lat.
Odpowiedz -
Justyna
Kolumna JSON w MySQL to faktycznie niedoceniany kompromis. Mamy tak zrobiony katalog produktów i sprawdza się od dwóch lat.
Odpowiedz -
Kamil
Dobra tabelka. Dorzuciłbym jeszcze kolejki zadań, bo to kolejny przypadek, gdzie Redis bije wszystko inne.
Odpowiedz -
Kamil
Dobra tabelka. Dorzuciłbym jeszcze kolejki zadań, bo to kolejny przypadek, gdzie Redis bije wszystko inne.
Odpowiedz- Przemek
Popieram, kolejki na Redisie działają u nas od dwóch lat bez jednej awarii. Prosto i szybko.
Odpowiedz
-
