Ho una grande tabella (diversi 100 milioni di righe) che vorrei dividere in modo efficiente. La mia domanda è se esiste un compromesso tra dimensione della partizione e numero di partizioni. Per quanto ho capito, la maggior parte delle query su una colonna utilizzata nella partizione sarà più veloce perché la query (per la maggior parte delle query) dovrà solo cercare all'interno della partizione applicabile alla query. Pertanto, sarebbe logico che, al fine di massimizzare l'efficienza, si debba dividere una tabella di grandi dimensioni nel numero massimo di partizioni, quindi, rendendo ogni partizione il più piccola possibile. Nel caso di MySQL, questo significa 1024 partizioni. Ma c'è qualche svantaggio prestazionale nell'avere un gran numero di partizioni? È così, come si trova il numero ottimale di partizioni?

Nota: esiste già una domanda in qualche modo simile su StackOverflow , ma solo una risposta, che (dal mio punto di vista) manca il segno. Quindi esporrò la domanda a modo mio ... speriamo che sia più chiaro

Confrontiamoli

DIMENSIONE DELLA PARTIZIONE

Se si dispone di quanto segue:

• 100 milioni di righe in una tabella
• Indicizzazione BTREE
• Ogni pagina nel BTREE contiene 1024 chiavi

Come sarebbero le metriche?

Poiché LOG (100000000) / LOG (2) = 26.575424759099, un indice BTREE con 1024 chiavi per pagina treenode avrebbe un'altezza dell'albero di soli 3 (SOFFITTO (LOG (100000000) / LOG (1024))). Con solo tre nodi di pagine, una ricerca binaria della chiave necessaria in ciascun treenode a cui si accederebbe comporterebbe una potatura e un isolamento di circa 30 chiavi.

NUMERO DI PARTIZIONI

Se si dispone di quanto segue:

• 100 milioni di righe in una tabella
• Indicizzazione BTREE
• Ogni pagina nel BTREE contiene 1024 chiavi
• Si creano 1024 partizioni

I numeri sarebbero leggermente diversi.

Ogni partizione dovrebbe avere circa 97656 righe. Cosa diventerebbero ora le metriche?

Poiché LOG (97656) / LOG (2) = 16.575421065795, un indice BTREE con 1024 chiavi per pagina treenode avrebbe un'altezza dell'albero di soli 2 (SOFFITTO (LOG (97656) / LOG (1024))). Con solo due nodi di pagine, una ricerca binaria della chiave necessaria in ciascun treenode a cui si accederebbe comporterebbe una potatura e un isolamento di circa 20 chiavi.

CONCLUSIONE

La distribuzione delle chiavi rimuove solo un livello dell'albero ma essenzialmente crea 1024 indici. Le query non conosceranno la differenza. Il tempo di ricerca sarebbe probabilmente al massimo nominale a favore delle partizioni. Tuttavia, assicurarsi che tutti i dati siano attivi. Altrimenti, potresti colpire solo alcune partizioni, mentre altre partizioni con dati a cui si accede raramente occupano solo spazio e non sono mai abbastanza frequenti da giustificare il partizionamento . Potresti avere diverse metriche delle prestazioni di cui preoccuparti che sono più evidenti (come la deframmentazione interna in XFS , ext3 vs ext4, ecc.) Inoltre devi preoccuparti di quale motore di archiviazione stai utilizzando perché:

• L'indicizzazione di InnoDB sarebbe un po 'più complicata rispetto a MyISAM a causa della necessità di gestire un indice cluster
• InnoDB esegue una doppia scrittura dei dati in ibdata1 e nel file di registro corrente (ib_logfile0 o ib_logfile1)