Sharding MySQL a klaster MySQL

Biorąc pod uwagę tylko wydajność , czy klaster MySQL może pokonać niestandardowe rozwiązanie MySQL do dzielenia danych? sharding = partycjonowanie poziome

Kiedy mówię o dzieleniu, rozważam dzielenie na fragmenty w warstwie aplikacji, na przykład równomierne rozprowadzanie rekordów między niezależnymi instancjami MySQL. W przypadku dwóch serwerów może to być (klawisz mod 2).

mysql ndbcluster

— gsb
źródło

Ujawnienie: Jestem pracownikiem MySQL, pracuję nad klastrem MySQL.

Powiedziałbym, że klaster MySQL może osiągnąć wyższą przepustowość / hosta niż podzielony MySQL + InnoDB pod warunkiem, że:

Zapytania są proste
Wszystkie dane mieszczą się w pamięci

Pod względem opóźnień klaster MySQL powinien mieć bardziej stabilne opóźnienie niż podzielony MySQL. Rzeczywiste opóźnienie dla danych czysto w pamięci może być podobne.

Ponieważ zapytania stają się bardziej złożone, a dane są przechowywane na dysku, porównanie wydajności staje się bardziej mylące. Aby uzyskać bardziej szczegółową odpowiedź, musisz opisać więcej na temat swojej aplikacji i wykonywanych zapytań, a także liczby hostów i ilości danych. Klaster MySQL zyskał ostatnio na równoległym wykonywaniu zapytań zlokalizowanych (AQL), co oznacza, że może konkurować z samodzielnym MySQLD, mimo że dane są rozproszone na wielu hostach.

Klaster MySQL jest obecnie ograniczony do „dzielenia” ponad 48 hostów. Shated MySQL w teorii nie ma granic. Jednak dla danej docelowej przepustowości może być potrzebnych mniej hostów klastra MySQL niż podzielonych hostów MySQL.

Bardziej interesujące różnice dotyczą spojrzenia na obszary inne niż wydajność:

Klaster MySQL obsługuje dowolne zapytania we wszystkich odłamkach
Klaster MySQL obsługuje dowolne transakcje we wszystkich odłamkach
Klaster MySQL obsługuje synchroniczną replikację odłamków z automatycznym przełączaniem awaryjnym i odzyskiwaniem
Klaster MySQL obsługuje węzeł dodawania online (rozszerzenie klastra)
Shaged MySQL jest bardziej „roll your own”

Wbudowane dzielenie fragmentów daje maksymalny potencjał skalowania, ale zwiększa złożoność i ogranicza elastyczność w zakresie zapytań i operacji między niezależnymi fragmentami. Jeśli fragmentowanie jest przedwczesne, może to być przyczyną niektórych problemów. Klaster MySQL pozwala czerpać niektóre korzyści z fragmentowania bez konieczności ograniczania aplikacji do pojedynczego fragmentu.

W odniesieniu do poprzedniej odpowiedzi, kilka wyjaśnień:

„Chociaż klaster MySQL stanowi skargę ACID, nie zapewnia odpowiedniego silnika pamięci dla danych ze złożonymi kluczami”.

Klaster MySQL obsługuje złożone klucze podstawowe i pomocnicze. Nie jestem pewien, co nie jest w tym „odpowiednie”. Być może poprzedni plakat może to wyjaśnić?

„Aby mieć dane o tej samej kluczowej charakterystyce przechowywane w określonym zestawie węzłów danych, możesz wykonać następujące czynności:

Przełącz wszystkie węzły danych w tryb offline, pozostawiając tylko te węzły danych, w których chcesz przechowywać dane o tych samych kluczowych cechach.

Załaduj dane do klastra MySQL, który wypełnia tylko wybrane węzły danych

Przełącz wszystkie węzły danych z powrotem do trybu online ”

To jest niepoprawne. Dystrybucja danych jest niezależna od tego, które węzły znajdują się w dowolnym momencie w trybie online. Klaster MySQL obsługuje różne schematy dystrybucji danych w celu wsparcia opisanych przez Ciebie optymalizacji. Opisuję dystrybucję danych w klastrze MySQL w blogu tutaj: Dystrybucja danych w klastrze MySQL

— Frazer Clement
źródło

Hej, Frazier. Przeczytałem podany przez ciebie link. Tylko dla wyjaśnienia, mój komentarz „klucza złożonego” został oparty na nieunikalnych indeksach. Firma mojego pracodawcy wypróbowała klaster MySQL około pierwszego kwartału 2007 roku i nie podobała mu się z powodu niskiej wydajności. IMHO to był zły wybór klienta dla kluczy (małe liczności) i jego zapytań. Klaster MySQL musi być bardziej dojrzały od tego czasu w oparciu o Twój link. Jeśli chodzi o moje drugie stwierdzenie, to jest liczba użytkowników MongoDB wypełniających określone odłamki. Niektórzy klienci mojego pracodawcy zrobili to dzięki niestandardowym ustawieniom MySQL.

— RolandoMySQLDBA,

W twoim linku wspomniano o „uporządkowanym skanowaniu indeksu”, którego nie można przyciąć, ponieważ nie można zagwarantować, że pasujące wiersze zostaną zapisane w jednym fragmencie tabeli. Właśnie dlatego sugerowałem izolowanie danych do określonych fragmentów (węzłów danych), aby zminimalizować miejsca, w których dane się rozprzestrzeniają. Ponieważ twoja odpowiedź uwydatnia pozytywną stronę klastra MySQL, lepiej pasuje do pierwotnie opublikowanego pytania. Moja odpowiedź przemawia za ostrożnością, pesymizmem i naiwnością na dzisiejszą moc klastra MySQL.

— RolandoMySQLDBA,

Zamiast mojego rantingu i wściekłości, +1 za twoją odpowiedź !!!

— RolandoMySQLDBA,

Cześć Rolando, Dziękujemy za wyjaśnienie twoich oświadczeń. Prawdą jest, że uporządkowane skanowanie indeksów bez przycinania jest „drogie” w klastrze, ponieważ w grę wchodzą wszystkie węzły danych. Wygląda na to, że te skany przy niskich wskaźnikach liczności byłyby drogie w każdym systemie, ale w Cluster stały się wyraźnie drogie. Twoja ostrożność i pesymizm bez wątpienia uratowały cię więcej niż raz :) Dzięki za +1

— Frazer Clement