MongoDB w zastosowaniu w serwisach społecznościowych

Transkrypt

1 MongoDB w zastosowaniu w serwisach społecznościowych Poniższe sprawozdanie ma na celu przekazanie informacji na temat systemu bazodanowego MongoDB i jego przewagach nad tradycyjną bazą danych wykorzystywaną w internetowych serwisach społecznościowych czyli Mysql. Sprawozdanie zawiera: 1. Przedstawienie wymagań dotyczących baz danych w tradycyjnym podejściu do portali internetowych czyli tzw. WEB Przedstawienie wymagań dotyczących baz danych w podejściu społecznościowym czyli WEB Przybliżenie cech systemów nierelacyjnych na podstawie MongoDB 4. Prezentacja możliwych zastosowań MongoDB 5. Omówienie zalet MongoDB na przykładzie wybranych funkcjonalności społecznościowych 6. Podsumowanie wyników wydajnościowych przeprowadzonych w środowisku produkcyjnym serwisów Gratka Technologie Celem sprawozdania jest przekazanie podstawowej wiedzy na temat nierelacyjnych baz danych, uświadomienie konieczności rozwoju środowisk bazodanowych w internetowych portalach społecznościowych, tak aby sprostać zmieniającym się wymaganiom i zaprezentowanie nowego podejścia do sposobu przechowywania i prezentowania informacji w portalach internetowych. Wymagania wobec baz danych w portalach internetowych w podejściu tradycyjnym. Mysql jest najpopularniejszym obecnie systemem baz danych wykorzystywanym w środowiskach portali internetowych. Jest to relacyjna baza danych spełniająca wymogi wydajnościowe i pojemnościowe nawet dla dużych serwisów. W czasach tzw. WEB1.0 czyli wtedy, gdy użytkownicy witryn internetowych byli biernymi oglądaczami prezentowanych treści, a jedyną formą interakcji była funkcjonalność forum internetowego, baza MySQL była więcej niż wystarczającym narzędziem. Jeśli założymy, że nawet duży portal internetowy o charakterze kontentowym (wp.pl, onet.pl itp) posiada nie więcej niż kilkuset redaktorów tworzących treść serwisu, to przekłada się to na nie więcej niż kilka-kilkanaście tysięcy zapisów do bazy mysql na dobę. Przy tym założeniu baza MySQL jest idealnym narzędziem ponieważ jej siła najbardziej się uwidacznia przy dużej dysproporcji między poziomem zapisu a odczytu (dokładnie mało zapisów, dużo odczytów). Nawet bardzo duża pula odczytów w takim serwisie może zostać skutecznie rozłożona na slave'y w replikacji mysql. Jeśli uruchomimy replikację na jednej maszynie typu master, to bez najmniejszego problemu obsłuży ona cały ruch zapisujący dane od redaktorów i prześle go na dowolną praktycznie ilość slave'ów, a duża pula odczytów rozłoży się poprzez loadbalance'ing na kilka slave'ów. W

2 takim systemie jest możliwe obsłużenie naprawdę bardzo dużego ruchu przy rozsądnych nakładach sprzętowych. Wymagania wobec baz danych w portalach internetowych w podejściu społecznościowym Tak zwane WEB2.0 całkowicie odmieniło rzeczywistość 'sprzętową' w portalach internetowych. Wokół witryn zaczęły tworzyć się społeczności przyciągane możliwościami aktywnego tworzenia treści serwisu, wymiany myśli, poglądów, współpracy i integracji ludzi. W WEB20 przeważa tzw. User Generated Content, co przekłada się oczywiście na kwestie przechowywania i serwowania informacji z poziomu baz danych. W serwisach społecznościowych nie ma kilkuset redaktorów tylko kilka tysięcy lub nawet kilka milionów! Facebook czy naszaklasa to sztandarowe przykłady bardzo dużych portali społecznościowych i na ich podstawie można przeanalizować jakim wymaganiom musi sprostać baza danych. Ogromny wzrost zapisów i modyfikacji w bazie danych spowodowany tym, że każdy dotychczasowy bierny 'oglądacz' treści stał się aktywnym twórcą. Taki wzrost zapisów jest czymś do czego Mysql po prostu nie został stworzony, zapis do bazy, zwłaszcza modyfikacja rekordu powoduje zablokowanie całej tabeli, co powoduje opóźnienia w odczytach i rosnące kolejki 'selectów' czekających na odblokowanie tabeli. Jeśli zapisów jest dużo, blokady powodują ogromny wzrost obciążenia i w rezultacie zawieszenie procesu mysqld. Oczywiście w Mysql są techniki i narzędzia które mogą w pewnym stopniu ograniczyć ten problem lecz w praktyce bardzo szybko dochodzi do wysycenia systemu i jedynym rozwiązaniem jest ucieczka w sprzęt czyli rozbudowa farmy serwerów mysql. Oczywiście takie rozwiązanie jest bardzo kosztowne i w praktyce nieopłacalne. Na szczęście istnieje inne rozwiązanie. Przybliżenie cech systemów nierelacyjnych na bazie MongoDB MongoDB to tak zwana nierelacyjna baza danych pracująca w modelu 'Document Oriented'. Idea stojąca za Mongo jest następująca: Systemy relacyjne takie jak Mysql, Oracele czy Mssql są bardzo rozbudowane, mają ogromne możliwości lecz często okupione jest to niższą wydajnością i skomplikowaną obsługą. Z drugiej strony systemy typu 'key-value' takie jak Mamcache, Redis, czy Voldemort są wyjątkowo proste w budowie i oferują stosunkowo niewiele funkcji (w uogólnieniu to tablice hashowe, czasem rozbudowane o proste mechanizmy wyszukiwania czy agregacji i bardziej rozbudowane funkcje wydajnościowe takie jak klastrowanie, możliwość pracy w systemach rozproszonych z wysoką odpornością na awarie) lecz ich zaletą jest ogromna wręcz prędkość działania i niezawodność. MongoDB spina te dwa podejścia starając się przejąć to co najlepsze z systemów relacyjnych czyli

