MongoDB – idealny system bazodanowy dla e-commerce?

Adam Sosiński | Bazy danych | 12.01.2022

MongoDB

Jednym z kluczowych wyzwań dla programistów, architektów oraz managerów zaangażowanych w projekty e-commerce jest wybór odpowiedniej bazy do przechowywania danych reprezentujących towar czy usługę. Analogicznie do tego jak fizycznie towary przechowywane są w magazynach, tak w świecie wirtualnym informacje o nich przechowywane są w bazach danych. Wybierając system do zarządzania bazą danych (DBMS) na potrzeby e-commerce, trzeba zwrócić uwagę na kilka kwestii: elastyczność, wysoką dostępność, niezawodność, obsługiwanie wielu zapytań oraz aktualność danych. Jednym z popularnych systemów odpowiadających na te potrzeby jest MongoDB, którego możliwości omówię w tym artykule.

E-commerce to nie tylko sklepy internetowe

E-commerce to nic innego jak handel przeniesiony do Internetu. Przy czym mówimy tu o samej transakcji kupna-sprzedaży, gdyż płatność i dostawa mogą być realizowane w sieci, jak i poza nią. Najbardziej znanym i przez część osób utożsamianym z tym pojęciem rodzajem handlu są sklepy internetowe. Należy jednak nadmienić, że poza e-sklepami możemy jeszcze wyróżnić serwisy aukcyjne, e-kantory, bankowość elektroniczną czy platformy bukmacherskie.

Wyzwania systemów bazodanowych w e-commerce

System bazodanowy w e-commerce to narzędzie do zadań specjalnych.

Dobrze skonfigurowany system bazodanowy powinien:

  • zagwarantować dostępność danych 24/7
  • utrzymać szybkość odpytywania w okresie wzrostu użycia
  • zapisywać ogromne ilości danych
  • informować w sposób dynamiczny i ciągły o zmianach (np. dostępności danego produktu)

W tym celu firmy e-commerce powinny postawić na skalowalność bazy danych. To istotne zwłaszcza w czasie peaków w e-commerce, takich jak Black Friday, Cyber Monday i związaną z nimi zwiększoną liczbą zapytań.

Co wybrać: nierelacyjne bazy danych czy relacyjne bazy danych?

Zastanówmy się trochę głębiej nad przechowywaniem danych dla usług e-commerce. Do wyboru mamy kilka typów baz danych, przy czym najbardziej znane są relacyjne (SQL) i nierelacyjne (NoSQL). Przyjrzyjmy się różnicom między nimi. Żeby być bardziej precyzyjnym, SQL jest to Structured Query Language, czyli język do pozyskiwania danych z bazy relacyjnej. Przyjęło się jednak tego typu bazy danych nazywać „bazami SQL”, zatem tej nazwy będę używał przy porównywaniu. Upraszcza to też zapamiętanie nazwy drugiego rodzaju baz, czyli NoSQL, które często określa się po prostu jako „nie SQL”.

Przechodząc do różnic, możemy wyróżnić 5 podstawowych, które zebrałem w tabeli poniżej:

SQLNoSQL
jasno zdefiniowane relacje między danymibrak relacji, dane są luźno powiązane
dane przechowywane w tabelachdane przechowywane w dokumentach, grafach, jako tzw. klucz-wartość
zdefiniowany schematdynamiczny schemat, nieuporządkowane dane
preferowany przy operacjach na wielu wierszachpreferowany, gdy szybkość pozyskania danych jest istotna
skalowalne wertykalnieskalowalne horyzontalnie

Jak widać, bazy NoSQL idealnie wpisują się w wymagania i potrzeby rynku e-commerce w kontekście dostępności i przechowywania danych. Obecnie najpopularniejszym systemem bazodanowym tego typu jest MongoDB.

Czym jest MongoDB?

MongoDB to dokumentowa baza danych zaprojektowana z myślą o łatwości tworzenia i skalowania. Dokumenty są tworzone i przechowywane w formacie BSON, czyli Binary JSON. Zastosowanie JSON oznacza, że ​​bardzo łatwo jest przekonwertować zapytania i wyniki do formatu, który rozumie kod frontendowy, w którym napisana jest aplikacja e-commerce. Jest też on bardziej czytelny dla człowieka. To rozwiązanie NoSQL obejmuje hierarchiczność, automatyczne fragmentowanie i wbudowaną replikację dla lepszej skalowalności i wysokiej dostępności.

