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ć.
źródło
Odpowiedzi:
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ść.
źródło
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ąć.
źródło
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 .
źródło
Jeśli nie robisz partycjonowania z powodu archiwizacji starych danych, robisz to z niewłaściwego powodu i nie powinieneś tego robić.
źródło