Jakie typy systemów muszą „skalować”, a nie „skalować”?

12

Od dłuższego czasu zastanawiam się, czy istnieją systemy, które muszą „skalować” (na bardziej wydajny, droższy serwer) niż „skalować” poprzez podział na wiele mniejszych serwerów.

Czy takie systemy istnieją, a jeśli tak, to czy jest coś w szczególności, co powoduje, że systemy muszą być skalowane, a nie skalowane? (Na przykład może to powodować transakcje w bazie danych skarg ACID lub inne surowe wymagania dotyczące integralności danych).

Ponieważ skalowanie wydaje się, że przyniosłoby znacznie wyższe koszty sprzętu niż skalowanie, wydaje się, że chciałbyś tego uniknąć, jeśli to możliwe, ale nie jestem pewien, czy zawsze można tego uniknąć, czy nie.

Czy istnieją systemy, których nie można skalować, a zamiast tego trzeba skalować? Co może to powodować i jak zidentyfikowałbyś taki system? (Czy ogólnie mają one wspólne cechy, które mogłyby ułatwić ich identyfikację?)

Demi
źródło
7
Skalowanie jest często znacznie łatwiejsze, jeśli oprogramowanie nie zostało zaprojektowane do skalowania. Ponowne projektowanie oprogramowania jest drogie lub niemożliwe, jeśli nie jesteś właścicielem źródła lub masz wpływ na programistów.
Zoredache
Pisanie takich systemów to bardzo trudny problem. Zwłaszcza projekty master / master, które mogą przychodzić i odchodzić tam, gdzie wielu mistrzów pisze do tych samych rekordów w tym samym czasie. Kto pisze pisze wygrywa?
Matt
3
Możesz być zainteresowany Twierdzeniem CAP . Zasadniczo usługa, która wymaga zarówno spójności, jak i dostępności, jak zdefiniowano w twierdzeniu, nie będzie tolerować podziału na partycje. Większość rzeczywistych wymagań może poświęcić pewną spójność dla ostatecznej spójności (ręcznie lub automatycznie obsłużyć niespójność po fakcie) lub poświęcić dostępność, odmawiając przetworzenia żądania, gdy niektórzy uczestnicy są niedostępni. Dlatego systemy, które wymagają zarówno absolutnej spójności, jak i absolutnej dostępności, są zasadniczo zmuszane do skalowania.
Lie Ryan,
1
Jeśli przez „niezawodną sieć LAN” rozumiesz „nigdy nie ma awarii”, to nie projektujesz dla prawdziwego świata.
mfinni

Odpowiedzi:

18

Pracuję przede wszystkim z aplikacją, która ma zerowy potencjał skalowania w poziomie . Mimo że działa w systemie Linux, aplikacja, struktury danych i wymagania we / wy zmuszają mnie do „skalowania” do coraz większych systemów w celu dostosowania do zwiększonego obciążenia użytkowników.

Wiele starszych aplikacji biznesowych i transakcyjnych ma tego rodzaju ograniczenia. To jeden z powodów, dla których podkreślam, że branża koncentruje się na rozwiązaniach chmurowych i architekturach sieciowych opartych na DevOps, ignoruje spory procent świata komputerowego.

Niestety systemy skalowania, które opisuję, są naprawdę nieprzyjemne , więc branża zwykle ignoruje ich wartość lub odrzuca umiejętności potrzebne do radzenia sobie z dużymi, krytycznymi systemami (np. Bydło kontra zwierzęta domowe ).

ewwhite
źródło
1
„najłatwiej jest rzucić sprzęt na problem”. Proszę, prawo Moore'a, nie przestawaj działać!
cjc
2
@Demetri - Microsoft SQL Server jest najbardziej „wysokim profilem”, jaki mogę sobie wyobrazić, jest to typowe „skalowanie w górę”, a nie „skalowanie w górę”. Skalowanie go jest prawie niemożliwe, chyba że spełni się bardzo określony zestaw kryteriów replikacji scalającej.
Mark Henderson
3
Lub jeśli możesz rozłożyć rozwiązanie na wiele problemów. Na przykład nie uruchamiaj raportów dla bazy danych transakcji; trafiła replikę działającą na innym sprzęcie. \
mfinni
1
-1. Myślę, że nie trafiłeś w sedno problemu. Twój problem nie jest zmuszony do skalowania, jeśli możesz przepisać system dla systemu skalowania w dół. To pytanie o systemy, w których problematyka jest taka, że ​​skalowanie w górę nie jest w ogóle możliwe, nawet jeśli jest projektowane od podstaw.
Lie Ryan
1
@LieRyan Zrozumienie. Twierdzę, że obsługiwanej przeze mnie aplikacji nie można skalować (jest to system podobny do bazy danych) ... nawet jeśli zostanie przeprojektowany z powodu ograniczeń architektonicznych.
ewwhite
8

Z perspektywy dewelopera mogę powiedzieć, że prawie każdy tradycyjny główny silnik bazy danych może jedynie skalować w górę, a skalowanie jest bardzo przemyślane.

