Tabela partycjonowana

Tabela partycjonowana dzieli dane na fragmenty według wybranego klucza, ułatwiając zarządzanie dużymi zbiorami.

Podział danych według klucza partycjonowania

Tabela partycjonowana to tabela logiczna, której dane są przechowywane w kilku odrębnych partycjach. Podział odbywa się na podstawie wartości wybranej kolumny albo wyrażenia, nazywanego kluczem partycjonowania. Dla użytkownika zapytanie nadal może wyglądać jak odwołanie do jednej tabeli, natomiast silnik bazy danych może wewnętrznie kierować rekordy do odpowiednich fragmentów. Partycje nie są osobnymi tabelami z punktu widzenia modelu danych, lecz częściami jednej struktury.

Najczęściej partycjonuje się duże zbiory według zakresów wartości, na przykład przedziałów dat, identyfikatorów lub numerów kolejnych. Stosuje się także partycjonowanie listowe, w którym poszczególne partycje odpowiadają określonym wartościom, oraz partycjonowanie haszujące, gdzie rekordy są rozdzielane za pomocą funkcji skrótu. Dostępne metody, składnia definicji i ograniczenia zależą od konkretnego systemu zarządzania bazą danych, dlatego nie należy przenosić ustawień z jednego silnika do innego bez sprawdzenia dokumentacji.

Zakres skanowania podczas wykonywania zapytań

Jedną z istotnych korzyści partycjonowania jest możliwość pominięcia partycji, które nie mogą zawierać wyników danego zapytania. Mechanizm ten jest określany jako eliminacja partycji albo pruning. Jeżeli tabela zawiera dane podzielone według daty, a warunek zapytania jednoznacznie ogranicza zakres dat, optymalizator może odczytać tylko wybrane fragmenty zamiast analizować całą tabelę. Skuteczność takiego działania zależy od planu zapytania, sposobu zapisania warunku, typu danych oraz statystyk dostępnych dla silnika.

Partycyjna organizacja danych nie zastępuje indeksów i nie gwarantuje automatycznego przyspieszenia każdego polecenia. Zapytanie bez warunku odnoszącego się do klucza partycjonowania może nadal wymagać odczytu wielu lub wszystkich partycji. Podobnie funkcja zastosowana na kolumnie albo niejawna konwersja typu może utrudnić optymalizatorowi ustalenie, które fragmenty są potrzebne. Każdą zmianę należy więc oceniać na podstawie rzeczywistego planu wykonania, czasu odczytu i liczby przetwarzanych wierszy, a nie wyłącznie na podstawie samego faktu podziału tabeli.

Indeksy, integralność i operacje na partycjach

Indeksy związane z tabelą partycjonowaną mogą być organizowane razem z partycjami albo niezależnie od ich podziału, zależnie od możliwości wybranego silnika. W pierwszym przypadku indeks jest dzielony zgodnie z organizacją tabeli, co może ułatwiać zarządzanie poszczególnymi fragmentami. W drugim przypadku indeks może obejmować całą tabelę, ale jego przebudowa lub utrzymanie może mieć inny koszt. Ważne jest również sprawdzenie, czy klucz partycjonowania musi występować w określonych indeksach unikatowych lub ograniczeniach integralności.

W systemach obsługujących partycjonowanie można wykonywać operacje dotyczące pojedynczych fragmentów, takie jak dołączanie nowego zakresu, odłączanie starszego zakresu, przenoszenie danych albo usuwanie niepotrzebnej partycji. Takie działania wymagają kontroli granic zakresów, typów danych i zależności między tabelą a indeksami. Błędnie zdefiniowane granice mogą spowodować odrzucenie rekordu, jego przypisanie do nieoczekiwanej partycji albo powstanie nakładających się zakresów. Przed zmianą struktury należy wykonać kopię zapasową zgodnie z procedurą właściwą dla używanego systemu bazodanowego i sprawdzić wpływ operacji na blokady oraz równoległe transakcje.

Ocena partycjonowania w praktyce serwisowej

Problemy związane z tabelą partycjonowaną mogą objawiać się długim wykonywaniem zapytań, błędami podczas zapisu, nieprawidłowym planem wykonania albo nadmiernym obciążeniem nośnika danych. Sama nazwa tabeli nie wystarcza do postawienia diagnozy. Potrzebne są informacje o używanym silniku bazy danych, definicji partycji, kluczu podziału, indeksach, statystykach, rozmiarze danych oraz konkretnych zapytaniach. Należy również rozróżnić problem struktury bazy od awarii sprzętu, systemu plików, pamięci masowej lub systemu operacyjnego.

Przy analizie komputera można sprawdzić, czy opóźnienia wynikają z przeciążenia procesora, braku pamięci operacyjnej, wysokiego czasu oczekiwania na operacje dyskowe albo błędów aplikacji korzystającej z bazy. Zmiana definicji tabeli bez znajomości używanego produktu może pogorszyć działanie systemu lub naruszyć jego spójność. W przypadku danych produkcyjnych konieczne jest zachowanie ostrożności, wykonanie testów na kopii i potwierdzenie, że planowana operacja jest zgodna z dokumentacją konkretnego silnika.