Idź do:
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ń.
Przeczytaj także: 5 najpopularniejszych narzędzi do analizy danych biznesowych
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:
| SQL | NoSQL |
| jasno zdefiniowane relacje między danymi | brak relacji, dane są luźno powiązane |
| dane przechowywane w tabelach | dane przechowywane w dokumentach, grafach, jako tzw. klucz-wartość |
| zdefiniowany schemat | dynamiczny schemat, nieuporządkowane dane |
| preferowany przy operacjach na wielu wierszach | preferowany, gdy szybkość pozyskania danych jest istotna |
| skalowalne wertykalnie | skalowalne 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:
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 votes i priority 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:
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.
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ć?