Różnica między skalowaniem w poziomie i w pionie dla baz danych [zamknięte]

Natknąłem się na wiele baz danych NoSQL i SQL. Istnieją różne parametry do pomiaru siły i słabości tych baz danych, a skalowalność jest jednym z nich. Jaka jest różnica między skalowaniem w poziomie i w pionie tych baz danych?

Skalowanie w poziomie oznacza, że ​​skalujesz, dodając więcej maszyn do puli zasobów, podczas gdy skalowanie w pionie oznacza, że ​​skalujesz, dodając więcej mocy (procesora, pamięci RAM) do istniejącej maszyny .

Łatwym sposobem na zapamiętanie tego jest myślenie o maszynie na szafie serwerowej, dodajemy więcej maszyn w kierunku poziomym i dodajemy więcej zasobów do maszyny w kierunku pionowym .

W świecie baz danych skalowanie w poziomie często opiera się na partycjonowaniu danych, tj. Każdy węzeł zawiera tylko część danych, w skalowaniu w pionie dane znajdują się w jednym węźle, a skalowanie odbywa się za pomocą wielordzeniowego, tj. Rozkładania obciążenia między zasoby procesora i pamięci RAM tego komputera.

Przy skalowaniu w poziomie często łatwiej jest dynamicznie skalować, dodając więcej maszyn do istniejącej puli - Skalowanie w pionie jest często ograniczone do wydajności pojedynczej maszyny, skalowanie poza tę pojemność często wiąże się z przestojami i ma górną granicę.

Dobrym przykładem skalowania w poziomie są Cassandra, MongoDB, Google Cloud Spanner .. a dobrym przykładem skalowania w pionie jest MySQL - Amazon RDS (wersja MySQL w chmurze). Zapewnia łatwy sposób skalowania w pionie poprzez przełączanie z małych na większe maszyny. Ten proces często obejmuje przestoje.

Siatki danych w pamięci, takie jak GigaSpaces XAP , Koherencja itp., Są często zoptymalizowane do skalowania w poziomie i pionie po prostu dlatego, że nie są powiązane z dyskiem. Skalowanie w poziomie poprzez partycjonowanie i skalowanie w pionie poprzez obsługę wielu rdzeni.

Możesz przeczytać więcej na ten temat w moich wcześniejszych postach: Skalowanie w górę a skalowanie w górę i wspólne zasady alternatyw NOSQL

Skalowanie w poziomie ===> Tysiące stworów wykona za ciebie wspólną pracę.

Skalowanie w pionie ===> Jeden wielki kadłub wykona za ciebie całą pracę.

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 działa powoli i nie jest w stanie obsłużyć bieżącej liczby żądań, musisz skalować system.

Zapewnia to dwie opcje. Albo zwiększysz zasoby na serwerze, którego obecnie używasz, tj. Zwiększysz ilość pamięci RAM, procesora, GPU i innych zasobów. Jest to znane jako skalowanie pionowe.

Skalowanie w pionie jest zwykle kosztowne. Nie powoduje to, że system jest odporny na awarie systemu, tzn. Jeśli skalujesz aplikację działającą z jednym serwerem, jeśli ten serwer ulegnie awarii, system przestanie działać. Również liczba wątków pozostaje taka sama w skalowaniu pionowym. Skalowanie w pionie może wymagać obniżenia systemu na moment, 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 liczby serwerów obecnych w systemie. To rozwiązanie jest szeroko stosowane w branży technologicznej. Spowoduje to w końcu zmniejszenie liczby żądań na sekundę na każdym serwerze. Jeśli chcesz skalować system, po prostu dodaj kolejny serwer i gotowe. Nie będzie wymagane ponowne uruchomienie systemu. Liczba wątków w każdym systemie maleje, co prowadzi do wysokiej przepustowości. Aby segregować żądania, jednakowo dla każdego serwera aplikacji, należy dodać moduł równoważenia obciążenia, który działałby jako odwrotne proxy dla serwerów WWW. Cały system można nazwać jednym klastrem. Twój system może zawierać dużą liczbę żądań, które wymagałyby większej liczby takich klastrów.

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

Istnieje dodatkowa architektura, o której nie wspomniano - usługi baz danych oparte na SQL, które umożliwiają skalowanie w poziomie bez złożoności ręcznego dzielenia na fragmenty. Usługi te dzielą fragmenty w tle, więc umożliwiają uruchamianie tradycyjnej bazy danych SQL i skalowanie w taki sam sposób, jak w przypadku silników NoSQL, takich jak MongoDB lub CouchDB. Dwie znane mi usługi to EnterpriseDB dla PostgreSQL i Xeround dla MySQL. Widziałem pogłębiony post Xeround, który wyjaśnia, dlaczego skalowanie w bazach danych SQL jest trudne i jak to robią inaczej - potraktuj to odrobiną soli, ponieważ jest postem dostawcy. Zobacz także wpis w chmurze w Wikipedii, istnieje ładne wyjaśnienie SQL vs. NoSQL i usługa vs. hostowane, lista dostawców i opcje skalowania dla każdej kombinacji. ;)

