Różnica między skalowaniem poziomym i pionowym dla baz danych

Skalowalność pozioma to zdolność do zwiększania pojemności poprzez łączenie wielu jednostek sprzętowych lub programowych, tak aby działały one jako jedna jednostka logiczna.

Gdy serwery są klastrowane, oryginalny serwer jest skalowany poziomo. Jeśli klaster wymaga więcej zasobów, aby poprawić wydajność i zapewnić wysoką dostępność (HA), administrator może skalować, dodając więcej serwerów do klastra.

Ważną zaletą skalowalności poziomej jest to, że może zapewnij administratorom możliwość zwiększania pojemności w locie. Kolejną zaletą jest to, że w teorii skalowalność pozioma jest ograniczona tylko przez to, ile podmiotów można z powodzeniem połączyć. Na przykład rozproszony system pamięci masowej Cassandra działa w oparciu o setki węzłów towarowych rozmieszczonych w różnych centrach danych. Ponieważ sprzęt towarowy jest skalowany poziomo, Cassandra jest odporna na błędy i nie ma pojedynczego punktu awarii (SPoF).

Pionowe z drugiej strony skalowalność zwiększa pojemność, dodając do maszyny więcej zasobów, takich jak więcej pamięci lub dodatkowy procesor. Skalowanie w pionie, które jest również nazywane skalowaniem w górę, zwykle wymaga przestojów podczas dodawania nowych zasobów i ma limity zdefiniowane przez sprzęt. Gdy klienci Amazon RDS muszą na przykład skalować w pionie, mogą przełączyć się z mniejszego na większy komputer, ale największa instancja Amazon RDS ma tylko 68 GB pamięci.

Skalowanie poziomo ma zarówno zalety, jak i wady. Na przykład dodanie niedrogich komputerów towarowych do klastra może wydawać się opłacalnym rozwiązaniem na pierwszy rzut oka, ale ważne jest, aby administrator wiedział, czy koszty licencji dla tych dodatkowych serwerów, dodatkowe koszty operacji zasilania i chłodzenia oraz duże rozmiary, które zajmą w centrum danych, naprawdę sprawiają, że skalowanie poziome jest lepszym Wyborem niż skalowanie pionowe.

Istnieje dodatkowa Architektura, o której nie wspomniano - usługi bazodanowe oparte na SQL, które umożliwiają skalowanie poziome bez złożoności ręcznego odłamywania. Usługi te wykonują sharding w tle, dzięki czemu umożliwiają uruchamianie tradycyjnej bazy danych SQL i skalowanie się tak, jak w przypadku silników NoSQL, takich jak MongoDB lub CouchDB. Dwie usługi, które znam to EnterpriseDBdla PostgreSQL i Xeround dla MySQL. Widziałem w głębi post przez Xeround co wyjaśnia, dlaczego skalowanie na bazach danych SQL jest trudne i jak robią to inaczej-traktuj to z przymrużeniem oka, ponieważ jest to post sprzedawcy. Sprawdź również wpis w bazie danych w chmurze Wikipedii, jest ładne Wyjaśnienie SQL vs. NoSQL i service vs. self-hosted, lista dostawców i opcje skalowania dla każdej kombinacji. ;)

Tak skalowanie poziomo oznacza dodawanie większej liczby maszyn, ale oznacza również, że maszyny są równe w klastrze. MySQL może skalować się poziomo pod względem odczytu danych, poprzez użycie replik, ale gdy osiągnie pojemność mem/dysku serwera, musisz rozpocząć dzielenie danych między serwerami. Staje się to coraz bardziej złożone. Często utrzymywanie spójności danych w replikach jest problemem, ponieważ tempo replikacji jest często zbyt wolne, aby nadążyć za szybkością zmiany danych.

Couchbase to również fantastyczna baza skalowania poziomego NoSQL, używana w wielu komercyjnych aplikacjach i grach o wysokiej dostępności i prawdopodobnie najwyższa wydajność w tej kategorii. Partycjonuje dane automatycznie w całym klastrze, dodawanie węzłów jest proste i można używać sprzętu towarowego, tańszych instancji maszyn wirtualnych(na przykład dużych zamiast wysokich Mem, wysokich maszyn dyskowych w AWS). Jest zbudowany z Membase (Memcached), ale dodaje trwałości. Ponadto, w przypadku Couchbase, każdy node może odczytywać i zapisywać, i są równe w klastrze, tylko z replikacją awaryjną (Nie pełną replikacją zestawu danych na wszystkich serwerach, jak w mySQL).

