In che modo le dimensioni del database influiscono sulle prestazioni: teoria e realtà

C'è molto là fuori che dice che la dimensione del database non dovrebbe influire in modo significativo sulle prestazioni. Finché gli indici delle tabelle si adattano alla memoria, il database deve rimanere performante.

Tuttavia qual è la realtà? Se l'architettura del database non è la migliore, gli indici non si adattano alla memoria e ci sono potenzialmente molti dati ridondanti, ci sono guadagni significativi da fare semplicemente cancellando i dati ridondanti? Stimo che il 60-80% dei dati nel mio database potrebbe essere eliminato.

Ritengo che ridurre le dimensioni del database e aumentare la RAM in modo che gli indici possano adattarsi alla memoria darebbe un significativo aumento delle prestazioni che darebbe un po 'di respiro per alcuni mesi per effettuare la ricerca del sistema.

Esistono anche altri fattori quali IO, frammentazione, set di dati di lavoro ecc. Che influiscono sulle prestazioni in base alle dimensioni del database?

Dipende interamente da cosa stai facendo con i dati.

Per le operazioni di inserimento / aggiornamento / eliminazione di base che interessano solo poche righe, la crescita delle dimensioni dei dati non è probabilmente una grande considerazione. Il database utilizzerà gli indici in memoria per accedere alla pagina corretta. Si ottengono più errori cache quando le tabelle non si adattano più alla memoria. Tuttavia, il sovraccarico potrebbe essere lieve, a seconda del database, delle configurazioni del database e delle configurazioni hardware.

Se si eseguono query che richiedono scansioni di tabelle complete, le prestazioni aumenteranno in modo lineare o peggiorano con la dimensione dei dati. Gli indici possono effettivamente peggiorare la situazione, randomizzando gli accessi alle pagine, che quindi garantiscono praticamente la mancanza di cache.

Un'alternativa a più memoria è la velocità del disco migliorata - il disco a stato solido può fornire un enorme miglioramento.

È improbabile che il solo fatto di avere più dati influenzi le prestazioni a meno che le tabelle non vengano utilizzate nelle query. I dati sono ridondanti all'interno di una tabella o tra tabelle? Avere tavoli di grandi dimensioni che non vengono mai utilizzati è disordinato, ma ha un impatto minimo sulle prestazioni. È immaginabile che se si hanno miliardi di tabelle non necessarie, la compilazione di query potrebbe richiedere più tempo.

La regola di sintonizzazione numero uno AMM (Aggiungi più memoria) è semplice. È anche uno che è molto costoso e alla fine uno che non è efficace quando ci sono problemi nella selettività. Anche se un database si adatta completamente alla memoria, le prestazioni dell'applicazione possono essere pessime. Nel peggiore dei casi a causa del blocco e del latching durante esecuzioni SQL molto selettive. Questi dovrebbero essere risolti per primi. Uno dei motivi è la concorrenza che è come colpire - e mantenere - le interruzioni se ogni SQL accede ogni volta a tutti i dati in una tabella.

Assicurarsi che nessun SQL acceda a più righe del necessario. Questo è il modo più efficace per mantenere buone le prestazioni. Un normale database sa come gestire io e fa qualche forma di memorizzazione nella cache dei dati più usati.

Se l'applicazione ha già ridotto a icona tutti gli accessi possibili e si utilizzano già i sistemi di dischi più veloci, considerare l'utilizzo di array di memoria flash reali. Possono aumentare le prestazioni di un altro livello.

Si prega di fare riferimento a questi post:

• Quanto può raggiungere un database MySQL prima che le prestazioni inizino a peggiorare
• Perché MySQL potrebbe essere lento con tabelle di grandi dimensioni?

Suggerimenti per rendere i tuoi dati il ​​più piccoli possibile:

Progetta i tuoi tavoli per ridurre al minimo il loro spazio sul disco. Ciò può comportare enormi miglioramenti riducendo la quantità di dati scritti e letti dal disco. Le tabelle più piccole normalmente richiedono meno memoria principale mentre i loro contenuti vengono elaborati attivamente durante l'esecuzione della query. Qualsiasi riduzione dello spazio per i dati della tabella comporta anche indici più piccoli che possono essere elaborati più rapidamente.

