poniedziałek, 31 maja 2010

O skalowaniu baz danych słów kilka

Część druga o skalowalności. Dzisiaj trochę o bazach danych które sprawiają zawsze najwięcej problemów.

Ze względu na naturę baz danych, to co najbardziej obrywa na serwerze to dyski. Wszelkie zmiany muszą być jak najszybciej utrwalane żeby można było zwolnić blokady i zapewnić trwałość danych. Obojętnie jaki wypas serwer by się nie posiadało i tak w końcu dojdzie do tego, że nie będzie już posiadał możliwości by przyjąć więcej obciążenia, a nas nie będzie stać na zakup lepszego. Trzeba będzie się przeskalować w poziomie co jest trochę hardcorowe :)

Podejść jest kilka i chciałem omówić 3 najważniejsze z nich.

1. Master-Slave replication
W tym podejściu mamy jeden węzeł typu master oraz jeden lub więcej węzłów typu slave. Zadaniem węzła master jest tylko i wyłącznie przyjmowanie operacji modyfikacji danych. Ten serwer odpowiada za wszystkie zapytania typu INSERT, UPDATE i DELETE. Jest do tego specjalnie skonfigurowany by operacje te były jak najszybciej wykonywane. Węzły typu slave natomiast odpowiadają za wykonywanie zapytań typu SELECT. Może być ich kilka oczywiście. Aktualizują swoje dane poprzez asynchroniczną komunikację z węzłem master. Co określony czas przesyła on zgrupowane zapytania aktualizujące dane na węzłach slave.
Problemy związane z master-slave replication to:

  • na dobrą sprawę to nie ma tutaj skalowania poziomego. Co prawda mamy więcej węzłów, ale ciągle istnieje tylko jeden master, który może stać się wąskim gardłem, gdy liczba modyfikacji które musi wykonać przekroczy jego możliwości
  • synchronizacja aktualizowanych danych może powodować błędy. Jeśli klient coś zmodyfikuje i natychmiast to będzie chciał odczytać to może otrzymać błędne dane. To jednak można obejść stosując cache z polityką write-through
  • wymagana jest modyfikacja logiki aplikacji aby kierować SELECTy do slave, a modyfikacje do master
Podejście jest bardzo dobre, gdy mamy mało modyfikacji i dużo zapytań.

2. Database clustering 

Klastrowanie bazy danych polega na utworzeniu wielu instancji bazy danych współdzielących jedną wspólną pamięć trwałą. Daje to dużo większą przepustowość i nie wymaga prawie zmian w logice aplikacji.
Jednak posiada też wady:

  • SAN jest drogi i też ma swoje granice
  • wymagana jest kosztowna synchronizacja między wszystkimi węzłami (blokady itp.). Może nawet dojść do momentu, gdy dodanie nowego węzła spowolni działanie całości
3. Database sharding
Bazę danych można też podzielić na wiele mniejszych baz i tak z nich korzystać. Najpierw należy przeanalizować dokładnie sposób jej używania a później znaleźć grupy tabel które są używane razem w zapytaniach. Na tej podstawie można dzielić ją na mniejsze.
Problemy:

  • trzeba bardzo dobrze przemyśleć podział, każda późniejsza zmiana jest bardzo trudna do wprowadzenia
  • gdy jedna z mniejszych baz zacznie działać niewydajnie trzeba będzie ją znowu dzielić. Może dojść do tego, że trzeba będzie mięć np. 3 bazy danych z produktami
  • zapytania łączące z wielu baz są bardzo wolne
  • zapytania modyfikujące wymagają rozproszonych transakcji
  • wymaga znacznych zmian w logice aplikacji

To są tylko koncepcje, firmy w swoich produktach (tych "dużych" głównie) wprowadziły technologie, które ułatwiają skalowanie poziome. Np. w DB2 mamy Database Partitioning Feature, który jest połączeniem podejść database sharding i clustering i eliminuje kilka wad z nimi związanymi. 
Problem jest jednak bardzo złożony i wymaga długich przemyśleń. Trzeba zawsze pamiętać aby wdrożone rozwiązanie spełniało wymagania ACID.

5 komentarzy:

  1. Kolejny fajny artykulik o skalowalności :) O czym planujesz napisać następnym razem? :)

    OdpowiedzUsuń
  2. hej!
    Dzięki za komentarz;)
    Jeszcze nie wiem szczerze mówiąc. Trochę jestem zajęty przez magisterkę, ale może coś spłodzę w następnym tygodniu. Chyba już czas na jakieś praktyczne rzeczy:) Jestem otwarty na wszelkie propozycje ;)

    Pozdr!
    Łukasz

    OdpowiedzUsuń
  3. @WooKasZ - chętnie zobaczyłbym coś praktycznego :)

    OdpowiedzUsuń
  4. Jesteś w stanie polecić jakieś źródła opisujące w/w zagadnienia?

    OdpowiedzUsuń
    Odpowiedzi
    1. hej,

      szczerze to już nie pamiętam gdzie czytałem o tym wszystkim. Pamiętam, że czytałem wtedy sporo redbooków o DB2. Polecam za to blog: http://highscalability.com/ świetne źródło praktycznej wiedzy o tym jak rozwiązywane są takie problemy w znanych serwisach internetowych.

      Usuń