Pod względem wydajności, można zobaczyć doskonały benchmark Cisco: http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server

Oto świetny wpis na blogu o architekturze Couchbase: http://horicky.blogspot.com/2012/07/couchbase-architecture.html

Tradycyjne relacyjne bazy danych, gdzie zaprojektowane jako systemy baz danych klient / serwer. Można je skalować poziomo, ale proces ten jest złożony i podatny na błędy. Bazy danych NewSQL likeNuoDB są rozproszonymi systemami bazodanowymi zorientowanymi na pamięć, zaprojektowanymi do skalowania poziomo przy zachowaniu właściwości SQL/ACID tradycyjnych RDBMS.

Aby uzyskać więcej informacji na temat NuoDB, przeczytaj ich dokumentację techniczną pod adresem http://goo.gl/uzLIWB .

Zacznijmy od potrzeby skalowania, które Zwiększa zasoby, aby Twój system mógł teraz obsłużyć więcej żądań niż wcześniej.

Kiedy zdasz sobie sprawę , że Twój system robi się powolny i nie jest w stanie obsłużyć bieżącej liczby żądań, musisz skalować system .

Zapewnia to dwie opcje, albo zwiększasz zasoby na serwerze, z którego obecnie korzystasz, tj. zwiększasz ilość pamięci ram, procesora, gpu i innych zasobów .To jest znany jako skalowanie pionowe .

Skalowanie pionowe jest zazwyczaj kosztowne . Nie czyni to systemu odpornym na błędy, tzn. jeśli skalujesz aplikację działającą z jednym serwerem, jeśli ten serwer ulegnie awarii, system ulegnie awarii . Również ilość wątków pozostaje taka sama w skalowaniu pionowym . Skalowanie pionowe może wymagać, aby system został na chwilę wyłączony, gdy proces ma miejsce . Zwiększenie zasobów na serwerze wymaga ponownego uruchomienia i wyłączenia systemu .

Innym rozwiązaniem tego problemu jest zwiększenie ilości serwerów obecnych w systemie . Rozwiązanie to jest szeroko stosowane w przemyśle technologicznym . To ostatecznie zmniejszy liczbę żądań na sekundę na każdym serwerze . Jeśli chcesz skalować system, po prostu dodaj inny serwer i gotowe . Nie musisz ponownie uruchamiać systemu . Zmniejsza się liczba wątków w każdym systemie, co prowadzi do wysokiej przepustowości . Segregować wnioski, jednakowo do każdego z wniosków serwer, musisz dodać load balancer, który będzie działał jako odwrotne proxy do serwerów internetowych . Cały ten system można nazwać pojedynczym klastrem . Twój system może zawierać dużą liczbę żądań, które wymagałyby większej liczby klastrów, takich jak ten .

Mam nadzieję, że otrzymasz całą koncepcję wprowadzenia skalowania do systemu

Bazy danych SQL, takie jak Oracle, db2, również obsługują skalowanie poziome poprzez współdzielony klaster dysków. Na przykład Oracle RAC, IBM DB2 purescale lub Sybase ASE Cluster edition. Nowy węzeł można dodać do systemu Oracle RAC lub systemu DB2 purescale w celu uzyskania skalowania poziomego.

Ale podejście różni się od baz danych noSQL (takich jak mongodb, CouchDB lub IBM Cloudant) tym, że sharding danych nie jest częścią skalowania poziomego. W bazach noSQL dane są dzielone podczas poziomego skalowanie.

Wszystkie inne odpowiedzi wydają się już całkiem kompletne, ale nie widziałem Google Cloud Spanner jako przykład relacyjnej bazy danych ze skalowaniem poziomym, dlatego dodaję mój mały wkład.

Dodanie wielu równoważników obciążenia powoduje dodatkowe obciążenie i opóźnienia, co jest wadą skalowania poziomego w bazach danych nosql. To jest jak pytanie, dlaczego ludzie mówią, że RPC nie jest zalecane, ponieważ nie jest solidny.

Myślę, że w prawdziwym systemie powinniśmy używać zarówno baz danych sql, jak i nosql, aby wykorzystać zarówno wielordzeniowe, jak i chmurowe możliwości dzisiejszych systemów.

Z drugiej strony złożone zapytania transakcyjne mają wysoką wydajność, jeśli bazy danych sql, takie jak oracle jest używany. NoSql może być używany do skalowania bigdata i horizontal poprzez sharding.