Jaki jest dobry rozmiar (liczba wierszy), aby podzielić tabelę, aby naprawdę skorzystać?

Question

I.E. jeśli mamy stolik z 4 milionami rzędów.

Który ma pole STATUS, które może przyjąć następującą wartość: TO_WORK, BLOCKED lub WORKED_CORRECTLY.

Czy podzieliłbyś się na pole, które zmieni się tylko raz (najczęściej z to_work do working_correctly)? Ile partycji tworzysz?

Answer 1

Liczba wierszy w tabeli nie jest zwykle doskonałym wskaźnikiem do określenia, czy i jak należy podzielić tabelę.

Jaki problem próbujesz rozwiązać? Czy próbujesz poprawić wydajność zapytań? Wydajność ładunków danych? Wydajność czyszczenia danych?

Zakładając, że próbujesz poprawić wydajność zapytań? Czy wszystkie twoje zapytania mają predykaty na kolumnie STATUS? Czy oni wykonują pojedynczy wiersz wierszy? A może chcesz, aby twoje zapytania skanowały całą partycję?

Answer 2

Bezwzględna liczba wierszy na partycji nie jest najbardziej użyteczną miarą. To, czego naprawdę chcesz, to kolumna, która jest stabilna podczas wzrostu tabeli i która zapewnia potencjalne korzyści z partycjonowania. Są to: dostępność, zarządzanie tabelami i wydajność.

Na przykład Twoja przykładowa kolumna ma trzy wartości. Oznacza to, że możesz mieć trzy partycje, co oznacza, że ​​możesz mieć trzy obszary tabel. Jeśli więc obszar tabel zostanie uszkodzony, stracisz jedną trzecią danych. Czy partycjonowanie sprawiło, że stolik jest bardziej dostępny? Nie całkiem.

Dodanie lub upuszczenie partycji ułatwia zarządzanie dużymi wolumenami danych. Ale czy kiedykolwiek zrzucisz wszystkie wiersze ze statusem WORKED_CORRECTLY? Wysoce nieprawdopodobne. Czy partycjonowanie sprawiło, że stolik jest łatwiejszy w zarządzaniu? Nie całkiem.

Korzyści z partycjonowania wynikają z przycinania zapytań, dzięki czemu optymalizator może natychmiast od razu odliczyć część tabeli. Teraz każda partycja ma 1,3 miliona wierszy. Więc nawet jeśli zapytasz o numer STATUS='WORKED_CORRECTLY', wciąż masz ogromną liczbę rekordów do wybrania. Są szanse, że każde zapytanie, które nie dotyczy STATUS, będzie działało gorzej niż w przypadku tabeli niepodzielonej na partycje. Czy partycjonowanie sprawiło, że stolik jest bardziej wydajny? Prawdopodobnie nie.

Do tej pory zakładałem, że twoje partycje są równomiernie rozmieszczone. Ale ostatnie pytanie wskazuje, że tak nie jest. Większość wierszy - jeśli nie wszystkie - zostanie zakończona w WORKED_CORRECTLY. Tak więc partycja stanie się ogromna w porównaniu do innych, a szanse korzyści z partycjonowania stają się jeszcze bardziej odległe.

Wreszcie proponowany schemat nie jest elastyczny. W bieżącym woluminie każda partycja miałaby 1,3 miliona wierszy. Gdy Twój stół powiększy się do czterdziestu milionów wierszy, każda partycja pomieści 13,3 miliona wierszy. To jest złe.

Co zatem jest dobrym kandydatem do klucza partycji? Jeden, który produkuje wiele partycji, taki, w którym partycje są mniej więcej równe, taki, w którym wartość klucza jest mało prawdopodobna do zmiany i taka, w której wartość ma pewne znaczenie w cyklu życia obiektu, a na koniec jest użyteczny w większości zapytań uruchamianych względem tabeli.

Dlatego coś takiego jak DATE_CREATED jest tak popularnym wyborem do partycjonowania tabel faktów w hurtowniach danych.Generuje rozsądną liczbę partycji w zakresie różnych ziarnistości (typowymi opcjami są dzień, miesiąc lub rok). Otrzymujemy mniej więcej taką samą liczbę rekordów utworzonych w danym przedziale czasowym. Ładowanie danych i archiwizacja danych są zwykle wykonywane na podstawie wieku (tj. Daty utworzenia). Zapytania BI prawie zawsze zawierają wymiar TIME.