Czy klucz główny z kolumną 5+ jest zły dla dużej (100 milionów +) tabeli?

Czytałem o niektórych rzeczywistych problemach z DB, a jeden projekt miał 100 milionów wierszy plus tabela, która miała 5 kolumn jako podstawową. Myślę, że to źle, ale czy ktoś może mi dokładnie powiedzieć, dlaczego?

Tabela była rodzajem mikropakietowania / tabeli agregacji, więc 5 kolumn było podobnych (dzień, identyfikator_ rynku, identyfikator_produktu ...). Na początku myślałem, że klucz podstawowy z 5 kolumnami nie jest idealny, ale im bardziej myślałem, nie mogłem znaleźć dobrego powodu, dla którego był zły.

Było to podczas późnej nocy dyskusji z połową inżynierów firmy. Ktoś właśnie wspomniał, że to zły projekt, zgodził się jeden starszy inżynier, ale nikt tak naprawdę nie wskoczył na to, dlaczego. W ten sposób próbuję zbadać sprawę dla siebie!

Występują problemy z wydajnością bardzo złożonych kluczy podstawowych. I może nie bronić się przed powielaniem, jak również może być prostszy klucz podstawowy.

Istnieje jednak jeden wzorzec projektowy, który często daje tabele z kluczem podstawowym złożonym z około sześciu komponentów. To tabele faktów na schemacie gwiazdy. Jeśli tabela faktów schematu gwiaździstego ma sześć wymiarów, klucz podstawowy będzie miał sześć składników. Nigdy nie widziałem tabeli faktów bez zadeklarowanego klucza podstawowego i myślę, że jest to warte narzutu, mimo że proces ETL wciąż musi być dość starannie napisany.

Niektóre bazy danych raportowania naśladują wzór schematu gwiazdy, nawet jeśli nie jest on wyraźnie zaprojektowany w ten sposób.

Ponad 100 milionów wierszy nie jest zbyt duże jak na tabelę faktów, szczególnie w dzisiejszych dużych danych.

Ta tabela była tabelą zestawień / agregacji.

W takim razie jest to nie tylko w porządku, ale „właściwe”.

I pachnie jak tabela podsumowań, ponieważ zaczyna się od day.

Czy masz jakieś indeksy wtórne? Pamiętaj, że jeśli używasz InnoDB, pozostałe kolumny KLUCZA PODSTAWOWEGO zostaną umieszczone na końcu indeksu wtórnego. Znów nie jest to problem.

100 mln wierszy to bardzo dużo w przypadku zestawienia. Wygląda na to, że stół jest zbyt drobnoziarnisty. To znaczy, być może zamiast tego, jeśli (data, a, b, c, d) powinieneś mieć 4 zestawienia z PK takimi jak (data, a, b, c), (data, b, c, d), (data, c, d, a), (data, d, a, b) (lub niektóre odpowiednie kombinacje). Robię to, każdy może mieć tylko 10 milionów wierszy, dzięki czemu raporty są jeszcze szybsze, a jednocześnie mają prawie taką samą elastyczność w raportach.

A może przełącz się na (tydzień, a, b, c, d), co może prowadzić tylko do 14 milionów wierszy. (Prawdopodobnie więcej.)

Korzystanie ze PARTYCJI w celu ułatwienia przycinania --- Spożycie z dużą prędkością --- Wskazówki dotyczące hurtowni danych --- Tabele podsumowań . Podsumowują one wiele technik, które opracowałem w kilku projektach DW. Jak można wywnioskować, każdy projekt jest inny. „Typowa” liczba tabel podsumowań (z mojego doświadczenia) to 3-7. Podsumowując, celem jest 10 wierszy faktów -> 1 wiersz podsumowań. (Może to być „mediana”). W rzadkich przypadkach podsumowałem tabelę podsumowań. W innym rzadkim przypadku podzieliłem na partycje tabelę podsumowań, aby uzyskać dobry efekt; zwykle tabele podsumowań są wystarczająco małe, więc są wystarczająco szybkie, aby uzyskać bezpośredni dostęp z interfejsu użytkownika.

Właściwie posiadanie PK z 5+ kolumnami niekoniecznie jest samo w sobie złe.

Staje się zły, gdy PK jest również indeksem klastrowym, ponieważ byłby on liczony jako identyfikator wiersza, a zatem byłby dodawany do każdego wiersza w indeksie NC. To drastycznie zwiększy wymaganą przestrzeń.

Byłoby również źle, gdybyś faktycznie używał PK przez innego FK, ponieważ musisz mieć dane ze wszystkich 5+ kolumn zarówno w bieżącej tabeli, jak i tej, do której się odwołujesz. Po raz kolejny znacznie zwiększy pamięć!

Pod względem wydajności będzie źle, gdy PK zostanie użyty jako indeks - niech będzie wyłącznie w tabeli lub w połączeniu z FK - ponieważ większy klucz PK zawierający 5+ kolumn zajmie więcej miejsca, a zatem mniej wpisów będzie mieści się na stronie i odtąd więcej stron musi być czytanych w celu analizy indeksu.

To powiedziawszy - zawsze może istnieć dobry powód, na przykład tabela faktów. Dlatego najlepsza odpowiedź byłaby tak jak w większości przypadków: To zależy!

Pozdrawiam Dennis

Od ponad 15 lat nie potrzebuję takiego klucza, czasami go widziałem, a to tylko powodowało kłopoty. Wiele problemów. Przede wszystkim klucz podstawowy służy do zachowania integralności danych i powinny być syntetyczne. Nie powinny mieć żadnego związku z prawdziwym światem. Dlaczego ? Gdy rzeczywisty świat się zmieni i na pewno zniknie twój klucz podstawowy, musisz go zaktualizować i wszystkie powiązane informacje.

Wyobraź sobie, że musisz pamiętać ten ker w innej tabeli / bazie danych / usłudze zamiast jednego pola, musisz skopiować kilka i możesz zapomnieć o skopiowaniu niektórych z nich. Zamiast tego sysntetyczny klucz podstawowy to tylko jedna część danych, którą musisz podać. Nie wspominam o wyjątkowości indeksu, który może być kolejnym wielkim tematem do dyskusji.

Tak krótkie podsumowanie, syntetyczny klucz podstawowy (automatyczne zwiększanie, guid, ...) jest prosty w utrzymaniu, kopiowaniu, ...

Rozważam więc syntetyczny klucz podstawowy i kolejny klucz do 5 wspomnianych kolumn.

W końcu, jeśli tabela jest tylko agregacją i nigdy nie będzie ktoś musiał odwoływać się do wiersza według kluczy (ale zmiany w świecie, zaufaj mi, to przynajmniej dla mnie zmieni się na stałe), prawdopodobnie zostawię to tak, jak jest (pierwotne klucz z pięcioma rzędami), ale w przypadku, gdy mieliśmy, zawsze powoduje wiele problemów. Więc ci powiedziałem.