Perché NON partizionare?

Quando NON si vorrebbe partizionare un database? (pensando al partizionamento MySQL )

Nel mio caso

Inizierò con un paio di milioni di righe, dovrebbe crescere da lì.
Chiave primaria in un campo di caratteri che funge da restrizione alla query più frequente (e le ricerche sono frequenti, almeno alcuni al secondo).
La chiave primaria verrebbe codificata come chiave di partizione
Verranno effettuati aggiornamenti per ogni riga che viene estratta nelle frequenti query sopra menzionate
Ricerche meno frequenti (contro colonne di date o altro) dovranno colpire tutte le partizioni

Anche per l'ultimo punto, la ricerca non funziona in parallelo, quindi in tutti i casi è una vittoria ? Quali sono gli svantaggi del partizionamento? Perché non è qualcosa che TUTTI usano per impostazione predefinita, almeno quando si guardano oltre un milione di record?

AGGIORNAMENTO - Ho selezionato la risposta di zgguy ma nota che ho aggiunto la mia risposta con i risultati della mia ricerca, incluso un link a una risposta davvero valida su una domanda simile che mi è stata molto utile.

mysql database-design partitioning

— Chell
fonte

Risposte:

Non esiste un proiettile d'argento per problemi di prestazioni e neanche il partizionamento è uno.

Ogni partizione è essenzialmente una tabella per sé. Quindi le query scritte in un modo che consente al database di cercare righe in una sola partizione diventano più veloci. La differenza può essere enorme per le query che avrebbero bisogno di scansionare l'intera tabella di grandi dimensioni, ma possono limitarsi a scansionare solo una partizione nella tabella partizionata. Per ricerche chiave uniche, la differenza è molto più piccola.

Tuttavia, le query che utilizzano le ricerche di indice in un modo che richiede al database di visitare tutte o la maggior parte delle partizioni di tabella (indice) verranno eseguite molto più lentamente.

L'esecuzione parallela è un argomento a sé stante. Se esegui grandi lotti durante la notte e hai l'intero computer per fare quel singolo lavoro, allora la sua parallelizzazione è una buona cosa. Tuttavia, in un sistema OLTP in cui il database serve costantemente query da molti utenti simultanei, non si desidera che un utente occupi tutte le risorse.

— zgguy
fonte

Quindi le ricerche di chiavi uniche / primarie non vedranno effettivamente molti miglioramenti (se ce ne sono?) Perché l'indice PK è più veloce? È su tutta la linea - ci sono momenti in cui un indice PK è più lento? Cosa succede se le ricerche sono inclinate rispetto ai PK aggiunti più di recente? Sarebbe utile una partizione basata sul PK (penso che l'algo della chiave di partizione debba essere modulo o simile e NON hash, giusto?) Che fa sì che la maggior parte delle attività colpisca solo una partizione sarebbe utile?

— chell

Le ricerche di chiavi primarie / uniche vedranno nella migliore delle ipotesi un lieve miglioramento delle prestazioni. D'altra parte, se il tuo obiettivo è ridurre la contesa delle istruzioni DML, devi partizionare in modo che il DML sia distribuito equamente su tutte le partizioni invece di concentrarti su alcune di esse.

— zgguy,

mi dispiace tornare 10 giorni dopo, ma sollevi un punto chiave - Hai fornito buone ragioni per vedere il partizionamento come possibilmente non necessario, tuttavia , il mio scenario include l'aggiornamento di ogni record dopo che è stato letto (diversi al secondo). La necessità di così tante scritture costituisce un caso più convincente per le partizioni (con distribuzione uniforme) in modo da distribuire il carico di scrittura?

— chell

Sto anche cercando di capire il tuo commento sulle query che colpiscono molte partizioni (che sono più lente). Se le query sono contro il PK che viene anche usato (con hash) come chiave di partizione, il DB non sa immediatamente a quale partizione andare in base all'hash della ricerca? Grazie per l'aiuto!

— chell

Spiacenti, non sono stato in grado di visitare lo scambio di stack di recente. La risposta a cui sei collegato è ottima. Credo che risponda ad entrambe le tue domande.

— zgguy,

La risposta qui è ben scritta e fa argomentazioni simili alla risposta di zgguy , che il partizionamento non ti dà molto, se del caso, avvantaggia uno scenario a macchina singola in cui le ricerche più frequenti sono basate sulla chiave primaria o qualcosa di simile (perché le ricerche indicizzate dovrebbero essere altrettanto veloci).

In effetti, un filo conduttore comune sembra essere che il motivo principale per la partizione sia tangenziale e principalmente legato alla gestione: ad esempio, separare i dati in base alla data se è necessario eliminare i vecchi record ogni tanto. Sebbene sia stato notato che ciò può anche avvantaggiare le prestazioni di ricerca se i dati sono tali che la maggior parte delle query raggiungerà solo i record aggiunti di recente.

Ho anche visto menzionare che MySQL non fa mai nulla in parallelo (sarebbe bello vedere alcuni collegamenti o ulteriori spiegazioni al riguardo).

Non ho visto nessuno parlare se l'attività di scrittura aggiunge o meno considerazioni diverse.

— Chell
fonte

Non credo che le scritture cambino la tua risposta. Hai menzionato 2 dei 4 casi d'uso che ho riscontrato. Ancora nessun parallelismo, anche in 8.0.

— Rick James,

La prima cosa che mi viene in mente è la potatura delle partizioni ; se non è qualcosa che le tue domande possono usare.

Avrai bisogno dell'eliminazione di grandi quantità di dati dalla tabella poiché il partizionamento ti aiuterebbe. Anche se vecchio, ma questo post di Peter ha alcuni punti da considerare.

e un'altra cosa a cui si può pensare è la facilità d'uso per semplici tabelle ... il partizionamento richiede ulteriore lavoro e manutenzione.

— mysql_user
fonte

Le versioni più recenti hanno una sintassi per limitare esplicitamente la query a una partizione. Non riesco a pensare a un motivo valido per averlo mai usato.

— Rick James,