Przejdź do treści

Serverless a ogromne zbiory danych do przetworzenia.

Kiedy mówimy o platformach takich jak Booking.com, które działają na architekturze serverless, mamy na myśli, że system może dynamicznie zarządzać ogromnymi ilościami danych o hotelach i rezerwacjach w sposób wysoce efektywny, ale to nie oznacza, że dane są przechowywane w jednym miejscu lub w jednym regionie. W praktyce, systemy takie stosują rozproszone podejście do przechowywania danych, które umożliwia im szybkie przetwarzanie zapytań z dowolnej lokalizacji na świecie, bez względu na to, czy zapytanie dotyczy hotelu w odległym kraju. Oto, jak to działa:

1. Rozproszone bazy danych i replikacja

Dzięki rozproszonym bazom danych i replikacji danych w różnych regionach geograficznych, system Booking.com może przechowywać dane o hotelach, lokalizacjach, dostępności itp., w wielu regionach serwerów. Nawet jeśli użytkownik wyszukuje hotel w odległym kraju, system nie musi przeszukiwać jednej, centralnej bazy danych. Zamiast tego zapytanie jest kierowane do odpowiednich lokalnych baz danych, które przechowują dane dla tej konkretnej lokalizacji.

  • Replikacja danych: Dane o hotelach mogą być replikowane na serwerach w różnych częściach świata, co pozwala na szybki dostęp do informacji, niezależnie od miejsca, w którym znajduje się użytkownik.

  • Sharding danych: Dalszym ulepszeniem jest sharding, czyli podział danych na mniejsze fragmenty, które są przechowywane na różnych serwerach. Na przykład dane o hotelach w Europie mogą być przechowywane na innych serwerach niż dane o hotelach w Azji.

2. Kroki w przetwarzaniu zapytań w architekturze serverless

W praktyce, gdy użytkownik wpisuje zapytanie o hotel w odległym kraju, system Booking.com działa na zasadzie kilku kroków:

  1. Geolokalizacja użytkownika: Dzięki technologii geolokalizacji, system może określić, skąd pochodzi zapytanie, czyli w jakim kraju lub regionie znajduje się użytkownik. To pozwala na optymalizację przetwarzania zapytań.

  2. Przekierowanie zapytania do odpowiedniego regionu serwerowego: Nawet jeśli użytkownik jest w Polsce i szuka hotelu w Japonii, zapytanie jest przekierowywane do serwera, który przechowuje dane o hotelach w Japonii. System stosuje load balancing i DNS routing, aby przekazać zapytanie do najbliższego regionu, gdzie dane są już przetworzone i przechowywane.

  3. Dynamika serverless: W przypadku platformy serverless, zasoby są dynamicznie skalowane w zależności od obciążenia. Jeśli zapytania dotyczą hoteli w Japonii, serwery w regionie Azji automatycznie uruchomią więcej instancji funkcji (np. AWS Lambda), które obsługują to konkretne zapytanie.

  4. Wyszukiwanie w rozproszonych bazach danych: Kiedy zapytanie jest już skierowane do odpowiedniego serwera, system może wykorzystać rozproszone bazy danych, takie jak NoSQL (np. DynamoDB, Cassandra) lub relacyjne bazy danych (np. PostgreSQL z replikacją), które są zoptymalizowane pod kątem szybkim odczytem danych. W przypadku takich baz danych, dane o hotelach są zorganizowane w sposób umożliwiający szybkie wyszukiwanie i filtrowanie.

3. Cache’owanie na wielu poziomach

Wspomniane wcześniej cache’owanie jest kluczowym elementem, który umożliwia bardzo szybkie odpowiedzi na zapytania, nawet gdy dotyczą one odległych krajów:

  • Cache na poziomie aplikacji: Wyniki zapytań (np. hotele w określonym mieście) mogą być przechowywane w pamięci podręcznej na poziomie aplikacji (np. Redis, Memcached). Dzięki temu, gdy użytkownicy będą ponownie szukać hoteli w tej samej lokalizacji, odpowiedź jest dostarczana natychmiastowo.

  • Cache na poziomie CDN: Platformy takie jak Booking.com mogą korzystać z sieci dostarczania treści (CDN), które przechowują dane o popularnych hotelach w różnych punktach na całym świecie. Kiedy użytkownik z Europy szuka hotelu w Japonii, CDN może szybko dostarczyć mu dane o popularnych hotelach bez konieczności przetwarzania zapytania przez główny serwer w Japonii.

4. Algorytmy wyszukiwania i filtrowania

Na poziomie wyszukiwania i filtrowania, systemy takie jak Booking.com są zoptymalizowane pod kątem obsługi wielkich zbiorów danych:

  • Wyszukiwanie oparte na geolokalizacji i kategoryzacji: Hotel może być przypisany do różnych kategorii (np. „z basenem”, „tanie”, „w centrum miasta”), co pozwala na szybkie filtrowanie wyników na podstawie lokalizacji użytkownika i preferencji.

  • Wyszukiwanie w czasie rzeczywistym: W systemach takich jak Booking.com bardzo ważne jest szybkie przetwarzanie danych w czasie rzeczywistym (np. zmiany dostępności pokoi), co jest możliwe dzięki algorytmom wyszukiwania w rozproszonych bazach danych oraz systemach streamingowych, które natychmiastowo aktualizują wyniki wyszukiwania.

5. Wieloskalowe systemy i architektura mikroserwisów

Platformy takie jak Booking.com są rozbite na mikroserwisy, co pozwala na:

  • Optymalizację zasobów: Każdy mikroserwis (np. wyszukiwanie hoteli, płatności, recenzje) może działać niezależnie i skalować się w zależności od obciążenia. Dzięki temu, nawet jeśli zapytanie dotyczy hotelu w odległym kraju, odpowiednia część systemu (np. mikroserwis odpowiedzialny za przetwarzanie dostępności pokoi w Japonii) może zostać aktywowana w odpowiednim regionie.

  • Przetwarzanie równoległe: Zamiast przetwarzać zapytania sekwencyjnie, system może równocześnie obsługiwać wiele zapytań (np. kilka różnych krajów) przy użyciu wielu instancji mikroserwisów działających równolegle w różnych regionach geograficznych.

Podsumowanie

Zatem, mimo że użytkownicy mogą być z różnych części świata i wyszukiwać hotele w odległych krajach, system Booking.com wykorzystuje rozproszone bazy danych, technologię serverless, cache’owanie, geolokalizację i mikroserwisy, aby błyskawicznie przetwarzać zapytania i zwracać wyniki w czasie rzeczywistym. Dzięki temu, nawet przy globalnym zasięgu i ogromnych zbiorach danych, platforma jest w stanie działać bardzo szybko i sprawnie, oferując użytkownikom szybkie i trafne wyniki wyszukiwania.