Szukałem wyjaśnienia, dlaczego twitter musiał migrować część swojego środkowego towaru z Railsów do Scali. Co uniemożliwiło im skalowanie sposobu działania Facebooka poprzez dodanie serwerów w miarę rozszerzania bazy użytkowników. Mówiąc dokładniej, co z technologią Ruby/Rails uniemożliwiło zespołowi Twittera takie podejście?Dlaczego nie można uzyskać skali na Twitterze, dodając serwery w taki sposób, jaki mają witryny takie jak Facebook?
Nie chodzi o to, że Rails nie skaluje się, ale raczej żądania dla "żywych" danych w Ruby (lub dowolnym zinterpretowanym języku) nie są skalowane, ponieważ są stosunkowo dużo droższe, zarówno pod względem wykorzystania pamięci CPU niż w przypadku CPU & niż ich odpowiedniki w języku kompilowanym.
Otóż, czy Twitter był innego rodzaju usługą, taki, który miał taką samą ogromną bazę użytkowników, ale podawane dane, które zmieniały się rzadziej, Railsy mogą być realną opcją poprzez buforowanie; to jest unikanie na żywo żądań do stosu Railsów i rozładowywanie do serwera frontowego i/lub pamięci podręcznej DB w pamięci. Doskonały artykuł na ten temat:
How Basecamp Next got to be so damn fast
Jednak Twitter nie rów Rails do skalowania same problemy, zrobili przełącznik bo Scala, jako język, zapewnia pewny wbudowaną gwarancji o stan swojej Aplikacja, która interpretuje języki, nie może zapewnić: jeśli kompiluje, czas marnowania błędów, takich jak literówki z grubymi palcami, nieprawidłowe wywołania metod, nieprawidłowe deklaracje typów itp. po prostu nie może istnieć.
Dla Twittera TDD nie było wystarczające. Cytat z Dijkstra w Programowanie w Scala ilustruje ten punkt: "testowanie może jedynie udowodnić obecność błędów, nigdy ich nieobecność".W miarę jak ich zastosowanie rosło, coraz trudniej było im wyśledzić błędy. Magiczna tajemnicza trasa stawała się przeszkodą wykraczającą poza wydajność, więc postanowili zmienić. Na wszystkich kontach przytłaczający sukces, Twitter to Scala, co Facebook ma do PHP (chociaż Facebook używa własnego ultraszybkiego preprocesora C++, więc oszukuje trochę ;-))
Podsumowując, Twitter stał się przełącznikiem zarówno wydajności, jak i niezawodność. Oczywiście, Rails ma tendencję do bycia na czele innowacji, więc 99% niezwiązanych z Twittera aplikacji będących przedmiotem handlu na świecie może być dobrze zinterpretowane językiem (chociaż, jestem teraz solidnie po stronie skompilowanego języka ogrodzenia , Scala jest po prostu zbyt dobra!)
Zacznę od stwierdzenia, że bardzo lubię Scalę, mimo że wciąż jestem bardziej z Rubinowego. Odnosząc się do Dijkstry i dostrzeganych zalet pisania statycznego, muszę sparafrazować Richa Hickeya, który powiedział, że wszystkie błędy w oprogramowaniu produktywnym mają wspólną cechę, to, że przeszły test sprawdzania typu i testy jednostkowe. BTW: HipHop na Facebooku jest napisany w C++, a nie w C. –
Dzięki, zaktualizowany odnośnik do Facebooka w C++ z C. re: Hickey i pochodzenie błędów, na pewno, całkowicie się zgadzam, i z językami interpretowanymi nie ma sprawdzającego typu, więc klasa Błędy, które nie mogą istnieć w skompilowanym języku, muszą zostać przechwycone na poziomie testów jednostkowych w Ruby, PHP i in. Idąc naprzód, interesujące będzie przekonanie się, czy zinterpretowane lub skompilowane języki są falą przyszłości (podejrzewam, że to drugie), będzie fajnie się przekonać, niezależnie od tego ;-) – virtualeyes
Oczywiście istnieje kontrola typów w językach interpretowanych, ale w czasie wykonywania. Tbh, ale ledwie mogę skończyć z błędem typu w Ruby, z wyjątkiem przypadków, gdy coś jest 'nil', które nie powinno być. Tutaj Haskell's 'Maybe' monad lub Scala' Option' są dużą zaletą, podczas gdy rozwiązania Ruby, takie jak klejnot 'andand', są naprawdę kludgy. Nie sądzę, żeby któryś z paradygmatów był falą przyszłości, obie były już od jakiegoś czasu i prawdopodobnie tu zostaną. –
http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster linki do zestawu postów o zmianach, w tym przyzwoita historia kroków podjętych w czasie.
Krótka wersja jest taka, że Ruby i Rails nie zapewniły wydajności i niezawodności wymaganej dla usługi. Biorąc pod uwagę skalę, nie jest to zaskakujące; większość rozwiązań COTS nie jest zadowalająca na bardzo dużym końcu skali.
Wysoka skalowalność obejmuje wiele pytań dotyczących architektury na tym samym poziomie, w przypadku innych witryn, więc pomaga również odpowiedzieć na szersze pytania w tej dziedzinie.
Mogli oni rzucić więcej sprzętu na problem, ale jest o wiele droższy niż napisanie bardziej wydajnego kodu. Podobnie jak wiele wysokopoziomowych frameworków, Ruby on Rails jest świetny w wielu aspektach, ale wysoka wydajność nie jest jedną z nich. Skompilowane języki będą zawsze szybsze niż języki interpretowane.
"szybciej" - jeśli chodzi o liczbę cykli procesora potrzebną do wykonania czegoś, z pewnością. Na zajętych platformach jest to IO, które jest generalnie bardziej zabójcze. Niezależnie od tego, czy musisz trafić na dysk, czy też poczekać na serwer zdalny, aby wysłać Ci jakiś zestaw danych. Język jest czynnikiem, ale z wyjątkiem pewnych ograniczonych scenariuszy, prawdopodobnie nie decydującym czynnikiem. –
W tym konkretnym przypadku, jeśli czytasz wywiady, dość wyraźnie stwierdzono, że był to problem z wydajnością językową. – sosborn
Jeśli porównasz koszty przepisania dość grubej aplikacji w nowym języku i śmiesznie niskich cen sprzętu dzisiaj, byłbym ostrożny zakładając, że "po prostu" pisanie bardziej wydajnego kodu jest zawsze tańsze. –
Żadna platforma nie może w nieskończoność skalować, a jednocześnie zajmować się złożonymi zestawami danych, które zmieniają się z chwili na chwilę. Kwestie dotyczące języka i infrastruktury, ale sposób budowania witryny i schematy dostępu do danych mają większe znaczenie.
Jeśli kiedykolwiek grałeś w gry takie jak Transport Tycoon lub Settlers, gdzie musisz transportować zasoby, dowiesz się, w jaki sposób musisz być na bieżąco z aktualizowaniem infrastruktury w miarę wzrostu zużycia.
Platformy skalowania takie jak Facebook i Twitter to niekończące się zadanie. Masz stale rosnącą liczbę użytkowników i jesteś zmuszany do dodawania nowych funkcji i funkcji. Jest to ciągły proces ulepszania jednego bit, który powoduje większy nacisk na inny bit.
Rzucanie serwerów na problem nie zawsze jest odpowiedzią, a czasami może powodować więcej problemów.
+1 dla Osadników referencja – daniel
Myślę, że brakuje jednego ważnego fragmentu platformy. Tak, mieliśmy skompilowaną i zinterpretowaną argumentację oraz kilka innych. Ale jednym bardzo ważnym aspektem była rzeczywiście platforma. Istnieją różne maszyny wirtualne Ruby, ale żadna z nich nie sprawdziła twittera, mimo że dostroiła je całkiem sporo. Ale scala działa na JVM i twitter inżynierów, którzy mają z tym całkiem niezłe doświadczenie. Dlaczego nie spróbowali/wybrali JRuby? Cóż, domyślam się, że powody wymienione powyżej wchodzą w grę.
IIRC, Rails nie działał wtedy na JRuby. I nadal IIRC, uzyskanie Railsów do uruchomienia na JRuby miało znaczną pomoc ze strony Twittera. –
OK! Chodzi mi głównie o to, że chodziło o język, ale RÓWNIEŻ dlatego, że platforma JVM podjęła decyzję: – AndreasScheinert
Niestety, głosowanie w dół to brak kliknięcia na telefonie komórkowym. Skasowanie systemu zajmie około 53 minut, chyba że edytujesz swoją odpowiedź. – butch
Liniowe zyski z równoległością (co jest tym, czym jest wiele serwerów) są niezwykle rzadkie i zależą od aplikacji. Tak, istnieje - tak GPU wykonuje większość swojej pracy. Jeśli wyświetlasz strony statyczne, bez stanu sesji, tak też by było. Jednak w większości przypadków dodawanie serwerów nie zwiększa wydajności liniowo (tzn. 10 serwerów nie jest 10 razy szybszych niż 1 serwer), a oznacza, że wszelkie zyski, które można uzyskać na pojedynczym serwerze, będą miały znacznie więcej niż tylko dodawanie serwerów. To nie tak, że Twitter nie ma garści serwerów, prawda?
Facebook (i Google) skalują się, dodając więcej serwerów, ale jednocześnie dzielą swoją aplikację na różne usługi. Te usługi komunikują się za pośrednictwem uzgodnionego interfejsu i typu, a teraz mogą swobodnie budować te usługi w dowolnej technologii, która im odpowiada. Tylko dlatego, że czytasz, że Facebook używa php, nie oznacza, że wszystkie ich usługi zapleczowe są obsługiwane przez php (i to nie ma sensu, ponieważ w SOA możesz wybrać dowolny stos technologii).
Myślę, że ten film jest najlepszą odpowiedzią na pytanie:
„od Ruby na JVM” https://www.youtube.com/watch?v=ohHdZXnsNi8
O ile mi wiadomo, Twitter nie * wymiana * RoR z Scala. Zastąpiły one niektóre komponenty Scala, ale przedni koniec to Railsy. Myślę. I w zeszłym roku widziałem prezentację autorstwa kogoś z Twittera, mówiącą o wielu pracach, które wykonali, aby Ruby działała szybciej. –
http://canrailsscale.com/ ten link prawie odpowiada na pytanie. Ale, jak powiedział @virtualeyes, może się to zdarzyć z każdym interpretowanym językiem. – luchosrock
@luchosrock Ten link jest zepsuty, czy jest gdziekolwiek indziej? – Addison