Jak pomaga partycjonowanie tabeli?

Mam trudności z uchwyceniem koncepcji zalet i wad partycjonowania tabel. Zaraz rozpocznę pracę nad projektem, który miałby 8 tabel, a jedna z nich będzie główną tabelą danych, która pomieści 180-260 milionów rekordów. Ponieważ będzie to właściwie indeksowana tabela, myślę o ograniczeniu rekordów tabeli do 20 milionów w ten sposób, że musiałbym stworzyć 9-13 tabel.

Ale nie jestem pewien, jak to poprawi wydajność, ponieważ będą siedzieć na tej samej maszynie (32 GB pamięci RAM)?

Korzystam z MySQL, a tabele byłyby MyISAM, a duża tabela miałaby indeks na polu id i nie ma żadnych dalszych złożoności takich jak wyszukiwanie pełnotekstowe itp

Rzuć też światło na partycjonowanie tabeli vs partycjonowanie bazy danych.

Oto szalone ranting i szaleństwo ...

Jeśli pozostawisz wszystkie dane w jednej tabeli (bez partycjonowania), będziesz mieć czas wyszukiwania O (log n) za pomocą klucza. Weźmy najgorszy wskaźnik na świecie, drzewo binarne. Każdy węzeł drzewa ma dokładnie jeden klucz. Idealnie zrównoważone drzewo binarne z 268 435 455 (2 ^ 28 - 1) węzłami ma wysokość 28. Jeśli podzielisz to drzewo binarne na 16 osobnych drzew, otrzymasz 16 drzew binarnych z 16 777 215 (2 ^ 24 - 1) węzły drzew o wysokości 24. Ścieżka wyszukiwania jest zmniejszona o 4 węzły, co oznacza zmniejszenie wysokości o 14,2857%. Jeśli czas wyszukiwania jest w mikrosekundach, skrócenie czasu wyszukiwania o 14,2857% jest zerowe lub nieistotne.

W prawdziwym świecie indeks BTREE miałby treenody z wieloma kluczami. Każde wyszukiwanie BTREE przeprowadzałoby wyszukiwanie binarne na stronie z możliwym przyzwoitym przejściem na inną stronę. Na przykład, jeśli każda strona BTREE zawiera 1024 klucze, wysokość drzewa wynosząca 3 lub 4 byłaby normą, a rzeczywiście krótka wysokość drzewa.

Zauważ, że partycjonowanie tabeli nie zmniejsza wysokości BTREE, która jest już mała. Biorąc pod uwagę podział na 260 milionów wierszy, istnieje nawet duże prawdopodobieństwo posiadania wielu BTREE o tej samej wysokości. Wyszukiwanie klucza może za każdym razem przechodzić przez wszystkie główne strony BTREE. Tylko jeden spełni ścieżkę wymaganego zakresu wyszukiwania.

Teraz rozwiń to. Wszystkie partycje istnieją na tym samym komputerze. Jeśli nie masz osobnych dysków dla każdej partycji, będziesz mieć dyskowe operacje we / wy i obroty wrzeciona jako automatyczne wąskie gardło poza wydajnością wyszukiwania partycji.

W takim przypadku parowanie według bazy danych niczego nie kupuje, jeśli id ​​jest jedynym wykorzystywanym kluczem wyszukiwania.

Partycjonowanie danych powinno służyć do grupowania danych logicznie i spójnie w tej samej klasie. Wydajność przeszukiwania każdej partycji nie musi być głównym czynnikiem, o ile dane są poprawnie pogrupowane. Po osiągnięciu partycjonowania logicznego skoncentruj się na czasie wyszukiwania. Jeśli oddzielasz dane tylko według identyfikatora, możliwe jest, że dostęp do wielu wierszy danych nie będzie możliwy w celu odczytu lub zapisu. To powinno być najważniejsze: zlokalizuj wszystkie identyfikatory, do których najczęściej uzyskiwany jest dostęp, i podziel według partycji . Wszystkie rzadziej używane identyfikatory powinny znajdować się w jednej dużej tabeli archiwum, która jest nadal dostępna podczas wyszukiwania indeksu dla zapytania „raz w błękitne księżyc”.

Ogólny wpływ powinien mieć co najmniej dwie partycje: jedna dla często używanych identyfikatorów, a druga podział na pozostałe identyfikatory. Jeśli często używane identyfikatory są dość duże, możesz opcjonalnie podzielić je na partycje.

200 milionów wierszy jest z pewnością w zakresie, w którym można skorzystać z partycjonowania tabeli. W zależności od aplikacji możesz postawić niektóre z poniższych korzyści:

• Łatwość czyszczenia starych danych Jeśli chcesz wyczyścić rekordy mające więcej niż (powiedzmy) 6 miesięcy, możesz podzielić tabelę na partycje według daty, a następnie zamienić starsze partycje. Jest to znacznie szybsze niż usuwanie danych z tabeli i często można to zrobić w systemie na żywo. W przypadku PO może to być pomocne do konserwacji systemu.

• Wiele woluminów dyskowych Partycjonowanie pozwala na podzielenie danych w celu szybkiego podziału ruchu dyskowego na wiele woluminów dyskowych. W przypadku nowoczesnego kontrolera RAID nie będzie to prawdopodobnie problemem dla OP.

• Szybsze skanowanie tabel i zakresów Naprawdę, system operacyjny nie powinien robić takich rzeczy, ale hurtownia danych lub podobny system wykona tego rodzaju zapytania ilościowo. Skany w tabelach wykorzystują głównie sekwencyjny ruch dyskowy, więc są zazwyczaj najskuteczniejszym sposobem przetwarzania zapytania, które zwraca więcej niż kilka procent wierszy w tabeli.
  
  Partycjonowanie przez wspólny filtr (zazwyczaj oparty na czasie lub okresie) pozwala wyeliminować duże fragmenty tabeli z takich zapytań, jeśli predykat można rozwiązać na podstawie klucza partycjonowania. Umożliwia także podział tabeli na wiele woluminów, co może zapewnić znaczny wzrost wydajności w przypadku dużych zestawów danych. Zwykle nie stanowi to problemu dla systemów operacyjnych.

Dla celów PO partycjonowanie raczej nie przyniesie większej wydajności w przypadku zapytań operacyjnych, ale może być przydatne do zarządzania systemem. Jeśli istnieje jakikolwiek istotny wymóg zgłaszania agregatów w dużych ilościach danych, odpowiedni schemat partycjonowania może w tym pomóc.

Partycjonowanie umożliwia równoczesne ponowne rejestrowanie według partycji, jeśli wszystkie indeksy są podzielone na partycje. Jeśli nie, partycje są nadal znacznie mniejsze i zajmują mniej miejsca do ponownego organizowania. I wewnętrznie każdy „dobry” DBMS może robić rzeczy równolegle z tabelami partycjonowanymi. To prawdopodobnie NIE obejmuje MySQL lub MyISAM, chociaż ....