Una chiave primaria a 5+ colonne è dannosa per una tabella di grandi dimensioni (100 milioni +)?

Stavo leggendo alcuni problemi di DB nella vita reale e un progetto aveva una riga di oltre 100 milioni di righe con 5 colonne come principale. Sto pensando che sia un male, ma qualcuno può dirmi esattamente perché?

La tabella era una specie di micro tabella di rollup / aggregazione, quindi le 5 colonne erano come (giorno, market_id, product_id ...). All'inizio pensavo che una chiave primaria a 5 colonne non fosse l'ideale, ma più pensavo che non potevo davvero trovare una buona ragione per cui fosse cattiva.

Questo è stato in una discussione a tarda notte con metà degli ingegneri dell'azienda. Qualcuno ha appena detto che si trattava di una cattiva progettazione, concordò un ingegnere senior, ma nessuno si mise davvero d'accordo sul perché. Quindi, cercando di indagare sulla questione da solo!

Esistono problemi di prestazioni con chiavi primarie molto complesse. E potrebbe non difendersi dalla duplicazione, così come potrebbe essere una chiave primaria più semplice.

Tuttavia, esiste un modello di progettazione che spesso restituisce tabelle con una chiave primaria composta da circa sei componenti. Sono le tabelle dei fatti dello schema a stella. Se la tabella dei fatti di uno schema a stella ha sei dimensioni, la chiave primaria avrà sei componenti. Non ho mai visto una tabella dei fatti senza chiave primaria dichiarata e penso che valga la pena l'overhead, anche se il processo ETL deve ancora essere scritto con molta attenzione.

Alcuni database di report imitano il modello dello schema a stella anche se non è stato progettato in modo esplicito in questo modo.

Oltre 100 milioni di righe non sono eccessivamente grandi per una tabella dei fatti, soprattutto con i big data di oggi.

La tabella in questione era una tabella di rollup / aggregazione.

Quindi non va solo bene, è "giusto".

E puzza come una tabella di riepilogo, poiché inizia con day.

Hai degli indici secondari? Tieni presente che se stai utilizzando InnoDB, il resto delle colonne PRIMARY KEY verrà aggiunto alla fine dell'indice secondario. Ancora una volta, questo non è necessariamente un problema.

100 milioni di righe sono molte per un rollup. Sembra che il tavolo sia troppo fine. Cioè, forse invece se (data, a, b, c, d) dovresti avere 4 rollup con PK come (data, a, b, c), (data, b, c, d), (data, c, d, a), (data, d, a, b) (o alcune combinazioni adatte). Lo sto facendo, ognuno potrebbe essere solo 10 M righe, quindi rendere i report ancora più veloci, pur avendo quasi la stessa flessibilità nel report.

O forse passare a (settimana, a, b, c, d), portando a forse solo 14 milioni di righe. (Probabilmente di più.)

Utilizzo di PARTITION per facilitare la potatura --- Ingestione ad alta velocità --- Suggerimenti per il data warehouse --- Tabelle di riepilogo . Questi riassumono molte delle tecniche che ho sviluppato in diversi progetti DW. Come puoi dedurre, ogni progetto è diverso. Il numero "tipico" di tabelle riassuntive (nella mia esperienza) è 3-7. L'obiettivo nel riepilogo è di 10 righe dei fatti -> 1 riga di riepilogo. (Potrebbe essere una "mediana".) In un raro caso, ho riassunto una tabella riassuntiva. In un altro raro caso, ho partizionato una tabella di riepilogo con buoni risultati; di solito le tabelle di riepilogo sono abbastanza piccole, quindi sono abbastanza veloci per l'accesso diretto da un'interfaccia utente.

Bene, in realtà avere un PK con 5+ colonne non è necessariamente male in sé.

Diventa cattivo una volta che il PK è anche l'indice cluster in quanto quello verrebbe conteggiato come identificatore di riga e quindi verrebbe aggiunto a ciascuna riga in un indice NC. Ciò aumenterebbe drasticamente lo spazio richiesto.

Sarebbe anche un male se si utilizza effettivamente il PK da un altro FK, poiché è necessario disporre dei dati di tutte le 5+ colonne nella tabella corrente e in quella a cui si fa riferimento. Ancora una volta aumenterà di molto lo spazio di archiviazione!

Dal punto di vista delle prestazioni, sarà negativo una volta che il PK è stato utilizzato come indice - lascia che sia solo all'interno della tabella o in combinazione con un FK - poiché una chiave PK più grande contenente 5+ colonne occuperà più spazio, quindi meno voci rientrare in una pagina e d'ora in poi è necessario leggere più pagine per analizzare l'indice.

Detto questo, potrebbe esserci sempre una buona ragione per farlo effettivamente, come ad esempio una tabella dei fatti. Pertanto la risposta migliore sarebbe effettivamente come nella maggior parte dei casi: dipende!

Saluti Dennis

Per circa 15 anni non ho bisogno di tale chiave, l'ho visto a volte, e stava solo causando problemi. Molti problemi. Prima di tutto, la chiave primaria serve per conservare l'integrità dei dati e dovrebbero essere sintetici. Non dovrebbero avere alcun legame con il mondo reale. Perché ? Una volta che il mondo reale cambierà e, sicuramente, la tua chiave primaria scomparirà e dovrai aggiornarla e tutte le informazioni correlate.

Imagime è necessario ricordare questo ker in qualche altra tabella / database / servizio anziché in un campo è necessario copiarne diversi e si può dimenticare di copiarne alcuni. Invece la chiave primaria sysntetic, è solo un pezzo di dati, devi fornire. Non sto menzionando l'unicità dell'indice, che può essere trattata da un altro enorme argomento di discussione.

Quindi un breve riassunto, chiave primaria sintetica (autoincremento, guid, ..) è semplice da mantenere, copiare, ...

Quindi, considero la chiave primaria sintetica e un'altra chiave per 5 colonne che hai citato.

Alla fine, se la tabella è solo aggregata e mai qualcuno dovrà mai fare riferimento alla riga per chiavi (ma il mondo cambia, fidati di me, almeno per me cambia in modo permanente), probabilmente lo lascerò come è (primario chiave con cinque righe), ma nel caso in cui lo avessimo, causa sempre molti problemi. Quindi te l'ho detto.