In che modo aiuta il partizionamento delle tabelle?


28

Sto avendo difficoltà ad afferrare l'idea di pro e contro del partizionamento delle tabelle. Sto per iniziare a lavorare su un progetto che avrebbe 8 tabelle e una di esse sarà la tabella di dati principale che conterrà 180-260 milioni di record. Poiché sarà una tabella correttamente indicizzata, quindi sto pensando di limitare i record della tabella a 20 milioni in questo modo dovrei creare 9-13 tabelle.

Ma non sono del tutto sicuro di come migliorerà le prestazioni perché saranno posizionate sulla stessa macchina (32 GB di RAM)?

Sto usando MySQL e le tabelle sarebbero MyISAM e la tabella grande avrebbe indice sul campo ID e non ci sono ulteriori complessità come la ricerca full text ecc.

Si prega inoltre di far luce sul partizionamento delle tabelle rispetto al partizionamento del database.


Spiegare quale tipo di ricerca indicizzata verrà eseguita sulla tabella diversa dall'ID. Ti indicherà il tipo di partizionamento da eseguire.
RolandoMySQLDBA

Sarà solo id.
Rick James,

"Solo ID" non ci dice ancora nulla. Come vengono distribuiti gli ID nell'intervallo di tutti gli ID? Stai chiedendo principalmente quelli più recenti, è veramente distribuito? L'accesso ai dati verrà letto o scritto per lo più? Tutte queste sono domande importanti alle quali abbiamo bisogno di risposte prima di poterti aiutare in modo specifico. Detto questo, le risposte che seguono sono davvero utili :)
Walter Heck,

1
Ecco i miei sentimenti 5 anni dopo aver iniziato questa discussione.
Rick James,

Risposte:


32

Quella che segue è solo folle ranting e delirio ...

Se si lasciano tutti i dati in una tabella (senza partizionamento), si avranno i tempi di ricerca O (log n) usando una chiave. Prendiamo l'indice peggiore del mondo, l'albero binario. Ogni nodo dell'albero ha esattamente una chiave. Un albero binario perfettamente bilanciato con 268.435.455 (2 ^ 28 - 1) nodi d'altezza sarebbe un'altezza di 28. Se dividi questo albero binario in 16 alberi separati, otterrai 16 alberi binari ciascuno con 16.777.215 (2 ^ 24 - 1) nodi dell'albero per un'altezza di 24. Il percorso di ricerca è ridotto di 4 nodi, con una riduzione dell'altezza del 14,2857%. Se il tempo di ricerca è in microsecondi, una riduzione del 14,2857% nei tempi di ricerca è nulla da trascurare.

Ora nel mondo reale, un indice BTREE avrebbe treenodi con più chiavi. Ogni ricerca BTREE eseguirà la ricerca binaria all'interno della pagina con un possibile decente in un'altra pagina. Ad esempio, se ogni pagina BTREE conteneva 1024 chiavi, un'altezza dell'albero di 3 o 4 sarebbe la norma, una breve altezza dell'albero.

Si noti che la partecipazione di una tabella non riduce l'altezza del BTREE che è già piccolo. Dato un partizionamento di 260 milioni di file, c'è anche la forte probabilità di avere più BTREE con la stessa altezza. La ricerca di una chiave può passare tutte le pagine principali di BTREE ogni volta. Solo uno soddisferà il percorso dell'intervallo di ricerca necessario.

Ora espandi su questo. Tutte le partizioni esistono sulla stessa macchina. Se non si dispone di dischi separati per ciascuna partizione, si avranno rotazioni I / O del disco e mandrino come un collo di bottiglia automatico al di fuori delle prestazioni di ricerca della partizione.

In questo caso, il partizionamento per database non ti compra nulla se id è l'unica chiave di ricerca che viene utilizzata.

Il partizionamento dei dati dovrebbe servire a raggruppare i dati che sono logicamente e coerentemente nella stessa classe. Le prestazioni di ricerca in ogni partizione non devono essere la considerazione principale finché i dati sono raggruppati correttamente. Una volta ottenuto il partizionamento logico, concentrati sul tempo di ricerca. Se si stanno solo separando i dati solo per ID, è possibile che non sia mai possibile accedere a molte righe di dati per letture o scritture. Ora, questa dovrebbe essere una considerazione importante: individuare tutti gli ID a cui si accede più frequentemente e partizionarli . Tutti gli ID con accesso meno frequente dovrebbero risiedere in una grande tabella di archivio che è ancora accessibile dalla ricerca dell'indice per quella query "una volta in una luna blu".

L'impatto globale dovrebbe essere quello di avere almeno due partizioni: una per ID con accesso frequente e l'altra per il resto degli ID. Se gli ID a cui si accede di frequente è abbastanza grande, è possibile partizionarlo facoltativamente.


16

200 milioni di righe sono certamente nell'intervallo in cui è possibile trarre vantaggio dal partizionamento delle tabelle. A seconda della tua applicazione, puoi scommettere alcuni dei vantaggi elencati di seguito:

  • Facilità di eliminazione dei vecchi dati Se è necessario cancellare i record più vecchi di (diciamo) 6 mesi, è possibile partizionare la tabella alla data e quindi sostituire le partizioni più vecchie. Questo è molto più veloce dell'eliminazione dei dati da una tabella e spesso può essere eseguito su un sistema live. Nel caso del PO questo potrebbe essere utile per la manutenzione del sistema.

  • Volumi su più dischi Il partizionamento consente di dividere i dati per distribuire il traffico su più volumi su disco per maggiore velocità. Con un moderno controller RAID questo non è probabilmente un problema per l'OP.

  • Scansioni più rapide di tabelle e intervalli In realtà, un sistema operativo non dovrebbe fare questo genere di cose, ma un data warehouse o un sistema simile eseguirà questo tipo di query in quantità. Le scansioni delle tabelle utilizzano principalmente il traffico su disco sequenziale, quindi sono in genere il modo più efficiente per elaborare una query che restituisce più di una percentuale delle righe in una tabella.

    Il partizionamento tramite un filtro comune (in genere basato su tempo o periodo) consente di eliminare grossi blocchi della tabella da tali query se il predicato può essere risolto rispetto alla chiave di partizionamento. Inoltre, consente di suddividere la tabella su più volumi, il che può offrire significativi miglioramenti delle prestazioni per set di dati di grandi dimensioni. Normalmente, questo non è un problema per i sistemi operativi.

Ai fini del PO, il partizionamento non è suscettibile di ottenere molti vantaggi in termini di prestazioni per le query operative, ma può essere utile per la gestione del sistema. Se esiste un requisito significativo per la segnalazione di aggregati su grandi volumi di dati, uno schema di partizionamento appropriato può essere di aiuto.


1

Il partizionamento consente reorg simultanei per partizione, se tutti gli indici sono partizionati. In caso contrario, le partizioni sono ancora molto più piccole e utilizzano meno spazio di lavoro per riforgiare. E, internamente, qualsiasi "buon" DBMS può fare le cose in parallelo con le tabelle partizionate. Ciò probabilmente NON include MySQL o MyISAM, anche se ...


MySQL non fa alcuna elaborazione parallela, anche quando partizionamento è coinvolto. MySQL indicizza solo una partizione; quindi UNIQUEe FOREIGN KEYnon sono realmente disponibili nelle tabelle partizionate. Partizionare su MyISAM contro InnoDB - nessuna differenza rispetto alle cose discusse in questo thread.
Rick James,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.