Partycjonowanie w programie SQL Server - czego używać w przypadku klucza partycji?

10

Nigdy nie pracowałem z partycjonowaniem SQL Server, ale obecnie mam do czynienia z projektowaniem bazy danych, dla której woluminy prawdopodobnie to uzasadniają. System przeznaczony jest na kupony. Kupony będą wydawane okresowo, zwykle co sześć tygodni, chociaż będzie również wydawana ad hoc - np. Na specjalne wydarzenie. Istnieje 15 milionów klientów, a na każde wydarzenie wydawania każdy klient otrzyma 6 różnych rodzajów kuponów, co daje łącznie 90 milionów wystąpień kuponów. Musimy śledzić dane dotyczące wykorzystania instancji kuponu i utrzymywać je przez 6 miesięcy, chociaż zazwyczaj kupon jest ważny tylko przez sześć tygodni. Wszelkie żądania wykorzystania nieprawidłowego kuponu nie dotrą do bazy danych, ponieważ zostaną zatwierdzone przez POS do.

Przez okres sześciu miesięcy będziemy musieli przechowywać do 360 milionów wierszy w tabeli wystąpienia kuponu i do 72 milionów (przy założeniu maks. 20% stopy wykupu) w tabeli wykupu. Mam wrażenie, że te liczby są za duże na jedną partycję?

Moje pytanie brzmi - co użyć jako klucza partycji? Jednym oczywistym kandydatem byłby wydawca, który dałby około 6 partycji. Ale potem myślę, że może nawet to dałoby zbyt duży rozmiar partycji, aby umożliwić optymalną wydajność? Czy byłoby możliwe podzielenie według dwóch kluczy, np. Według zdarzenia wydania + ostatniej cyfry identyfikatora klienta? Logika wyglądałaby następująco:

If issuance event = 1 and last digit of customer id < 5 then
    Store in partition 1
Else if issuance event = 1 and last digit of customer id >4 then
    Store in partition 2
Else if issuance event =2 and last digit of customer id <5 then
    Store in partition 3
Else if issuance event =2 and last digit of customer id >4 then
    Store in partition 4
Etc...

Nie jestem też pewien, jakiej specyfikacji serwera bazy danych będziemy potrzebować. Czy 16GB i 8CPU wystarczą? Db musi być w stanie zwrócić wynik z tabeli instancji kuponu, wpisany na numerycznej wartości kodu kreskowego w mniej niż pół sekundy. Oczekuje się, że oczekiwane żądanie transakcji dotyczące weryfikacji (wyboru) i wykorzystania (wstawienia) osiągnie szczyt około 3500 na minutę.

64-bitowy serwer db SQL Server 2008r2 będzie udostępniany jako VM z bardzo wydajnego hosta z dostępem do wysokiej wydajności i dużej pojemności sieci SAN.

Byłbym bardzo wdzięczny za wszelkie porady od tych, którzy wdrożyli rozwiązanie SQL Server do zarządzania podobnymi woluminami.

pozdrowienia

Obrabować.

Rob Bowman
źródło
2
Twoje tabele są wciąż małe - nie potrzeba POTRZEB dla partycji, mam tabelę z kilkoma miliardami wierszy bez partycji, działa. Jednak partycje są dobre dla FAST DROP.
TomTom
1
Bzdury @TomTom, partycje mogą być przydatne, gdy wiersz liczy ułamek tego. To prawda, że ​​schemat partycji musi być korzystny dla wzorców dostępu, aby zrealizować wzrost wydajności, ale koc „brak potrzeby” przy tym rozmiarze jest po prostu zły.
Mark Storey-Smith
1
Nie, to prawda. POTRZEBA! = Korzyść. POTRZEBUJESZ, gdy masz problemy z wykonywaniem zapytań bez partycji.
TomTom
1
Hej, TomTom. Myślę, że potrzebujesz małego kumpla, który jest trochę silny, nawet jeśli nie jest obraźliwy. Zgadzam się z Mark StoreySmith, koc „no NEED” jest po prostu błędny, jednak twoje twierdzenie, że prawdopodobnie nie jest potrzebne, jest prawidłowe. Wyobrażam sobie, że to kwestia indeksowania. Wiem też, że Mark wie, co masz na myśli mówiąc o potrzebie kontra korzyść. Wytnij nas wszystkich trochę luzu i porzuć kofeinę, k? (I zaufaj mi, wiem, że mam bardzo mało cierpliwości w niektóre dni, zwłaszcza takie jak dzisiaj, kiedy mam leki przeciwbólowe na plecy)
jcolebrand

Odpowiedzi:

14

Pytania dotyczące specyfikacji serwera powinny być kierowane do Serverfault lub DBA.SE.

W przypadku pytania dotyczącego partycjonowania nie sądzę, że musisz koniecznie przeprowadzić partycjonowanie.

Rzędy o długości 360 m to dużo, ale nie jest zbyt nieporęczne.

W żadnym wypadku NIE próbuj partycjonować na podstawie ostatniej cyfry pola. Nie jestem pewien, czy to w ogóle zadziałałoby, ale nie jest to SARGable, który nie byłby możliwy do utrzymania.

Jeśli potrzebujesz wykonać wyszukiwanie tylko w jednym rzędzie na podstawie klucza numerycznego, partycjonowanie prawdopodobnie nie pomoże.