MySQL supporta molti diversi motori di archiviazione (tipi di tabella) e formati di riga. Per ogni tabella, puoi decidere quale metodo di archiviazione e indicizzazione utilizzare. La scelta del formato corretto per la tua applicazione può darti un grande vantaggio in termini di prestazioni.

È possibile ottenere prestazioni migliori per una tabella e ridurre al minimo lo spazio di archiviazione utilizzando le tecniche elencate qui: - Utilizzare i tipi di dati più efficienti (più piccoli) possibili. MySQL ha molti tipi specializzati che risparmiano spazio su disco e memoria. Ad esempio, utilizzare i tipi interi più piccoli, se possibile, per ottenere tabelle più piccole. MEDIUMINT è spesso una scelta migliore di INT perché una colonna MEDIUMINT utilizza il 25% di spazio in meno.

• Dichiarare le colonne NON NULL, se possibile. Rende tutto più veloce e risparmi un bit per colonna. Se hai davvero bisogno di NULL nella tua applicazione, dovresti sicuramente usarlo. Evita semplicemente di averlo su tutte le colonne per impostazione predefinita.

• Per le tabelle MyISAM, se non si dispone di colonne di lunghezza variabile (colonne VARCHAR, TEXT o BLOB), viene utilizzato un formato di riga di dimensioni fisse.

• Le tabelle InnoDB utilizzano un formato di archiviazione compatto. Nelle versioni di MySQL precedenti alla 5.0.3, le righe di InnoDB contengono alcune informazioni ridondanti, come il numero di colonne e la lunghezza di ciascuna colonna, anche per colonne di dimensioni fisse. Per impostazione predefinita, le tabelle vengono create nel formato compatto (ROW_FORMAT = COMPACT). La presenza del formato di riga compatto riduce lo spazio di archiviazione delle righe di circa il 20% a costo di aumentare l'utilizzo della CPU per alcune operazioni. Se il carico di lavoro è tipico, limitato dalle percentuali di hit della cache e dalla velocità del disco, è probabile che sia più veloce. Se si tratta di un caso raro limitato dalla velocità della CPU, potrebbe essere più lento.

Il formato compatto InnoDB cambia anche il modo in cui sono archiviate le colonne CHAR contenenti dati UTF-8. Con ROW_FORMAT = REDUNDANT, un UTF-8 CHAR (N) occupa 3 × N byte, dato che la lunghezza massima di un carattere codificato UTF-8 è di tre byte. Molte lingue possono essere scritte principalmente utilizzando caratteri UTF-8 a byte singolo, quindi una lunghezza di archiviazione fissa spesso spreca spazio. Con ROW_FORMAT = formato COMPACT, InnoDB alloca una quantità variabile di memoria nell'intervallo da N a 3 × N byte per queste colonne, eliminando gli spazi finali, se necessario. La lunghezza minima di archiviazione viene mantenuta come N byte per facilitare gli aggiornamenti sul posto nei casi tipici.

• L'indice primario di una tabella dovrebbe essere il più breve possibile. Ciò rende l'identificazione di ogni riga semplice ed efficiente

• Crea solo gli indici di cui hai veramente bisogno. Gli indici sono utili per il recupero ma non validi quando è necessario archiviare rapidamente i dati. Se accedi a una tabella principalmente cercando una combinazione di colonne, crea un indice su di esse. La prima parte dell'indice dovrebbe essere la colonna più utilizzata. Se si utilizzano sempre più colonne quando si seleziona dalla tabella, la prima colonna dell'indice dovrebbe essere quella con il maggior numero di duplicati per ottenere una migliore compressione dell'indice.

• In alcune circostanze, può essere utile dividere in due una tabella che viene scansionata molto spesso. Ciò è particolarmente vero se si tratta di una tabella di formato dinamico ed è possibile utilizzare una tabella di formato statico più piccola che può essere utilizzata per trovare le righe pertinenti durante la scansione della tabella.