Mając już obraz tego, jakie są główne wyzwania w e-commerce, oraz upewniając się, że MongoDB to dobry wybór w kontekście przechowywania danych, możemy zastanowić się nad odpowiedzią na pytanie: co MongoDB może zaoferować branży e-commerce?

NoSQL w e-commerce, czyli co MongoDB może zaoferować branży?

Dynamiczne schematy

Dzięki dynamicznym schematom dokumenty w kolekcji nie muszą posiadać tych samych pól, a i dane pole może mieć różne typy w zależności od dokumentu. Zwiększa to elastyczność mapowania na encje czy obiekty. Praktyka pokazuje jednak, że struktura dokumentów wewnątrz kolekcji jest podobna. Aby to zagwarantować, MongoDB wprowadziło możliwość ustawienia reguł walidacyjnych na kolekcję.

Łatwa hierarchizacja danych

Zastosowanie formatu JSON pozwala na łatwą hierarchizację danych. Możemy to zrobić poprzez osadzenie jednego dokumentu wewnątrz drugiego lub poprzez przekazanie referencji. Użycie jednej bądź drugiej metody powinno być rozpatrywane indywidualnie dla każdej kolekcji. Zalecane jest stosowanie osadzenia, ponieważ pozwala to pozyskać dane w wyniku pojedynczego zapytania, co zwiększa wydajność systemu. Referencje warto rozważyć dla bardziej skomplikowanych reprezentacji hierarchii bądź w sytuacji, kiedy korzyści z zagnieżdżenia nie przeważają nad skutkami duplikacji danych (takimi jak np. potrzeba monitorowania zmian przy podmianie danych)

Replikacja

MongoDB używa konceptu nazwanego Replica Set, czyli zestawu node’ów zawierających te same dane. Umożliwia to replikację danych, której celem jest zwiększenie dostępności oraz zabezpieczenie się przed awariami serwerów bazodanowych. Dobrze zaprojektowana architektura pozwala również na szybszy dostęp do danych.

Kluczowe założenia i mechanizmy replikacji omówimy na podstawie poniższego schematu:

nosql w ecommerce

Zestaw replik składa się z jednego node’a, tzw. członka głównego (Primary), oraz członków drugorzędnych (Secondary). Istnieje też specjalny członek takiego zestawu, sędzia (Arbiter), który nie posiada kopii danych, ale służy do wybierania zastępcy w przypadku niedostępności głównego serwera.

Operacje zapisu wykonywane są wyłącznie na głównej instancji, z której później mechanizm wbudowany MongoDB kopiuje dane na pozostałe. Operacje odczytu domyślnie również przechodzą przez wiodącą instancję, ale istnieje możliwość skonfigurowania node’ów, tak aby to poboczne serwery służyły do obsługi zapytań, przy czym może to się wiązać z wystąpieniem tzw. eventual-consistency, czyli z opóźnioną aktualnością danych.

Istotny dla całej koncepcji replikacji jest mechanizm taktowania (heartbeat). Każdy z node’ów (members) co 2 sekundy odpytuje pozostałe w celu sprawdzenia ich dostępności. W przypadku gdy serwer główny jest niedostępny, następuje wybór nowego. Proces ten polega na wybraniu spośród pozostałych instancji tej, która ma ustawiony najwyższy priorytet. Dokumentacja stwierdza, że replika może posiadać do 50 node’ów, przy czym tylko 7 z nich może brać udział w wyborze (voting), i to spośród nich wybierany jest następca. Pozostałe serwery, nazwane Non-Voting members, muszą mieć właściwości votespriority ustawione na 0. Zaleca się, aby liczba instancji z możliwością głosowania była nieparzysta, stąd też minimalna liczba  node’ów w replice to 3.

Fragmentacja

Fragmentacja polega na podzieleniu zestawu danych na mniejsze części, dzięki czemu możemy skalować horyzontalnie, praktycznie w nieskończoność. MongoDB do obsługi fragmentacji używa klastra, który składa się z następujących elementów:

  • Shard, czyli zestawu replik, który zawiera część kolekcji (Chunk)
  • Router, który działa trochę jak load balancer i na podstawie konfiguracji przekazuje polecenia do odpowiedniej podkolekcji, żeby zrównoważyć obciążenie
  • Config server, przechowujący metadane i konfigurację klastra

Zależności pomiędzy komponentami przedstawia poniższy schemat:

nosql database real time analysis

Istotne w przypadku fragmentacji danych jest dobranie odpowiedniego klucza oraz strategii.

