Mam duży stół (kilka 100 milionów wierszy), który chciałbym efektywnie podzielić. Moje pytanie brzmi, czy istnieje kompromis między rozmiarem partycji a liczbą partycji. O ile rozumiem, większość zapytań w kolumnie użytej na partycji będzie szybsza, ponieważ zapytanie (w przypadku większości zapytań) będzie musiało przeszukać tylko partycję dotyczącą zapytania. W związku z tym sensowne byłoby, aby w celu zmaksymalizowania wydajności podzielić dużą tabelę na maksymalną liczbę partycji, dzięki czemu każda partycja powinna być jak najmniejsza. W przypadku MySQL oznacza to 1024 partycje. Ale czy istnieje duża wada wydajności związana z posiadaniem dużej liczby partycji? Czy tak, jak znaleźć optymalną liczbę partycji?

Uwaga: Istnieje już nieco podobne pytanie na temat przepływu stosu , ale tylko jedna odpowiedź, która (z mojej perspektywy) nie ma znaku. Zadam więc pytanie na swój sposób ... mam nadzieję, że jest bardziej jasne

Porównajmy je

ROZMIAR PARTYCJI

Jeśli masz następujące elementy:

• 100 milionów wierszy w tabeli
• Indeksowanie BTREE
• Każda strona w BTREE zawiera 1024 klucze

Jak wyglądałyby dane?

Ponieważ LOG (100000000) / LOG (2) = 26,575424759099, indeks BTREE z 1024 kluczami na stronie treenode miałby wysokość drzewa tylko 3 (CEILING (LOG (100000000) / LOG (1024))). Mając tylko trzy strony węzłów, binarne wyszukiwanie potrzebnego klucza w każdym dostępnym treenode spowoduje przycinanie i izolację około 30 kluczy.

LICZBA PARTYCJI

Jeśli masz następujące elementy:

• 100 milionów wierszy w tabeli
• Indeksowanie BTREE
• Każda strona w BTREE zawiera 1024 klucze
• Tworzysz 1024 parytetów

Liczby byłyby nieco inne.

Każda partycja powinna mieć około 97656 wierszy. Jakie stałyby się teraz wskaźniki?

Ponieważ LOG (97656) / LOG (2) = 16.575421065795, indeks BTREE z 1024 kluczami na stronie treenode miałby wysokość drzewa tylko 2 (CEILING (LOG (97656) / LOG (1024))). Przy tylko dwóch węzłach stron, binarne wyszukiwanie potrzebnego klucza w każdym dostępnym treenode spowoduje przycinanie i izolację około 20 kluczy.

WNIOSEK

Rozłożenie kluczy usuwa tylko jeden poziom drzewa, ale zasadniczo tworzy 1024 indeksy. Zapytania nie poznają różnicy. Czas wyszukiwania prawdopodobnie byłby w najlepszym razie nominalny na korzyść partycji. Upewnij się jednak, że wszystkie dane są aktywne. Otheriwse, możesz uderzać tylko w kilka partycji, podczas gdy inne partycje z rzadko dostępnymi danymi po prostu zajmują miejsce i nigdy nie są dostępne na tyle często, aby uzasadnić partycjonowanie . Możesz mieć różne wskaźniki wydajności, które mogą Cię martwić, które są bardziej rażące (takie jak wewnętrzna defragmentacja w XFS , ext3 vs. ext4 itp.) Musisz także martwić się o używany silnik pamięci, ponieważ:

• Indeksowanie InnoDB byłoby nieco bardziej nieporządne w porównaniu do MyISAM z powodu konieczności zarządzania indeksem klastrowym
• InnoDB podwójnie zapisuje dane w ibdata1, a także w bieżącym pliku dziennika (ib_logfile0 lub ib_logfile1)