Czy denormalizacja wierszy do kolumn zwiększa wydajność w SQL Server?

Question

Mam dane, które są macierzą wartości całkowitych, które wskazują pasmową krzywą rozkładu. Optymalizuję wydajność SELECT przez WSTAWIĆ wydajność. Istnieje maksymalnie 100 pasm. Będę głównie sprawdzać te dane przez sumowanie lub uśrednianie pasm w określonym przedziale czasu.

Moje pytanie brzmi: czy mogę osiągnąć lepszą wydajność poprzez spłaszczenie tych danych w tabeli z 1 kolumną dla każdego pasma lub za pomocą pojedynczej kolumny reprezentującej wartość pasma?

dane spłaszczone

UserId ActivityId DateValue Band1 Band2 Band3....Band100 
10001 10002  1/1/2013 1  5  100  200 

LUB Znormalizowany

UserId ActivityId DateValue Band BandValue 
10001 10002  1/1/2013 1 1 
10001 10002  1/1/2013 2 5 
10001 10002  1/1/2013 3 100 

zapytania Próbka

SELECT AVG(Band1), AVG(Band2), AVG(Band3)...AVG(Band100) 
FROM ActivityBands 
GROUP BY UserId 
WHERE DateValue > '1/1/2012' AND DateValue < '1/1/2013' 

Answer 1

Zapisz dane w znormalizowanym formacie.

Jeśli nie uzyskujesz akceptowalnej wydajności z tego schematu, zamiast denormalizować, najpierw zastanów się jakie indeksy posiadasz na stole. Prawdopodobnie brakuje indeksu, który spowodowałby, że ta funkcja będzie podobna do tabeli zdenormalizowanej. Następnie spróbuj wpisać zapytanie, aby pobrać dane z znormalizowanej tabeli, aby zestaw wyników wyglądał jak tabela zdenormalizowana i użyj tego zapytania, aby utworzyć indexed view. Zapewni to wybraną wydajność identyczną jak w przypadku zdenormalizowanej tabeli, ale zachowa korzystne dla organizacji danych korzyści prawidłowej normalizacji.

Answer 2

Jeśli chcesz pobrać dane bardzo szybko, to należy wyrównać indeksy tabeli i użyć poprawić wybór w szerokim zakresie kolumn, podobnym do tego, co zaproponowałeś. Jeśli jednak jesteś zainteresowany budowaniem danych dla szybkich aktualizacji, to używanie normalizacji na poziomie 3 lub 4 w połączeniu z dużą liczbą połączeń tabel powinno zapewniać lepszą wydajność.

Answer 3

Jeśli uzyskujesz dostęp do wszystkich (lub większości) pasm w każdym rzędzie, to zdormowany formularz jest lepszy. Znacznie lepiej w moim doświadczeniu.

Powód jest prosty. Rozmiar danych na stronach jest znacznie mniejszy, więc o wiele mniej stron należy przeczytać, aby spełnić zapytanie. Narzut na przechowywanie jednego pasma na wiersz to około 4 liczby całkowite lub 32 bajty. Tak więc 100 pasm to około 3200 bajtów. W jednym rekordzie rekord wynosi 100 * 4 + 8 lub około 408 bajtów. Jeśli zapytanie odczytuje znaczną liczbę rekordów, znacznie zmniejsza to wymagania dotyczące operacji wejścia/wyjścia.

Istnieje zastrzeżenie. Jeśli czytasz tylko jedną wartość, to 100 rekordów pasuje do pojedynczej strony w SQL i jeden rekord mieści się na jednej stronie. We/wy dla odczytu jednej strony może być identyczne w obu przypadkach. Pojawia się korzyść, że czytasz coraz więcej danych.

Twoje przykładowe zapytanie odczytuje setki lub tysiące wierszy, więc takie zapytanie powinno przydać się do denormalizacji.

Answer 4

Denormalizacja optymalizuje dokładnie jeden sposób dostępu do danych, kosztem (prawie wszystkich) innych.

Jeśli masz tylko jedną metodę dostępu, która ma krytyczne działanie, prawdopodobnie pomoże jej denormalizacja; chociaż odpowiednia selekcja indeksu przynosi większe korzyści. Jeśli jednak masz wiele krytycznych ścieżek dostępu do danych, lepiej jest szukać innych optymalizacji.

Utworzenie odpowiedniego indeksu klastrowego; umieszczanie indeksów nieklastrowych na dyskach SSD. zwiększenie pamięci na serwerze; są wszystkie techniki, które poprawią wydajność dla dostępu, a nie handlują pomiędzy różnymi dostępami.