doszedłem po wielu baz danych NoSQL i baz danych SQL. Istnieją różne parametry mierzące siłę i słabe strony tych baz danych, a skalowalność jest jedną z nich. Jaka jest różnica między skalowaniem w poziomie i w pionie tych baz danych?Różnica między skalowania w poziomie i pionie do baz
skalowanie poziome oznacza, że skala dodając więcej maszyn do swojej puli zasobów natomiast skalowanie w pionie oznacza, że skala dodając więcej energii (CPU, RAM) do istniejącej maszyny.
Łatwym sposobem, aby pamiętać, jest to, aby myśleć o maszynie na stojaku serwerze, dodajemy więcej maszyn w całej poziomej kierunku i dodać więcej zasobów na maszynie w pionowej kierunku.
w świecie baza danych poziomej skalowanie często opiera się na partycjonowanie danych czyli każdy węzeł zawiera tylko część danych, w pionowym skalowanie rezyduje danych na pojedynczym węźle i skalowanie odbywa się poprzez wielordzeniowe, tj. rozkładanie obciążenia między zasobami procesora i pamięci RAM tego komputera.
Przy skalowaniu poziomym często łatwiej jest skalować dynamicznie, 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órny limit.
Dobrym przykładem poziomej skalowania Cassandro, MongoDB .. i dobrym przykładem pionowej skalowania MySQL - Amazon RDS (Chmura wersja MySQL). Zapewnia łatwy sposób skalowania w pionie poprzez przełączanie z małych na większe maszyny. Ten proces często wiąże się z przestojami.
Siatki danych w pamięci, takie jak GigaSpaces XAP, Coherence itd. Są często zoptymalizowane do skalowania zarówno w poziomie, jak iw pionie, po prostu dlatego, że nie są związane z dyskiem. Skalowanie w poziomie poprzez podział i pionowe skalowanie poprzez wielordzeniowe wsparcie.
Możesz przeczytać więcej na ten temat na moich wcześniejszych wypowiedzi: Scale-out vs Scale-up i The Common Principles Behind the NOSQL Alternatives
Istnieje również Couchbase, Riak, HBase, CitrusLeaf i Infinispan, aby uzupełnić listę nieco dalej (jest ich więcej). – scalabl3
@Nati Shalom Czy bazy danych NOSQL są skalowane w poziomie? –
Czy można skalować MySQL w poziomie - może z pewnym rozszerzeniem lub narzędziem? –
Tak skalowania poziomo oznacza dodając więcej maszyn, ale również sugeruje, że maszyny są równe w klastrze. MySQL można skalować w poziomie w kategoriach odczytu danych za pomocą replik, ale gdy osiągnie pojemność pamięci/dysku serwera, należy rozpocząć odczytywanie danych na serwerach. Staje się to coraz bardziej złożone. Często problemem jest utrzymanie spójności danych w replikach, ponieważ współczynniki replikacji są często zbyt wolne, aby nadążyć za zmianami danych.
Couchbase jest również fantastyczna baza danych NoSQL Skalowanie w poziomie, stosowane w wielu komercyjnych zastosowań wymagających wysokiej dostępności oraz gry i prawdopodobnie najwyższym wykonawca w kategorii. Automatycznie dzieli dane na klastry, a dodawanie węzłów jest proste. Można korzystać ze sprzętu towarowego, tańszych instancji vm (na przykład przy użyciu maszyn typu Large zamiast High Mem, High Disk w AWS). Jest on zbudowany na bazie Membase (Memcached), ale dodaje trwałość. Ponadto, w przypadku Couchbase, każdy węzeł może wykonywać odczyty i zapisy, i są równe w klastrze, z tylko replikacją awaryjną (nie pełną replikacją zbiorów danych na wszystkich serwerach, jak w mySQL).
Performance-mądry, widać doskonałą odniesienia Cisco: http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server
Oto wielki post na blogu o Couchbase Architektury: http://horicky.blogspot.com/2012/07/couchbase-architecture.html
Istnieje dodatkowy architektura, która nie została wymieniona - na bazie SQL usługi baz danych, które umożliwiają skalowanie w poziomie bez złożoności odłamków ręcznych. Usługi te wykonują shardowanie w tle, dzięki czemu umożliwiają uruchamianie tradycyjnej bazy danych SQL i skalowanie tak, jak w przypadku silników NoSQL, takich jak MongoDB lub CouchDB. Dwie znane mi usługi to EnterpriseDB dla PostgreSQL i Xeround dla MySQL. Zobaczyłem, że Xeround ma głębokie post, co wyjaśnia, dlaczego skalowanie w bazach danych SQL jest trudne i jak robią to inaczej - traktuj to z przymrużeniem oka, ponieważ jest postem dostawcy. Zajrzyj także do Wikipedii: Cloud Database entry, istnieje dobre wytłumaczenie SQL vs. NoSQL i service vs. self-hosted, lista dostawców i opcje skalowania dla każdej kombinacji. ;)
Jako kolejny punkt danych, przesyłam kolejny post od Clustrix: http://www.clustrix.com/blog/bid/259950/scale-up-vs-scale-out – clieu
Co z Amazon RDS? –
Wiem, że to stary post ... tylko niektóre aktualizacje. Xeround zamknął sklep. Poziome opcje skalowania PostreSQL nie są tak naprawdę opcjami skalowania poziomego - są to tylko opcje replikacji bazy danych, w których można odradzić niektóre operacje do zreplikowanej bazy danych. –
Tradycyjne relacyjne bazy danych, w których zaprojektowano systemy bazodanowe klient/serwer. Można je skalować w poziomie, ale proces ten jest zwykle skomplikowany i podatny na błędy. Bazy danych NewSQL, takie jak NuoDB, są zorientowanymi na pamięć rozproszonymi systemami baz danych, zaprojektowanymi do skalowania w poziomie przy zachowaniu właściwości SQL/ACID tradycyjnych RDBMS.
Więcej informacji na temat NuoDB można znaleźć w ich biuletynie technicznym pod numerem http://goo.gl/uzLIWB.
Pozioma skalowalność to możliwość zwiększenia wydajności poprzez połączenie wielu elementów sprzętowych lub programowych w taki sposób, aby działały jako jedna jednostka logiczna.
Gdy serwery są klastrowane, oryginalny serwer jest skalowany w poziomie. Jeśli klaster wymaga więcej zasobów w celu zwiększenia wydajności i zapewnienia wysokiej dostępności (HA), administrator może skalować, dodając więcej serwerów do klastra.
Ważną zaletą skalowania poziomego jest to, że może on zapewnić administratorom możliwość zwiększania wydajności w locie. Kolejną zaletą jest to, że teoretycznie skalowalność pozioma jest ograniczona jedynie przez liczbę jednostek, z którymi można pomyślnie połączyć. Rozproszony system pamięci masowej Cassandra na przykład działa na setkach węzłów towarowych rozmieszczonych w różnych centrach danych. Ponieważ sprzęt towarowy jest skalowany w poziomie, Cassandra jest odporna na awarie i nie ma jednego punktu awarii (SPoF).
Z kolei skalowalność w pionie zwiększa pojemność, dodając do urządzenia więcej zasobów, takich jak więcej pamięci lub dodatkowego procesora. Skalowanie w pionie, które jest również nazywane skalowaniem, zwykle wymaga przestojów, podczas gdy dodawane są nowe zasoby i ma ograniczenia zdefiniowane przez sprzęt. Gdy klienci Amazon RDS muszą skalować w pionie, mogą na przykład przełączyć się z mniejszej na większą maszynę, ale największa instancja RDS firmy Amazon ma tylko 68 GB pamięci.
Skalowanie w poziomie ma zarówno zalety, jak i wady. Na przykład dodanie niedrogich komputerów do klastra może wydawać się na pierwszy rzut oka opłacalnym rozwiązaniem, ale ważne jest, aby administrator wiedział, czy koszty licencji na te dodatkowe serwery, dodatkowe koszty operacyjne zasilania i chłodzenia oraz duże rozmiary, które zajmą w centrum danych, rzeczywiście sprawiają, że skalowanie w poziomie jest lepszym wyborem niż skalowanie w pionie.
Skalowanie poziome - określane również jako "skalowanie" to w zasadzie dodanie większej liczby komputerów lub skonfigurowanie klastra lub rozproszonego środowiska dla systemu oprogramowania.Zazwyczaj wymaga to programu równoważenia obciążenia, który jest komponentem middle-ware w standardowym 3-rzędowym modelu architektonicznym klient-serwer.
Load-Balancer jest odpowiedzialny za rozłożenie żądań użytkownika (obciążenia) między różne systemy zaplecza/maszyny/węzły w klastrze. Każda z tych maszyn typu back-end uruchamia kopię twojego oprogramowania, dzięki czemu może obsługiwać żądania. Jest to tylko jedna z wielu funkcji, które może wykonywać równoważenie obciążenia. Inną bardzo powszechną odpowiedzialnością jest "kontrola stanu zdrowia", w której system równoważący obciążenie używa protokołu "ping-echo" lub wymienia komunikaty pulsu ze wszystkimi serwerami, aby upewnić się, że działają poprawnie.
Load-Balancer rozkłada obciążenie, utrzymując stan każdej maszyny - ile żądań jest obsługiwanych przez każdą maszynę, która maszyna jest bezczynna, która maszyna jest przeładowana kolejnymi żądaniami itd. Więc algorytm równoważenia obciążenia uważa, że rzeczy przed przekierowaniem żądania do odpowiedniego komputera serwera. Uwzględnia także obciążenie sieci i może wybrać serwer w najbliższym centrum danych, pod warunkiem, że jest on dostępny do obsługi żądań.
Żądanie-odpowiedź może być również wykonane w 2 różne sposoby:
równoważenia obciążenia zawsze działa jako program pośredniczący dla każdej odpowiedzi - W tym przypadku, gdy wniosek został przekazany do serwera przez moduł równoważenia obciążenia, każda reakcja serwera na użytkownika przechodzi przez moduł równoważenia obciążenia. Tak więc serwery, które faktycznie obsługują żądanie, nigdy nie będą bezpośrednio komunikować się z maszyną użytkownika, na którym działa aplikacja kliencka. Komputer obsługujący program równoważenia obciążenia będzie obsługiwał wszystkie żądania/odpowiedzi do i od użytkownika.
Load Balancer nie działa jako pośrednik dla odpowiedzi pochodzących z maszyny serwerowej - w tym przypadku, gdy serwer otrzyma żądanie od load-balancera, omija load balancer i przekazuje mu odpowiedzi bezpośrednio do serwera. klient.
Utworzenie klastra i systemu równoważenia obciążenia jako interfejsu front-end do aplikacji klienckiej nie uzupełnia w pełni naszej skalowalnej architektury i projektu. Nadal istnieje wiele kluczowych pytań, na które należy odpowiedzieć, oraz szereg kluczowych decyzji projektowych, które będą miały wpływ na ogólne właściwości naszego systemu.
Najpierw musimy określić nasze cele biznesowe i obszary, w których chcielibyśmy dodać wartość. Cele te będą źródłem różnych wymagań. Powinniśmy zadać sobie różne pytania dotyczące różnych właściwości systemowych.
Czy taki wzór spełnia nasze wymagania dotyczące wydajności?
Na jakie cechy wydajności dbamy? Czy jest to ogólna przepustowość systemu, w której jesteśmy zainteresowani obsługą maksymalnej liczby żądań w danym czasie? Czy jest to czas reakcji systemu, w którym projektujemy, aby odesłać odpowiedź do klienta w jak najkrótszym czasie? Zarówno te jak i wiele innych typów cech wydajności są ze sobą powiązane.
Czy taki wzór spełnia nasze wymagania dotyczące dostępności? Czy system jest odporny na awarie? Jeśli tak, jaki jest jej stopień?
Czy taka konstrukcja jest niezawodna? Czy ma to wpływ na poprawność? Nie powinniśmy zapominać, że 100% poprawność jest nieodłącznym celem każdego systemu.
Czy naprawdę realizujemy nasze cele w zakresie skalowalności? Może osiągnąć krótkoterminowe lub natychmiastowe, ale co się stanie w dłuższej perspektywie?
Wszystkie te rodzaje wymagań powinny mieć mierzalne środki z nimi związane.
Powinniśmy wtedy podejmować ważne decyzje projektowe, kwestionując siebie, opracowując prototypy i udoskonalając projekt.
Po pierwsze, stosowanie równoważenia obciążenia jest jedynym sposobem dystrybucji obciążenia i skalowania poziomego systemu?
Czy różne serwery zaplecza lub węzły komunikują się ze sobą? Jeśli tak, to w jaki sposób system rozwiązuje sytuację, w której jeden lub więcej węzłów zanika - na stałe lub tymczasowo? Jeśli tak, to w jaki sposób system rozwiązuje sytuację, w której sieć łącząca węzły jest wyłączona, ale wszystkie węzły są uruchomione? Co najważniejsze, czy musimy rozróżniać te dwie sytuacje? W jaki sposób ?
Wszystko to sprawia, że system rozproszony jest tak interesujący i trudny do zaprojektowania i wdrożenia.
Vertical Scaling - określane także jako „scale-up” podejście jest próbą zwiększenia zdolności jednej maszynie: Dodając więcej mocy obliczeniowej Dodając więcej pamięci więcej pamięci itp Podsumowanie:
Ważne jest, aby zrozumieć różnice między tymi dwoma podejściami skalowania, określić, jakie rozwiązania odpowiadają naszym wymaganiom i sprawdzić, czy aplikacja rzeczywiście pasuje do wybranego przez nas modelu.
Jak już zrozumiałeś, skalowanie poziome wiąże się z obciążeniem w postaci kosztów konfiguracji, zarządzania i konserwacji oraz złożoności. Projekt staje się coraz bardziej złożony i zmienia się modelowanie oprogramowania.
Po prostu wrzucanie nowego sprzętu i dodawanie kolejnych węzłów lub maszyn nie jest dobrym sposobem na rozpoczęcie pracy. Najpierw sprawdź, czy wymagania można spełnić, zwiększając pojemność lub charakterystykę strojenia pojedynczej maszyny. Jeśli nie, zastosuj metodę skalowania lub kombinację obu metod.
Bazy danych SQL, takie jak Oracle, db2 obsługuje również skalowanie w poziomie za pośrednictwem klastra Shared Disk. Na przykład Oracle RAC, IBM DB2 purescale lub Sybase ASE Cluster. Nowy węzeł można dodać do systemu Oracle RAC lub systemu DB2 purescale, aby uzyskać skalowanie poziome.
Ale podejście różni się od baz danych noSQL (takich jak mongodb, CouchDB lub IBM Cloudant), że sharding danych nie jest częścią skalowania poziomego. W bazach danych noSQL dane są przesuwane podczas skalowania poziomego.
Zacznijmy od potrzeby skalowania, które zwiększa zasoby, aby system mógł obsłużyć więcej żądań niż wcześniej.
Kiedy zdajesz sobie sprawę, że twój system działa wolno i nie może obsłużyć obecnej liczby żądań, musisz skalować system.
To zapewnia dwie opcje, albo zwiększasz zasoby na serwerze, z którego korzystasz obecnie, tj. Zwiększasz ilość pamięci RAM, procesora, gpu i innych zasobów. Jest to znane jako skalowanie pionowe.
Skalowanie w pionie jest zazwyczaj kosztowne. Nie powoduje to, że system jest odporny na awarie, tj. Jeśli skalujesz aplikację działającą z pojedynczym serwerem, jeśli serwer ulegnie awarii, system ulegnie awarii. Również liczba wątków pozostaje taka sama w skalowaniu pionowym. Skalowanie w pionie może wymagać, aby system zawiesił się na chwilę podczas procesu. Zwiększanie zasobów na serwerze wymaga restartu i obniżenia wydajności 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 zmniejszenie liczby żądań na sekundę na każdym serwerze. Jeśli chcesz przeskalować system, po prostu dodaj kolejny serwer i gotowe. Nie trzeba będzie restartować systemu. Liczba wątków w każdym systemie zmniejsza się, co prowadzi do wysokiej przepustowości. Aby segregować żądania, tak samo dla każdego serwera aplikacji, należy dodać moduł równoważenia obciążenia, który będzie działać jako odwrotne proxy dla serwerów WWW. 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 takich klastrów.
Nadzieję masz całą koncepcję wprowadzenia do skalowania systemu
http://en.wikipedia.org/wiki/Scalability - termin odnosi się do wszystkich systemów oprogramowania/ –
Pay spaecial uwagi do sekcji _Database_ http : //en.wikipedia.org/wiki/Skalowalność#Database_scalability – user454322
http://stackoverflow.com/questions/5401992/what-does-scale-horizontally-and-scale-vertical-mean –