Klastry indeksów magazynu kolumn i klucze obce

Strojenie wydajności hurtowni danych za pomocą indeksów. Jestem dość nowy w SQL Server 2014. Microsoft opisuje następujące kwestie:

„Uważamy indeks klastrowanego magazynu kolumn za standard do przechowywania tabel faktów hurtowni dużych danych i oczekujemy, że będzie on używany w większości scenariuszy hurtowni danych. Ponieważ indeks klastrowanego magazynu kolumn jest aktualizowalny, obciążenie może wykonać dużą liczbę operacji wstawiania, aktualizacji, i usuń operacje ”. http://msdn.microsoft.com/en-us/library/gg492088.aspx

Jeśli jednak przeczytasz dalej w dokumentacji, znajdziesz pod ograniczeniami:

„Nie może mieć unikalnych ograniczeń, ograniczeń klucza podstawowego ani ograniczeń klucza obcego”.

To mnie bardzo myli! Dobrą praktyką (nieobowiązkową) jest posiadanie kluczy obcych w hurtowni danych z różnych powodów (integralność danych, relacje widoczne dla warstwy semantycznej ...)

Dlatego firma Microsoft zaleca klastrowane indeksy magazynu kolumn dla scenariuszy hurtowni danych; jednak nie może obsłużyć relacji klucza obcego ?!

Czy mam rację? Jakie inne podejścia doradzasz? W przeszłości korzystałem z nieklastrowanego indeksu magazynu kolumn w scenariuszach hurtowni danych, z upuszczaniem i przebudowywaniem dla ładowań danych. Jednak SQL Server 2014 nie dodaje żadnej nowej wartości dla hurtowni danych?

Masz tutaj wiele pytań:

P: (Brak kluczy obcych) bardzo mnie dezorientuje! Dobrą praktyką (nieobowiązkową) jest posiadanie Fk w DWH z różnych powodów (integralność danych, relacje widoczne dla warstwy semantycznej, ...)

Odp .: Prawidłowo, zwykle dobrą praktyką jest posiadanie kluczy obcych w hurtowni danych. Jednak klastrowane indeksy magazynu kolumn jeszcze tego nie obsługują.

P: Więc MS opowiada się za indeksami magazynu klastrowanych kolumn dla scenariuszy DWH, jednak nie może poradzić sobie z relacjami z FK ?!

Odp .: Microsoft udostępnia narzędzia. Od Ciebie zależy, jak korzystasz z tych narzędzi.

Jeśli Twoim największym wyzwaniem jest brak integralności danych w hurtowni danych, wówczas pożądanym narzędziem są konwencjonalne tabele z kluczami obcymi.

Jeśli Twoim największym wyzwaniem jest wydajność zapytań i chcesz sprawdzić swoją integralność danych w ramach procesu ładowania, wówczas pożądanym narzędziem są klastrowane indeksy magazynu kolumn.

P: Jednak SQL 2014 nie dodaje żadnej nowej wartości DWH?

Odp .: Na szczęście klastrowany magazyn kolumn nie był jedyną nową funkcją w SQL Server 2014. Na przykład sprawdź nowy estymator liczności.

P: Dlaczego jestem taki zły i gorzki z powodu sposobu, w jaki moja ulubiona funkcja została wdrożona?

Odp .: Złapałeś mnie - tak naprawdę nie zadałeś tego pytania - ale i tak odpowiem. Witamy w świecie oprogramowania firm trzecich, w którym nie wszystko jest zbudowane zgodnie z twoimi dokładnymi specyfikacjami. Jeśli z pasją czujesz zmianę, którą chciałbyś zobaczyć w produkcie Microsoft, sprawdź Connect.Microsoft.com . To ich proces przesyłania opinii, w którym możesz przesłać zmianę, inne osoby mogą ją zagłosować, a następnie zespół ds. Produktu czyta ją i mówi, dlaczego tego nie zrobi. Czasami. Zazwyczaj zaznaczają to jako „nie naprawi się, działa na moim komputerze”, ale hej, czasem dostajesz odpowiedzi.

Rozumiem, że czujesz, że brakuje ci części, do których byłeś przyzwyczajony. Ale to tylko dlatego, że ich brakuje.

Niemniej jednak SQL Server był z powodzeniem używany, gdy klucze obce były tylko koncepcją (którą wdrożyliśmy w tamtych czasach za pomocą wyzwalaczy), a nie fizyczną implementacją, taką jak ograniczenie. Deklaratywna integralność referencyjna istniała przynajmniej przez SQL Server 7.0, ale znacznie słabsza niż obecna implementacja.

Jeśli chodzi o wartość indeksu klastrowanego magazynu kolumnowego, zapewnia on indeks, a wiersze można aktualizować. Ta dyskusja może być dla ciebie cenna: http://sqlwithmanoj.com/2014/07/24/maintaining-uniqueness-with-clustered-columnstore-index-sql-server-2014/

Manoj zwraca uwagę, że istnieje sposób utworzenia widoku indeksowanego / zmaterializowanego na górze tej tabeli, z kluczem grupowania jako PK (pierwsza kolumna tabeli / widoku). To, czy ci to odpowiada, jest oczywiście decyzją, którą musisz podjąć.

Ale, jak skomentowali Aaron Bertrand i TomTom, chodzi o lepszą wydajność. Jeśli można zarządzać inne kwestie, które dotyczą Ciebie (i wierzę, że oni są w zarządzaniu), a następnie pojawi się sporo korzyści. Skorzystaj więc z ColumnStore, aby samodzielnie wykonać brakujące funkcje i zarządzać nimi.

To pytanie dotyczy SQL 2014, ale chcę podać dodatkowe informacje w świetle zmian wprowadzonych w SQL 2016 do indeksów magazynu kolumn, ponieważ może być trudno uporządkować ograniczenia w różnych wersjach, a to pytanie wciąż pojawia się dość wysoko w Google:

W przypadku SQL 2016 Microsoft opisuje metodę użycia nieklastrowanych indeksów Btree (które można teraz dodawać jako indeksy wtórne w klastrowanej tabeli magazynu kolumn) w celu wymuszenia ograniczeń klucza obcego, pod warunkiem że ograniczenie zostanie dodane przed indeksem magazynu kolumn: https: // docs .microsoft.com / en-us / sql / relational-databases / indexes / columnstore-indexes-design-guide

Niko Neugebauer ma również post na blogu na ten temat; w rzeczywistości możliwe jest bezpośrednie tworzenie unikalnych / obcych ograniczeń w tabelach magazynu kolumn (w swojej pracy stosowałem to podejście): http://www.nikoport.com/2015/09/15/columnstore-indexes-part-66- more-clustered-columnstore-ulepszenia-w-sql-server-2016 /