it-swarm.dev

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 zindeksowana tabela, myślę o ograniczeniu rekordów do 20 milionów w ten sposób, w ten sposób 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)?

Używam 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.

28
Rick James

Oto szalone ranting i szaleństwo ...

Jeśli pozostawisz wszystkie dane w jednej tabeli (bez partycjonowania), będziesz miał 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 przeprowadził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 faktycznie 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 kupi, 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 tylko 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. Teraz to powinno być główną kwestią: zlokalizuj wszystkie identyfikatory, do których najczęściej uzyskiwany jest dostęp i podziel na partycje według tego. Wszystkie rzadziej używane identyfikatory powinny znajdować się w jednej dużej tabeli archiwum, która jest nadal dostępna dla 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.

32
RolandoMySQLDBA

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 obstawić niektóre z poniższych korzyści:

  • Łatwość czyszczenia starych danych Jeśli musisz wyczyścić rekordy mające więcej niż (powiedzmy) 6 miesięcy, możesz podzielić tabelę na datę, 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 rozdzielenia ruchu dyskowego na wiele woluminów dyskowych w celu zwiększenia prędkości. W przypadku nowoczesnego kontrolera RAID nie będzie to prawdopodobnie problemem dla OP.

  • Szybsze skanowanie tabeli i zakres 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 zwracającego 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ż ....

1
Bill