Partizionamento/sharding/divisione MySQL: quale strada percorrere?
https://stackoverflow.com/questions/45879
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Disponiamo di un database InnoDB di circa 70 GB e prevediamo che cresca fino a diverse centinaia di GB nei prossimi 2 o 3 anni.Circa il 60% dei dati appartiene ad un'unica tabella.Attualmente il database funziona abbastanza bene dato che abbiamo un server con 64 GB di RAM, quindi quasi tutto il database sta in memoria, ma siamo preoccupati per il futuro quando la quantità di dati sarà notevolmente maggiore.In questo momento stiamo valutando un modo per suddividere le tabelle (soprattutto quella che rappresenta la maggior parte dei dati) e mi chiedo quale sarebbe il modo migliore per farlo.
Le opzioni di cui sono attualmente a conoscenza sono
- Utilizzando MySQL Partitioning fornito con la versione 5.1
- Utilizzando una sorta di libreria di terze parti che incapsula il partizionamento dei dati (come i frammenti di ibernazione)
- Implementandolo noi stessi all'interno della nostra applicazione
La nostra applicazione è basata su J2EE ed EJB 2.1 (speriamo di passare a EJB 3 un giorno).
Che cosa suggeriresti?
MODIFICA (11-02-2011):
Solo un aggiornamento:Attualmente la dimensione del database è di 380 GB, la dimensione dei dati della nostra tabella "grande" è di 220 GB e la dimensione del suo indice è di 36 GB.Quindi, mentre l'intera tabella non entra più nella memoria, l'indice sì.
Il sistema funziona ancora bene (sempre sullo stesso hardware) e stiamo ancora pensando di partizionare i dati.
MODIFICA (04-06-2014):Un altro aggiornamento:La dimensione dell'intero database è di 1,5 TB, la dimensione della nostra tabella "grande" è di 1,1 TB.Abbiamo aggiornato il nostro server a una macchina a 4 processori (Intel Xeon E7450) con 128 GB di RAM.Il sistema funziona ancora bene.Ciò che intendiamo fare dopo è mettere il nostro grande tavolo su un server database separato (abbiamo già apportato le modifiche necessarie al nostro software) aggiornando contemporaneamente al nuovo hardware con 256 GB di RAM.
Questa configurazione dovrebbe durare due anni.Quindi dovremo finalmente iniziare a implementare una soluzione di sharding o semplicemente acquistare server con 1 TB di RAM che dovrebbero permetterci di andare avanti per un po' di tempo.
MODIFICA (18-01-2016):
Da allora abbiamo inserito il nostro grande tavolo nel proprio database su un server separato.Attualmente la dimensione di questo database è di circa 1,9 TB, la dimensione dell'altro database (con tutte le tabelle tranne quella "grande") è di 1,1 TB.
Configurazione hardware attuale:
- HP ProLiantDL580
- 4 CPU Intel(R) Xeon(R) E7-4830
- 256 GB di RAM
Le prestazioni vanno bene con questa configurazione.
Soluzione
Se pensi che sarai vincolato a IO/memoria, non penso che il partizionamento sarà utile.Come al solito, il benchmarking ti aiuterà prima a capire la direzione migliore.Se non disponi di server di riserva con 64 GB di memoria, puoi sempre chiedere al tuo fornitore una "unità demo".
Mi propenderei per lo sharding se non ti aspetti un reporting aggregato di 1 query.Presumo che divideresti l'intero database e non solo la tua grande tabella:è meglio tenere insieme intere entità.Bene, se il tuo modello si divide bene, comunque.
Altri suggerimenti
Inizierai sicuramente a riscontrare problemi su quel tavolo da 42 GB una volta che non si adatterà più alla memoria.Infatti, non appena non entra più in memoria, le prestazioni diminuiranno molto rapidamente.Un modo per testare è mettere quella tabella su un'altra macchina con meno RAM e vedere quanto sono scarse le sue prestazioni.
Prima di tutto, non è così importante suddividere le tabelle a meno che non si spostino anche alcune tabelle in un volume fisico separato.
Ciò non è corretto.Il partizionamento (tramite la funzionalità di MySQL 5.1 o la stessa cosa utilizzando le tabelle MERGE) può fornire vantaggi significativi in termini di prestazioni anche se le tabelle si trovano sulla stessa unità.
Ad esempio, supponiamo che tu stia eseguendo query SELECT sulla tua tabella di grandi dimensioni utilizzando un intervallo di date.Se la tabella è intera, la query sarà costretta a scansionare l'intera tabella (e con quelle dimensioni, anche l'utilizzo degli indici può essere lento).Il vantaggio del partizionamento è che le query verranno eseguite solo sulle partizioni in cui è assolutamente necessario.Se ciascuna partizione ha una dimensione di 1 GB e la tua query deve accedere solo a 5 partizioni per realizzarsi, la tabella combinata da 5 GB è molto più semplice da gestire per MySQL rispetto a una versione mostruosa da 42 GB.
Una cosa che devi chiederti è come stai interrogando i dati.Se esiste la possibilità che le tue query necessitino solo di accedere a determinati blocchi di dati (ad es.un intervallo di date o un intervallo di ID), un partizionamento di qualche tipo si rivelerà utile.
Ho sentito che ci sono ancora alcuni problemi con il partizionamento di MySQL 5.1, in particolare legati alla scelta della chiave corretta da parte di MySQL.Le tabelle MERGE possono fornire la stessa funzionalità, anche se richiedono un sovraccarico leggermente maggiore.
Spero che questo aiuti... buona fortuna!
Questo è un ottimo esempio di cosa può fare il partizionamento MySql in un esempio reale di enormi flussi di dati:
Spero che possa essere utile per il tuo caso.
Qualche tempo fa, a un evento Microsoft ArcReady, ho visto una presentazione sui modelli di ridimensionamento che potrebbe esserti utile.Puoi visualizzare le diapositive per questo in linea.
Io opterei per MariaDB InnoDB + Partizioni (per chiave o per data, a seconda delle tue domande).
L'ho fatto e ora non ho più problemi con il database.
MySQL può essere sostituito con MariaDB in pochi secondi...tutti i file del database rimangono gli stessi.
Prima di tutto, non è così importante suddividere le tabelle a meno che non si spostino anche alcune tabelle in un volume fisico separato.
In secondo luogo, non è necessariamente il tavolo con le dimensioni fisiche maggiori che desideri spostare.Potresti avere una tabella molto più piccola che riceve più attività, mentre la tabella grande rimane abbastanza costante o aggiunge solo dati.
Qualunque cosa tu faccia, non implementarla tu stesso.Lascia che sia il sistema di database a gestirlo.
Cosa fa il grande tavolo?
Se hai intenzione di dividerlo, hai alcune opzioni:
- Dividilo utilizzando il sistema di database (non ne so molto)
- Dividilo per riga.
- dividilo per colonna.
Dividerlo per riga sarebbe possibile solo se i tuoi dati potessero essere facilmente separati in blocchi.per esempio.Qualcosa di simile a Campo base ha più account completamente separati.Potresti mantenere il 50% dei conti in una tabella e il 50% in una tabella diversa su una macchina diversa.
La divisione per colonna è utile per le situazioni in cui la dimensione della riga contiene campi di testo o BLOB di grandi dimensioni.Se hai una tabella con (ad esempio) un'immagine utente e un enorme blocco di testo, potresti inserire l'immagine in una tabella completamente diversa.(su una macchina diversa)
Qui si interrompe la normalizzazione, ma non credo che causerebbe troppi problemi.
Come al solito, il benchmarking ti aiuterà prima a capire la direzione migliore.
Questo è quello che mi dice la maggior parte della gente, quindi penso che finalmente dovrò prendere quella pillola...
Probabilmente alla fine vorrai dividere quel grande tavolo.Probabilmente vorrai metterlo su un disco rigido separato, prima di pensare a un secondo server.Farlo con MySQL è l'opzione più conveniente.Se è capace, allora provaci.
MA
Tutto dipende da come viene utilizzato il tuo database, in realtà.Statistiche.