3 funkcje wyszukiwania, sortowania, agregacji a z systemów key-value szybkość działania i dużą odporność na awarie. W efekcie MongoDB zapewnia doskonałe lekarstwo na problemy które przyniosło WEB20. Posiada możliwość definiowania kolekcji (tabel) i dokumentów (krotek), lecz ponieważ jest bazą typu schemeless nie ma potrzeby definiowania struktury tych obiektów, więc każdy z nich może zawierać inne pola, jedynym wymogiem jest istnienie unikalnego klucza głównego dla każdego dokumentu wewnątrz jednej kolekcji o co zresztą dba samo Mongo. Takie podejście jest intuicyjne i proste w implementacji a dodatkowo oszczędza miejsce (nie ma potrzeby rezerwacji miejsca na pola które mają puste wartości) Kolekcje można przeszukiwać pod kątem istnienia dokumentów spełniających określone kryteria (np. Pole płeć ma wartość k lub imie zaczyna się na Mich ), w tej chwili nie ma jeszcze możliwości przeszukiwania pełnotekstowego ale istnieją znane obejścia tego problemu a developerzy Mongo pracują nad natywną obsługą tej funkcji. Otrzymane wyniki można dowolnie sortować, ograniczać i agregować. Mongo pozwala też na zakładanie indeksów, które działają analogicznie do tych w mysql. Dodatkowo Mongo zapewnia atomowość operacji na poziomie dokumentu i nie wymaga blokady kolekcji podczas dodawania danych bądź ich aktualizacji. Tylko usuwanie danych i zakładanie indeksów wymaga założenia blokady dla wątków odczytujących. Mongo oferuje też bardzo rozbudowane funkcje replikacji, shardowania i posiada wbudowane mechanizmy failover'a, potrafi też pracować w środowiskach rozproszonych. Jest więc odporne na awarie pojedynczego węzła systemu. Podstawową różnicą między MongoDB a systemami relacyjnymi jest brak możliwości wykonywania złączeń między kolekcjami mówiąc prosto MongoDB nie ma JOIN'ów, nie ma relacji. Ważnym ograniczeniem jest też brak transakcyjności dlatego też Mongo nie jest polecane dla systemów finansowo-księgowych, płatniczych czy bankowych. Prezentacja możliwych zastosowań MongoDB MongoDB jest w stanie w całości przejąć obowiązki Mysql, jednak najlepszą drogą dla już istniejących portali jest ewolucyjne podejście i implementacja Mongo tam gdzie można najlepiej wykorzystać jego możliwości. Pierwszym z takich miejsc jest tak zwana druga warstwa cache'owania (secondcache). Najczęściej stosowanych systemem keszowania w portalach internetowych jest Memcache jest to system który nie wspiera mechanizmów replikacji i failovera, więc w wypadku uszkodzenia maszyny, nie