Jeśli zdecydujesz się kontynuować trasę partycji, pamiętaj, aby być skutecznym, wszystkie zapytania muszą zawierać klucze do partycji, aby silnik wiedział, którą partycję sprawdzić. W przeciwnym razie sprawdzi je wszystkie i faktycznie pogorszysz wydajność.

JNK
źródło
Ja też się zgadzam. Czasami potrzebujesz po prostu lepszych indeksów.
jcolebrand
Nie zgadzam się @JNK. Wyszukiwanie w jednym wierszu na podstawie klucza numerycznego, który korzysta z eliminacji partycji, zmniejsza liczbę operacji wejścia / wyjścia. Jeśli wzorce dostępu są takie, że często używane partycje pozostają w puli buforów w porównaniu z partycjami rzadko dostępnymi, zyskujesz dodatkowe korzyści w zakresie wydajności. I nawet nie dotknęliśmy mojej ulubionej funkcji, jaką daje partycjonowanie, częściowa dostępność.
Mark Storey-Smith
Dla przypomnienia, w innych kwestiach zgadzam się z całego serca :)
Mark Storey-Smith
@ MarkStorey-Smith - Będzie to zależeć od jego klucza. Jak obecnie zdefiniowano w OP, partycja nie dodałaby żadnej wartości. Brzmi również tak, jakby nie był w stanie użyć dwuczęściowego klucza z polem daty lub „normalnym” schematem partycji.
JNK
5

Możesz podzielić na wiele kluczy, jeśli używasz utrwalonej kolumny obliczeniowej; jednak, jak powiedzieli inni, partycjonowanie nie działa w każdej sytuacji. Nie jestem pewien, czy rozumiem twój scenariusz na tyle, aby dać ci konkretną radę, ale oto kilka ogólnych wskazówek:

  • Partycjonowanie jest przydatne podczas odczytywania danych, gdy klucz partycjonowania jest częścią instrukcji SQL, która pozwala optymalizatorowi wywołać wykluczanie parowania. Musisz upewnić się, że wybrany klucz jest przydatny w przypadku większości zapytań.

  • Jedną z zalet dobrej strategii partycjonowania jest starzenie się danych; na przykład, jeśli klucz partycji jest oparty na dacie (tj. dniu roku) i chcesz usunąć wszystkie dane, które są starsze niż określona data, bardzo łatwo PRZEŁĄCZYĆ te partycje do pustej tabeli i obciąć.

Stuart Ainsworth
źródło
4

Naprawdę musisz nieco bardziej precyzyjnie określić swoje wymagania. Wspominasz, że będziesz mieć około 360 milionów wierszy w ciągu 6 miesięcy. A może za 2 lata? Czy nadal będziesz rosnąć tylko w tempie, w którym obecnie rośniesz? Czy jest szansa, że ​​doświadczysz wykładniczego wzrostu. Czy chcesz zachować dane w tej tabeli na zawsze; lub chcesz regularnie archiwizować dane.

Partycjonowania można używać do archiwizacji danych. Zobacz scenariusz przesuwanego okna. Zobacz ten oficjalny dokument i ten .

Partycjonowania można także użyć do zarządzania fragmentacją indeksu. Możesz odbudować / zreorganizować określone partycje.

Powinieneś również rozważyć widoki podzielone na partycje w przeciwieństwie do tabel podzielonych na partycje. Widoki podzielone na partycje nie wymagają licencji SQL Server Enterprise. Widoki podzielone na partycje umożliwiają także przeprowadzanie przebudowy indeksu online na określonej „partycji”.

Partycjonowanie można również rozważyć podczas planowania odzyskiwania po awarii. Można go użyć do częściowego odzyskiwania bazy danych. Na przykład: możesz mieć swoje stare partycje na innej grupie plików niż partycje główne / bieżące. A następnie, gdy odzyskujesz, odzyskujesz podstawową grupę plików, następnie grupę plików, w której znajdują się bieżące partycje, a następnie możesz przywrócić grupy plików, w których znajdują się stare partycje. Może to skrócić czas przestoju aplikacji.

Sprawdź ten świetny film od Kimberly Tripp na temat partycjonowania .

Dharmendar Kumar „DK”
źródło
Musimy przechowywać dane tylko przez sześć miesięcy. Co tydzień prowadzilibyśmy prace porządkowe, które usuwałyby wszelkie kupony wydane ponad sześć miesięcy wcześniej.
Rob Bowman,
3
Zasadniczo musiałbyś więc usuwać / usuwać około 15 milionów wierszy co tydzień. Jak szeroki jest stół? Sugeruję podzielenie tabeli według kolumn według dat. W ten sposób cotygodniowe usuwanie byłoby prostą operacją meta. Musisz po prostu zamienić najstarszą partycję z głównej partycjonowanej tabeli na tabelę pomostową. Następnie upuść tabelę pomostową. Nazywa się to scenariuszem przesuwnego systemu Windows. Spójrz na pierwszą białą księgę, którą opublikowałem, och, jak to zrobić.
Dharmendar Kumar „DK”
-2

Jeśli nie robisz partycjonowania z powodu archiwizacji starych danych, robisz to z niewłaściwego powodu i nie powinieneś tego robić.

Ryk
źródło
2
Istnieje wiele powodów, dla których warto korzystać z partycjonowania oprócz archiwizacji; wykluczanie części ma wielką zaletę w przypadku wielu różnych typów zapytań, jeśli są stosowane poprawnie.
Stuart Ainsworth
Zgadzam się ze Stuartem, to trochę zła rada.
jcolebrand