Tak, skalowanie w poziomie oznacza dodawanie kolejnych komputerów, ale oznacza również, że maszyny są równe w klastrze. MySQL może skalować się w poziomie pod względem odczytu danych, dzięki użyciu replik, ale gdy osiągnie pojemność pamięci / dysku serwera, musisz rozpocząć dzielenie danych między serwerami. To staje się coraz bardziej złożone. Często problemem jest utrzymywanie spójności danych w replikach, ponieważ częstości replikacji są często zbyt wolne, aby nadążyć za szybkościami zmiany danych.

Couchbase to także fantastyczna baza danych NoSQL Horizontal Scaling, używana w wielu komercyjnych aplikacjach i grach o wysokiej dostępności i prawdopodobnie najwyższej wydajności w tej kategorii. Automatycznie dzieli dane na klastry, dodawanie węzłów jest proste, a można użyć sprzętu towarowego, tańszych instancji VM (na przykład dużych zamiast wysokiej pamięci, maszyn z wysokim dyskiem w AWS). Jest zbudowany na bazie Membase (Memcached), ale dodaje trwałości. Ponadto w przypadku Couchbase każdy węzeł może odczytywać i zapisywać i jest równy w klastrze, tylko z replikacją awaryjną (nie pełna replikacja zestawu danych na wszystkich serwerach, tak jak w mySQL).

Pod względem wydajności możesz zobaczyć doskonały test porównawczy 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 zostały zaprojektowane jako systemy baz danych klient / serwer. Można je skalować w poziomie, ale proces ten jest z reguły złożony i podatny na błędy. Bazy danych NewSQL, takie jak NuoDB, to rozproszone systemy baz danych zorientowane na pamięć, zaprojektowane do skalowania w poziomie przy jednoczesnym zachowaniu właściwości SQL / ACID tradycyjnych RDBMS.

Więcej informacji na temat NuoDB znajduje się w ich białej księdze technicznej .

Bazy danych SQL, takie jak Oracle, db2, obsługują również skalowanie w poziomie za pośrednictwem klastra dysków udostępnionych. 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 purescale DB2, aby uzyskać skalowanie w poziomie.

Jednak podejście różni się od baz danych noSQL (takich jak mongodb, CouchDB lub IBM Cloudant), ponieważ dzielenie danych nie jest częścią skalowania poziomego. W bazach danych noSQL dane są usuwane podczas skalowania poziomego.

Masz firmę i jest tylko 1 pracownik, ale w tym czasie masz 1 nowy projekt, zatrudniasz nowego kandydata - jest to skalowanie poziome. gdzie nowy kandydat to nowe maszyny, a projekt to nowy ruch / połączenia z interfejsem API.

Gdzie jako 1 projekt z facetem IIT / NIT obsługującym wszystkie żądania do twojego interfejsu API / ruchu. Jeśli kiedykolwiek poprosisz o api, zwolnij go i zastąp go facetem o wysokim IQ NIT / IIT - jest to skalowanie pionowe.

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

Myślę, że w prawdziwym systemie powinniśmy używać zarówno baz danych sql, jak i nosql, aby wykorzystywać zarówno możliwości przetwarzania wielordzeniowego, jak i chmurowego w dzisiejszych systemach.

Z drugiej strony złożone zapytania transakcyjne mają wysoką wydajność, jeśli używane są bazy danych SQL, takie jak Oracle. NoSql może być wykorzystywany do bigdata i skalowania poziomego poprzez sharding.

Przyjęta odpowiedź jest punktowa w podstawowej definicji skalowania poziomego vs pionowego. Ale w przeciwieństwie do powszechnego przekonania, że ​​skalowanie w poziomie baz danych jest możliwe tylko w Cassandrze, MongoDB itp. Chciałbym dodać, że skalowanie w poziomie jest również bardzo możliwe w przypadku każdego tradycyjnego RDMS; to również bez korzystania z rozwiązań innych firm.

Znam wiele firm, zwłaszcza takich, które działają w oparciu o SaaS. Odbywa się to za pomocą prostej logiki aplikacji. Zasadniczo bierzesz zestaw użytkowników i dzielisz ich na wiele serwerów DB. Na przykład zazwyczaj miałbyś „meta” bazę danych / tabelę, która przechowywałaby klientów, serwer DB / parametry połączenia itp. Oraz tabelę przechowującą mapowanie klient / serwer.

Następnie po prostu kieruj żądania od każdego klienta do serwera DB, na który są mapowane.

Teraz niektórzy mogą powiedzieć, że jest to podobne do podziału poziomego, a nie „prawdziwego” skalowania poziomego i pod pewnymi względami będą słuszne. Ale efekt końcowy jest taki, że przeskalowałeś DB na wielu serwerach Db.

Jedyną różnicą między dwoma podejściami do skalowania poziomego jest to, że jedno podejście (MongoDB itp.) Skalowanie jest wykonywane przez samo oprogramowanie DB. W tym sensie „kupujesz” skalowanie. W drugim podejściu (w przypadku skalowania poziomego RDBMS) skalowanie jest budowane według kodu / logiki aplikacji.