Wybierając pole dokumentu, którego chcemy użyć jako klucza, powinniśmy rozważyć:

  • Kardynalność – czyli na jak wiele elementów możemy podzielić kolekcję względem klucza
  • Powtarzalność – czy któraś wartość nie pojawia się zdecydowanie częściej niż pozostałe
  • Jednostajność – czy nowe wartości klucza nie są wzrastające / malejące w sposób liniowy
  • Częstotliwość zapytań – klucz powinien być wykorzystywany w najczęstszych zapytaniach

Jeżeli chodzi o strategie, mamy do dyspozycji dwie:

Hashed Sharding

Przy tej strategii MongoDB automatycznie generuje Hash z wartości pól kluczy. Sprawdza się ona w przypadku gdy wartości klucza zmieniają się jednostajnie. Zastosowanie hasha zwiększa równomierne rozdzielenie dokumentów pomiędzy udziałami (Shards). Minusem jest to, że w przypadku zapytań o dany zakres mało prawdopodobne jest, iż wszystkie dokumenty będą w jednym udziale. Skutkuje to odpytywaniem wszystkich części kolekcji (chunks), ponieważ router nie jest w stanie jednoznacznie określić, w którym udziale znajdują się szukane dokumenty.

Ranged Sharding

Każdy z udziałów przechowuje części kolekcji w danym zakresie wartości klucza. Strategia ta sprawdza się, kiedy zbiór wartości dla klucza jest duży, ale powtarzalność każdej z nich jest mała. Ogromną zaletą jest możliwość ukierunkowania zapytania na konkretny udział bądź  kolekcję, co znacząco wpływa na szybkość odpytywania.

Dzieleniem na części oraz ich rozmieszczaniem zajmuje się wbudowany mechanizm MongoDB, który dba o równe ich rozdystrybuowanie oraz stara się utrzymać zbliżoną wielkość każdego z nich. Decydując się na fragmentację, należy pamiętać, że MongoDB nie oferuje metody scalenia danych, a jedynie możliwość ponownej fragmentacji po innym kluczu.

Strumienie zmian

Od wersji 3.6 MongoDB pozwala nasłuchiwać zmian w wybranej kolekcji, bazie lub całym systemie, z wyjątkiem kolekcji admin, lokal i config. Odbywa się to poprzez otwarcie kursora, który pozwala iteracyjnie przechodzić po zdarzeniach związanych z danym zakresem. Ponieważ mechanizm ten używa agregacji, możemy również nasłuchiwać konkretnych zmian czy też modyfikować odebrane notyfikacje. Podstawowym wymaganiem jest użycie zestawu replik, gdyż powiadomienie następuje w momencie zapisu zmiany na większości z tych, które są odpowiedzialne za przechowywanie danych.

Strumienie zmian wykorzystują specjalną, ograniczoną kolekcję oplog, która przechowuje informację o operacjach wpływających na aktualny stan danych. Dokumenty w tej kolekcji rotują, oznacza to, że nowy dokument w przypadku osiągnięcia limitu rozmiaru kolekcji powoduje usunięcie najstarszych. Dlatego należy dobrać odpowiedni rozmiar dla tej kolekcji, zależny od częstotliwości występowania zdarzeń, tak aby możliwe było przechwycenie wybranego, zanim zostanie ono usunięte.

Podsumowanie

Wartość polskiego rynku e-commerce w 2020 r. przekroczyła 100 mld zł, jednocześnie według raportu „E-commerce w Polsce 2021”, opracowanego przez Gemius dla e-Commerce Polska, aż 77% Polaków deklaruje, że kupuje online. Wskazuje to wyraźny, utrzymujący się już od dłuższego czasu trend przenoszenia się handlu do Internetu. Według prognoz tak dynamiczny rozwój e-handlu w Polsce utrzyma się jeszcze przez kilka najbliższych lat.

Klienci mają coraz większe wymagania co do stron internetowych czy aplikacji. Do najważniejszych czynników zwiększających tzw. User Experience należą dostępność, szybkość i niezawodność. Dobrze skonfigurowany system bazodanowy taki jak MongoDB jest odporny na awarie, skalowalny i pozwala na hierarchizację i zapis sporych ilości danych, zatem w pełni odpowiada na potrzeby projektów e-commerce.  

Autorem wpisu jest:

Senior .NET Developer / Technical Leader

Programista rozwiązań webowych, pracujący z nowoczesnymi stackami technologicznymi. Stawia na pierwszym miejscu rodzinę, ale znajduje też czas na sport i poszerzanie wiedzy o nowinki ze świata .NET. Uważa, że jeżeli można się podzielić wiedzą i doświadczeniem, to czemu tego nie robić?

Dodaj komentarz: