Co to jest dzielenie i dlaczego jest ważne?

Wydaje mi się, że rozumiem, że sharding polega na umieszczeniu podzielonych danych (odłamków) w łatwym w obsłudze agregacie, który ma sens w kontekście. Czy to jest poprawne?

Aktualizacja : Chyba tutaj walczę. Moim zdaniem warstwa aplikacji nie powinna określać, gdzie należy przechowywać dane. W najlepszym wypadku powinien to być jakiś klient niezależny. Obie odpowiedzi odpowiedziały na pytanie, ale dlaczego nie jest to ważne. Jakie konsekwencje ma to poza oczywistymi wzrostami wydajności? Czy te korzyści są wystarczające, aby zrównoważyć naruszenie MVC? Czy dzielenie fragmentów jest szczególnie ważne w aplikacjach na bardzo dużą skalę, czy dotyczy mniejszych?

Sharding to po prostu inna nazwa „poziomego partycjonowania” bazy danych. Możesz poszukać tego terminu, aby był bardziej zrozumiały.

Z Wikipedii :

Podział poziomy to zasada projektowania, w której wiersze tabeli bazy danych są przechowywane osobno, a nie dzielone według kolumn (jak w przypadku normalizacji). Każda partycja stanowi część niezależnego fragmentu, który z kolei może znajdować się na oddzielnym serwerze bazy danych lub fizycznej lokalizacji. Zaletą jest zmniejszenie liczby wierszy w każdej tabeli (zmniejsza to rozmiar indeksu, a tym samym poprawia wydajność wyszukiwania). Jeśli fragmentowanie jest oparte na jakimś rzeczywistym aspekcie danych (np. Klienci europejscy kontra klienci amerykańscy), możliwe jest łatwe i automatyczne ustalenie odpowiedniego członkostwa niezależnego fragmentu i zapytanie tylko odpowiedniego fragmentu.

Kilka dodatkowych informacji o dzieleniu na fragmenty:

Po pierwsze, każdy serwer bazy danych jest identyczny i ma tę samą strukturę tabeli. Po drugie, rekordy danych są logicznie podzielone na podzieloną bazę danych. W przeciwieństwie do partycjonowanej bazy danych, każdy pełny rekord danych istnieje tylko w jednym niezależnym fragmencie (chyba że istnieje dublowanie w celu tworzenia kopii zapasowych / redundancji), a wszystkie operacje CRUD wykonywane są tylko w tej bazie danych. Użyta terminologia może Ci się nie podobać, ale reprezentuje to inny sposób organizowania logicznej bazy danych na mniejsze części.

Aktualizacja: Nie zepsujesz MVC. Praca nad określeniem poprawnego fragmentu, w którym mają być przechowywane dane, zostałaby wykonana w sposób transparentny przez warstwę dostępu do danych. Tam musisz określić poprawny fragment w oparciu o kryteria zastosowane do usunięcia fragmentu bazy danych. (Ponieważ musisz ręcznie podzielić bazę danych na różne fragmenty w oparciu o niektóre konkretne aspekty aplikacji). Następnie musisz zachować ostrożność podczas ładowania i przechowywania danych z / do bazy danych, aby użyć poprawnego fragmentu.

Być może ten przykład z kodem Java sprawia, że ​​jest nieco jaśniejszy (dotyczy projektu Hibernacja odłamków ), jak to będzie działać w scenariuszu z prawdziwego świata.

Aby rozwiązać problem „ why sharding”: Dotyczy to głównie aplikacji na bardzo dużą skalę, z dużą ilością danych. Po pierwsze, pomaga zminimalizować czas odpowiedzi na zapytania do bazy danych. Po drugie, możesz użyć tańszych, „niższych” maszyn do hostowania danych, zamiast jednego dużego serwera, co może już nie wystarczyć.

Jeśli masz zapytania do DBMS, dla których lokalizacja jest dość ograniczona (powiedzmy, że użytkownik odpala, wybiera tylko z „gdzie nazwa użytkownika = $ moja_nazwa_użytkownika”), sensowne jest umieszczenie wszystkich nazw użytkowników zaczynających się od AM na jednym serwerze, a wszystkie z NZ na inne. Przez to zbliżasz się do skalowania liniowego dla niektórych zapytań.

Krótko mówiąc : Sharding jest zasadniczo procesem dystrybucji tabel na różne serwery w celu zrównoważenia obciążenia na obu serwerach w jednakowy sposób.

Oczywiście w rzeczywistości jest to o wiele bardziej skomplikowane. :)

Sharding to partycjonowanie bazy danych w poziomie (w wierszu ), w przeciwieństwie do partycjonowania w pionie (w kolumnie ), czyli normalizacja . Dzieli bardzo duże bazy danych na mniejsze, szybsze i łatwiejsze do zarządzania części zwane odłamkami danych. Jest to mechanizm pozwalający osiągnąć systemy rozproszone.

Dlaczego potrzebujemy systemów rozproszonych?

