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

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ę?)

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 ).

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.

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.