Powody, dla których NIE jest zwiększanie skali w stosunku do -out?

Question

Jako programista dokonuję rewolucyjnych odkryć co kilka lat. Jestem albo przed zakrętem, albo za nim około π w fazie. Jedną z trudnych lekcji, których nauczyłem się, było to, że skalowanie OUT nie zawsze jest lepsze, często największe zyski wydajności są po przegrupowaniu i powiększeniu.

Jakie masz powody, by skalować się w górę? Cena, wydajność, wizja, przewidywane użycie? Jeśli tak, to w jaki sposób to zadziałało?

Raz wyskalowaliśmy do kilkuset węzłów, które serializowały i buforowały niezbędne dane do każdego węzła i uruchamiały procesy matematyczne w rekordach. Wiele, wiele miliardów rekordów musiało zostać poddanych analizie (krzyżowej). Był to doskonały biznes i przypadek techniczny do zastosowania skalowania. Optymalizowaliśmy do momentu, aż przetworzyliśmy około 24 godzin danych w ciągu 26 godzin na wallclock. Naprawdę długa historia, wynajęliśmy gigantyczny (na razie) IBM pSeries, umieściliśmy na nim Oracle Enterprise, zindeksowaliśmy nasze dane i zakończyliśmy przetwarzanie tych samych 24 godzin danych w około 6 godzin. Rewolucja dla mnie.

Tak wiele systemów dla przedsiębiorstw to OLTP, a dane nie są fragmentowane, ale pożądaniem wielu jest klastrowanie lub skalowanie. Czy jest to reakcja na nowe techniki lub postrzeganą wydajność?

Czy obecnie aplikacje są ogólnie dostępne, czy też nasze materiały programistyczne są lepsze do skalowania? Czy powinniśmy/powinniśmy brać ten trend zawsze pod uwagę w przyszłości?

Answer 1

Nic dziwnego, że wszystko zależy od twojego problemu. Jeśli możesz łatwo podzielić go na podproblemy, które nie komunikują się zbyt wiele, skalowanie daje niewielkie przyspieszenia. Na przykład wyszukiwanie słowa na stronach internetowych 1B może odbywać się za pomocą jednego komputera wyszukującego strony 1B lub przez maszyny 1M, które wykonują 1000 stron, bez znaczącej utraty wydajności (czyli z przyspieszeniem 1 000 000 x). Nazywa się to "żenująco równoległym".

Inne algorytmy wymagają jednak znacznie intensywniejszej komunikacji między podsekami. Twój przykład wymagający analizy krzyżowej jest doskonałym przykładem tego, gdzie komunikacja często może zagłuszyć wzrost wydajności dodawania kolejnych skrzynek. W takich przypadkach będziesz chciał utrzymywać komunikację wewnątrz (większego) pudła, przechodząc przez szybkie połączenia, a nie coś tak "powszechnego" jak (10-) Gig-E.

Oczywiście jest to dość teoretyczny punkt widzenia. Inne czynniki, takie jak I/O, niezawodność, łatwość programowania (jedna duża maszyna z pamięcią wspólną zwykle daje o wiele mniej bóle głowy niż klaster) może również mieć duży wpływ.

Wreszcie, ze względu na (często ekstremalne) korzyści kosztowe związane z skalowaniem za pomocą taniego sprzętu towarowego, podejście klaster/sieć przyciągnęło ostatnio znacznie więcej (algorytmicznych) badań. To sprawia, że ​​opracowano nowe sposoby zrównoleglania, które minimalizują komunikację, a przez to znacznie lepiej w klastrze - podczas gdy powszechna wiedza używana do dyktowania, że ​​tego typu algorytmy mogą działać efektywnie tylko na dużych maszynach żelaznych ...

Answer 2

Ponieważ przeskalowanie

• ogranicza się ostatecznie o wielkości pudełka rzeczywiście można kupić
• może być bardzo nieefektywne kosztowo, np maszyna ze 128 rdzeniami i 128-gramowym ramieniem jest znacznie droższa niż 16, z 8 rdzeniami i 8G pamięciami każdy.
• Niektóre rzeczy nie są dobrze skalowane - na przykład operacje odczytu IO.
• Skalowanie, jeśli Twoja architektura ma rację, możesz także osiągnąć wysoką dostępność. 128-rdzeniowe urządzenie z 128-bitowym ramieniem jest bardzo drogie, ale posiadanie drugiego zbędnego jest wygórowane.

A także do pewnego stopnia, ponieważ tak właśnie robi Google.

Answer 3

Skalowanie jest najlepsze dla problemów z embarrassingly parallel. To wymaga trochę pracy, ale wiele serwisów internetowych pasuje do tej kategorii (stąd aktualna popularność). W przeciwnym razie natkniesz się na Amdahl's law, co oznacza, że ​​musisz zwiększyć prędkość, aby nie skalować. Podejrzewam, że wpadłeś na ten problem. Operacje związane z IO mają również tendencję do radzenia sobie z skalowaniem w dużej mierze dlatego, że oczekiwanie na IO zwiększa%, który jest możliwy do zrównoleglenia.

Answer 4

Wpis na blogu Scaling Up vs. Scaling Out: Hidden Costs autorstwa Jeffa Atwooda ma kilka interesujących punktów do rozważenia, takich jak licencjonowanie oprogramowania i koszty zasilania.