4 ma możliwości zapewnienia ciągłości dostępu do cache'a. W takim środowisku stawiamy MongoDB jako drugą warstwę. Systemy odpowiedzialne za odczyt danych z bazy i ich zapis do kesza modyfikuje się o dodatkową funkcję która podczas zapisu danych zapisuje je dodatkowo do Mongo a przy odczycie w razie braku odpowiedzi z Memcache, próbuje uzyskać dane z Mongo. Samo MongoDB w takim systemie pracuje w systemie failoverowym (tzw. Replikacja Master- Master, jedna maszyna jest online, druga pracująca jako slave jest w trybie oczekiwania, w razie awarii pierwszej maszyny, druga przejmuje jej obowiązki i staje się masterem, a pierwsza po usunięciu usterki samoczynnie przełącza się w trym slave'a i przyjmuje zreplikowane dane), co zapewnia bardzo duży stopień bezpieczeństwa i uodparnia sytem cache'owania na awarię jednego z podsystemów. Drugim etapem integracji MongoDB z portalem jest tak zwany LazyCache czyli izolacja warstwy prezentacji od warstwy danych. W tym systemie dochodzi kolejna maszyna Mongo pełniąca rolę kolejki. Systemy dostępu do danych zostają zmodyfikowane w taki sposób, że każde zapytanie odczytujące dane z bazy jest zapisywane w kolejce wraz z informacją o czasie keszowania tych danych. Samego odczytu z bazy dokonuje mechanizm kolejki, wykonując zapamiętane zapytania w zadanym odstępie czasu. Pobrane dane są w wstępnie przetworzonej formie zapisywane do Mongo pełniącego funkcję secondcache'u. Dopiero stąd dane zapisywane się do Memcache'a (mechanizm mongo pozwala na zapamiętywanie całych list obiektów jak i pojedynczych obiektów co umożliwia aktualizację w Memcache'u danych w sposób w jaki do tej pory nie można tego było wykonać np. w razie aktualizacji obiektu o id 15 mongo może zaktualizować ten obiekt w memcache'u jak również wszystkie listy które zawierają kopie tego obiektu sam Memcache tego nie potrafi). Sam Memcache nigdy nie wygasza danych które zapamiętał, tak więc nawet w wypadku uszkodzenia mechanizmu kolejki, serwis zawsze będzie miał dostęp do danych. Nie będą może one tak aktualne jak by mogły być, jednak sam fakt, że zawieszenie się bazy danych, lub mechanizmu kolejki nie będzie powodowało awarii serwisu jest ogromnym krokiem naprzód. Dodatkową zaletą jest fakt, że można zarządzać obciążeniem bazy danych modyfikując prędkością kolejki i np. przyspieszać bądź spowalniać proces aktualizowania się danych w serwisie, i to nie tylko na poziomie całego portalu ale, przy zastosowaniu odpowiednio zaprojektowanych paneli z dostępem do danych kolejki, na poziomie pojedynczego zapytania. Zaprezentowanie zalet Mongo na przykładzie wybranych funkcjonalności portali społecznościowych MongoDB charakteryzuje się ogromną szybkością i pojemnością. Wszystkie dane przechowywane są w pamięci RAM i dopiero z stamtąd zapisywane na dysk. Powoduje to, że taka baza jest

5 wymarzonym narzędziem dla wielu funkcjonalności społecznościowych. Funkcje takie jak ściana lub tablica, znajomi, chmura tagów, opierają się zasadniczo na jednej podstawowej zasadzie. To co pisze jedna osoba widoczne jest u wielu osób a dodatkowo nie można tu stosować mechanizmów keszowania, ponieważ użytkownicy społecznościowi oczekują natychmiastowej reakcji na ich akcje (jeżeli piszę coś na ścianie mojego znajomego, on powinien to zobaczyć w tym samym momencie, jeżeli piszę coś na swojej ścianie, to wszyscy moi znajomi muszą zobaczyć to od razu!). Taki system z konieczności musi mieć możliwość ogarnąć ogromne ilości jednoczesnych zapisów z jednoczesnymi odczytami. W wypadku nawet niewielkich społeczności (wiadomosci24.pl) gdzie liczba użytkowników jest stosunkowo niewielka (20000) wymagałoby to od bazy MySQL wydajności na poziomie przekraczającym możliwości pojedynczego serwera, a pozostał by i tak problem blokad tabel na czas zapisu. W mongodb nie ma takiego problemu, zapisy nie blokują odczytów i są wykonywane na pamięci RAM. Odczyty są dość proste i nie ma konieczności stosowania relacji, założone indeksy są wyjątkowo trafne, operują bowiem na stałych parametrach (wyszukiwanie zawsze po id_uzytkownika, sortowanie zawsze po dacie wpisu, funkcjonalności takie jak ściana nie posiadają innych funkcji). W takiej sytuacji MongoDB jest wprost wymarzonym systemem, jakby został zaprojektowany właśnie w tym celu. Podsumowanie wyników wydajnościowych przeprowadzonych w środowisku produkcyjnym serwisów Gratka Technologie Podczas testowania MongoDB dział Rozwoju Gratki Technologie przeprowadził testy wydajnościowe na Mysql, Memcache i Mongo w środowisku analogicznym do produkcyjnego. Przeprowadzono dwa testy. Test pierwszy zakładał operacje na bazie użytkowników. Test przeprowadzono przy identycznych warunkach wejściowych dla baz Mysql i MongoDB i Memcache. Ilość danych w bazach: rekordów. Pobranie użytkownika po ID memcache 1.12 ms mongo 0.51 ms mysql 8.34 ms Odpytanie o nieistniejące ID: memcache 0.65 ms mongo 0.45 ms Mysql 9.35 ms

6 Drugi test zakładał przeszukiwanie bazy ogłoszeń działu nieruchomości w serwisie dom.gratka.pl. Baza zawierała 1mln rekordów a wyszukiwanie odbywało się po kilku polach z sortowaniem i limitem + count. Test przeprowadzono dla Mysql i MongoDB. Mysql: ~5s MongoDB: ~0.34s Wyniki mówią same za siebie. Dziękuję za uwagę Michał Giergielewicz.