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)
