Che cosa significa avere più colonne di ordinamento?

Question

Redshift consente di designare più colonne come colonne SORTKEY, ma la maggior parte della documentazione delle best practice è scritta come se ci fosse solo un singolo SORTKEY.

Se creo una tabella con SORTKEY (COL1, COL2), significa che tutte le colonne vengono archiviate ordinate per COL1, quindi COL2? O forse, dal momento che è un negozio colonnare, ogni colonna viene memorizzata in un ordine diverso? Cioè COL1 in ordine COL1, COL2 in ordine COL2 e le altre colonne non ordinate?

La mia situazione è che ho una tabella con (tra gli altri) un type_id e una colonna timestamp. I dati arrivano approssimativamente in ordine di data e ora. La maggior parte delle query viene unita contro/limitata da type_id e timestamp. Solitamente le clausole type_id sono più specifiche, il che significa che una percentuale molto più grande di righe può essere esclusa osservando la clausola type_id piuttosto che osservando la clausola timestamp. type_id è il DISTKEY per questo motivo. Sto cercando di capire i pro ei contro di SORTKEY (type_id), SORTKEY (stamp), SORTKEY (type_id,stamp), SORTKEY (stamp,type_id).

Grazie.

Answer 1

Se si dichiara SORTKEY(COL1, COL2), tutte le colonne verranno ordinate per COL1, quindi COL2 come se fosse stato eseguito ORDER BY (COL1, COL2).

Se si utilizza SORTKEY per accelerare un JOIN, AFAIU non ha importanza fintanto che si utilizza lo stesso SORTKEY nelle tabelle che verranno unite perché ciò che accade è un join di unione.

Se COL1 è altamente selettivo come il tuo type_id, significa che ci sono solo pochi numeri di file che ha lo stesso type_id. Pertanto, sebbene sia possibile aggiungere un'altra colonna a SORTKEY, la sua utilità è limitata perché la maggior parte dell'eliminazione delle righe è già avvenuta.

Se COL1 non è altamente selettivo come il vostro stamp (che è un po 'strano btw;? Mi sarei aspettato di essere più selettivi rispetto type_id In ogni modo ..), significa che il filtro da stamp non eliminerà più di tanto filari. Quindi ha più senso dichiarare una seconda chiave di ordinamento. Tuttavia, questo è meno efficiente rispetto al contrario, poiché eliminare le righe in precedenza sarebbe più economico. Se a volte si filtra per stamp ma non per type_id, potrebbe essere ragionevole farlo.

Answer 2

Usiamo anche Redshift e abbiamo circa 2 miliardi di record (+20 milioni ogni giorno) e devo dire che meno selettivo è il sort_key, più avanti dovrebbe essere nella lista sort_key.

Nel nostro caso (e si prega di essere informati di analizzare come si utilizzano/interrogare i propri dati) abbiamo utilizzato la data/ora come prima chiave_selezione. Il problema è che, anche entro 1 secondo, registriamo circa 200 righe, il che risulta che i nostri blocchi da 1 MB contengono solo pochi secondi e ogni tipo di dati in quel singolo blocco. Il significato, anche se il timestamp è altamente selettivo, dopo non possiamo filtrare ulteriormente poiché abbiamo tutti i tipi di dati in ogni blocco.

Recentemente abbiamo invertito l'ordine di sort_keys. Il primo ha circa 15 valori diversi, il secondo ne ha circa 30, ecc ... e il timestamp è l'ultimo ora, ma ancora, un blocco è ancora misurato in secondi.

Questi risultati, (poiché utilizziamo molto frequentemente i primi due sort_key come filtri) sono i seguenti: Vecchia soluzione: un anno di dati, selezionare un mese, il 91% dei blocchi diminuisce, ma dopo deve aprirsi tutti loro, anche se vogliamo filtrare ulteriormente.

La nuova soluzione scende di circa 14/15 dei blocchi nel primo passaggio, indipendentemente dall'intervallo di date, quindi circa il 95% di quelli rimanenti e il timestamp scende ancora del 91% rispetto ai rimanenti.

Lo abbiamo testato a fondo con due tabelle da 800 milioni di record, che erano uguali, tranne l'ordine delle chiavi di ordinamento. Maggiore era il periodo di tempo nella clausola 'where', i risultati migliori che abbiamo ottenuto. È diventato ancora più significativo in caso di join, ovviamente.

Quindi il mio suggerimento è, conoscere il proprio database e il tipo di query eseguite frequentemente, perché la colonna più selettiva potrebbe non essere la migliore prima_selezionata. Proprio come ha detto Enno Shioji, tutto dipende da cosa stai filtrando.

Answer 3

Devo dire che l'ordine per sort_key dovrebbe essere

1. considerano quelli di dist, filtro e si uniscono prima
2. considerano quelli di filtro, si uniscono
3. considerano quelli di filtro
4. considerano quelle in join
5. considerare quelli in gruppo per, ordine per (inclusa funzione finestra)

la regola generale: cardinalità inferiore posta per primo se stesso livello.