• Zwiększona dostępność.
• Łatwiejsza rozbudowa.
• Ekonomia: Tworzenie sieci mniejszych komputerów kosztuje mniej niż jeden duży komputer.

Możesz przeczytać więcej tutaj: Zalety rozproszonej bazy danych

W jaki sposób sharding pomaga osiągnąć rozproszony system?

Możesz podzielić indeks wyszukiwania na N partycji i załadować każdy indeks na osobnym serwerze. Jeśli prześlesz zapytanie do jednego serwera, otrzymasz 1/5 wyników. Aby uzyskać pełny zestaw wyników, typowy system wyszukiwania rozproszonego korzysta z agregatora , który gromadzi wyniki z każdego serwera i łączy je. Agregator dystrybuuje również zapytania na każdy serwer. Ten program agregujący nazywa się MapReduce w terminologii dużych zbiorów danych. Innymi słowy, Distributed Systems = Sharding + MapReduce (chociaż są też inne rzeczy).

Wizualna reprezentacja poniżej.

Czy dzielenie fragmentów jest szczególnie ważne w aplikacjach na bardzo dużą skalę, czy dotyczy mniejszych?

Sharding jest problemem tylko wtedy, gdy potrzeby są skalowane w stosunku do tego, co może obsłużyć pojedynczy serwer bazy danych. Jest to doskonałe narzędzie, jeśli masz dane możliwe do dzielenia i masz niewiarygodnie wysokie wymagania dotyczące skalowalności i wydajności. Domyślam się, że przez całe 12 lat byłem specjalistą od oprogramowania, spotkałem się z jedną sytuacją, która mogłaby skorzystać z dzielenia. Jest to zaawansowana technika o bardzo ograniczonym zastosowaniu.

Poza tym przyszłość prawdopodobnie będzie czymś zabawnym i ekscytującym, jak „chmura” ogromnego obiektu, która usuwa wszystkie potencjalne ograniczenia wydajności, prawda? :)

Sharding został pierwotnie wymyślony przez inżynierów Google i widać, że jest używany bardzo często podczas pisania aplikacji w Google App Engine. Ponieważ istnieją twarde ograniczenia dotyczące ilości zasobów, z których mogą korzystać zapytania, a ponieważ same zapytania mają ścisłe ograniczenia, dzielenie jest nie tylko wspierane, ale prawie narzucane przez architekturę.

Innym miejscem, w którym można fragmentować dane, jest ograniczenie rywalizacji o jednostki danych. Podczas budowania skalowalnych systemów szczególnie ważne jest uważanie na często zapisywane dane, ponieważ zawsze stanowią one wąskie gardło. Dobrym rozwiązaniem jest odłamek tego konkretnego bytu i zapisanie go na wielu kopiach, a następnie odczytanie sumy. Przykład tego „shaged counter wrt GAE: http://code.google.com/appengine/articles/sharding_counters.html

Sharding to coś więcej niż tylko partycjonowanie poziome. Według artykułu wikipedia ,

Partycjonowanie poziome dzieli jedną lub więcej tabel według wierszy, zwykle w ramach pojedynczej instancji schematu i serwera bazy danych. Może to być korzystne, ponieważ zmniejsza rozmiar indeksu (a tym samym wysiłek związany z wyszukiwaniem), pod warunkiem, że istnieje jakiś oczywisty, solidny, domyślny sposób identyfikacji, w której partycji zostanie znaleziony określony wiersz, bez konieczności przeszukiwania indeksu, np. Klasyka przykład tabel „CustomerEast” i „CustomerWest”, gdzie ich kod pocztowy już wskazuje, gdzie zostaną znalezione.

Sharding wykracza poza to: dzieli problematyczne tabele w ten sam sposób, ale robi to w potencjalnie wielu instancjach schematu. Oczywistą zaletą byłoby to, że obciążenie wyszukiwania dla dużej partycjonowanej tabeli można teraz podzielić na wiele serwerów (logicznych lub fizycznych), a nie tylko na wiele indeksów na tym samym serwerze logicznym.

Również,

Dzielenie odłamków na wiele izolowanych instancji wymaga czegoś więcej niż prostego podziału na partycje. Oczekiwany wzrost wydajności zostałby utracony, gdyby zapytanie do bazy danych wymagało odpytania obu instancji w celu pobrania prostej tabeli wymiarów. Poza partycjonowaniem sharding dzieli zatem duże serwery na partycje na serwery, a mniejsze tabele są replikowane jako kompletne jednostki

Moim zdaniem warstwa aplikacji nie powinna określać, gdzie należy przechowywać dane

To dobra zasada, ale jak większość rzeczy nie zawsze jest poprawna.

Kiedy tworzysz swoją architekturę, zaczynasz od obowiązków i współpracy. Po określeniu architektury funkcjonalnej musisz zrównoważyć siły niefunkcjonalne.

Jeśli jedną z tych niefunkcjonalnych sił jest ogromna skalowalność, musisz dostosować architekturę, aby uwzględnić tę siłę, nawet jeśli oznacza to, że abstrakcja przechowywania danych wycieka teraz do warstwy aplikacji.