W ostatnich latach, w związku z potrzebą większej skalowalności i wysokiej dostępności systemów, podjęto starania, aby istniejące bazy danych były skalowane. Ponieważ jednak projekty są utrudniane przez starszy kod, jest on po prostu mocno oparty na projekcie, a nie jego podstawowym znaczeniu. Spotkasz się z tym, jeśli spróbujesz skalować większość dobrze znanych silników baz danych. Dodawanie serwerów podrzędnych może być dość trudne do skonfigurowania, a zauważysz, że wiąże się to ze znacznymi ograniczeniami, z których niektóre mogą wymagać ponownego osadzenia tabel bazy danych.

Na przykład większość z nich jest projektami master / (multi-) slave, a nie multi-master. Innymi słowy, cały serwer może po prostu tam siedzieć i nie być w stanie przetwarzać zapytań. Niektóre robią to, ale z ograniczeniami ... np. Tylko do odczytu dla wielu urządzeń typu slave. Być może masz jeden serwer, który zapisuje, a wszystkie pozostałe zapewniają dane tylko do odczytu. Zauważysz, że po skonfigurowaniu tych systemów nie zawsze jest to prosty proces i trudno jest dobrze działać. W wielu przypadkach wydaje się bardzo trudny do dodania.

Z drugiej strony, od samego początku opracowywane są nowe silniki baz danych z jednoczesną i wieloplatformową konstrukcją. NOSQL i NewSQL to nowa klasa projektowa.

Wydaje się więc, że najlepszym sposobem na uzyskanie lepszej wydajności z tradycyjnego serwera SQL jest zwiększenie skali! W przypadku NOSQL i NewSQL zarówno skalowanie w górę, jak i skalowanie w górę.

Powodem, dla którego tradycyjne systemy RDBMS są ściśle powiązane, jest to, że wszystkie potrzebują spójnego widoku tych samych danych. Jeśli masz wiele serwerów, które akceptują aktualizacje tych samych danych od różnych klientów, któremu z nich ufasz? Każda metoda, która próbuje zapewnić spójność danych za pomocą pewnego rodzaju mechanizmu blokującego, wymaga współpracy z innymi serwerami, która albo obniża wydajność, albo wpływa na jakość danych, ponieważ wszelkie dane odczytywane przez klienta mogą być nieaktualne. A serwery muszą decydować między sobą, które dane są najnowsze, zapisując do tego samego rekordu. Jak widać, jest to złożony problem, który jest bardziej złożony, ponieważ obciążenie rozkłada się na serwery, a nie tylko na procesy lub wątki, w których dostęp do danych jest wciąż dość szybki.

Matt
źródło
Czy Oracle RAC nie zapewniał skalowania od 10 g?
Dani_l
To ma. Ale posiadanie RAC i bezbłędnie działający RAC to dwie różne rzeczy - to naprawdę wymaga szczególnej uwagi, aby kontynuować. To jednak niezły projekt. Jeśli będziesz go potrzebować, prawdopodobnie zechcesz zapłacić cenę.
TomTom
I zwróć uwagę na wspólny system pamięci wymagany dla Oracle RAC. Może to stanowić problem skalowania w zależności od sposobu jego implementacji.
Matt
7

Moim zdaniem, demarkacja skali w górę / w dół jest określana na podstawie tego, jak równoległy może być przepływ pracy i jak ściśle muszą być koordynowane równoległe wątki.

Jednowątkowy
Z jakiegokolwiek powodu ten przepływ pracy może działać tylko w jednym wątku.

Jeden wątek oznacza, że ​​jeden system oznacza skalowanie w górę, aby przyspieszyć.

Ściśle sprzężona równoległość
Jest to system wielowątkowy, w którym gwinty muszą być ściśle ze sobą połączone. Być może komunikacja między procesami musi być bardzo szybka lub wszystko musi być zarządzane za pomocą jednego menedżera pamięci. Większość systemów RDBMS jest tego rodzaju obliczeniami równoległymi.

W przeważającej części, systemy te są te, które skala się lepiej niż na zewnątrz , choć zdarzają się wyjątki. Na przykład przepływy pracy, które działałyby w klastrze w stylu obrazu pojedynczego systemu , pojedynczej przestrzeni pamięci, ale duże opóźnienia między wątkami, mogą ułatwić skalowanie. Ale takie systemy SSI są bardzo trudne do pracy, więc większość inżynierów po prostu robi większe pudło.

Luźno sprzężona równoległość
Jest to system wielowątkowy / procesowy, w którym wątki są w porządku z dużymi opóźnieniami między sobą. Lub wcale nie musisz ze sobą rozmawiać. Skalowane serwery WWW i farmy renderujące to klasyczne przykłady tego rodzaju systemu. Takie systemy są o wiele łatwiejsze do uzyskania większej niż ściśle sprzężona równoległość, dlatego jest wiele emocji związanych z tym stylem systemu.

To jest styl, gdzie skala na zewnątrz jest dużo łatwiejsze.

sysadmin1138
źródło
Powodem, dla którego RDBMS są ściśle powiązane, jest to, że są ściśle powiązane z danymi. tj. wiele serwerów uzyskujących dostęp do tego samego zasobu.
Matt