Home > Blog > Po spotkaniu Railsowym

Po spotkaniu Railsowym

Published on 15/01/07
by Kuba Filipowski

Miałem przyjemność, kolejny już raz brać udział w Railsowych spotkaniach na Chłodnej 25. Impreza ze spotkania na spotkanie rozkręca się i zaczyna przybierać coraz ciekawszą formę. U Reuptake można szerzej o samym spotkaniu poczytać. Ale ja w sumie o czymś innym.

Otóż, po prezentacji Rafała Agnieszczaka z Fotka.pl coś mi po głowie zaczęło się kołatać. Rafał wspominał o problemach z wydajnością i kłopotach ze skalowalnością i w końcu sobie przypomniałem.

Jakiś czas temu czytałem materiały z Google Labs o Map/Reduce. Jest to udostępniona biblioteka do rozproszonego przetwarzania danych. Brzmi to w strasznie akademicko ale jest to o wiele bardziej w stylu Google.

A o co w nim chodzi?

Generalnie Google ma coś takiego jak Google File System (niestety nie upublicznione) co w skrócie służy do rozpowszechniania danych na tych tysiącach Googlowych serwerów. W paczkach po 64MB. I teraz ponieważ te dane są rozproszone po różnych nudzących się serwerach, więc następnym logicznym krokiem byłoby zaprząc te serwery do ich analizy. Mechanizm MapReduce na to pozwala. Przyznam, że dokładnie go nie rozumiem, ale wydaje mi się że wiem o co chodzi. Nie miałem motywacji ani potrzeby przetestować tego w praktyce, po jakimś teście pewnie bym wiedział dobrze już o co chodzi.

Natomiast do czego się to doskonale nadaje (sądząc po opisie)? Jeśli analiza jest robiona tylko na podstawie danych w jednej paczce to nie ma problemu sięgania po dane w paczkach znajdujących się na innych maszynach, więc wzrost szybkości przetwarzania jest w zasadzie liniowy – dodanie drugiego serwera zwiększa szybkość o 100%.

Jakiego typu zadania to powinno robić szybko? Np takie rzeczy jak wyszukiwanie patternów w dużych zestawach danych (np taki rozproszony grep, albo ‘prosty’ select z warunkami – ale bez sięgania do innych tablic). Jeśli by chcieć robić ’select z joinami’ to nie wiem czy liniowość przyrostu wydajności by się uchowała.

Dlaczego? Bo tutaj kluczem jest rozproszenie danych na maszynach i korelacja z danymi odpowiednich zadań – jeśli nie trzeba sięgać do innych serwerów przez sieć po dane (bo pracujemy na lokalnych paczkach) to sieć nie jest wąskim gardłem, tylko lokalne IO/procesor – czyli serwer pracuje nad danymi pełną parą.

Google dzięki GFS i odpowiedniej korelacji odpalanych zadań uzyskuje przemiały po 31GB/s (w tej prezentacji) bo sieć 1Gbps nie jest ograniczeniem.

Co jest dość istotne? Że jest dostępna implementacja MR dla Ruby on Rails… Czyli w Railsach można korzystać z tego praktycznie bez bóli implementacyjnych.

Ktoś kiedyś korzystał? Widzi zastosowanie? Bo jeśli tak to chętnie się przyjrzę/pomogę, gdyż nie ukrywam chciałbym mieć okazję użyć MapReduce w praktyce.

Co dalej?

Proszę skometuj ten tekst - jestem ciekawy co o nim myślisz. Możesz też podlinkować swój wpis używając trackbacku: Po spotkaniu Railsowym.