IOPS vs. throughput: scegliere le metriche di prestazioni giuste per il tuo database

By Mirko Peters · 2026-08-11 · Updated 2026-08-26

Quando architetti e amministratori di database si propongono di progettare un'infrastruttura ad alte prestazioni per carichi di lavoro intensivi come SQL Server, si trovano spesso sommersi da una raffica di acronimi tecnici e specifiche di storage. Tra le metriche più critiche, ma anche più spesso fraintese, ci sono IOPS e throughput. Scegliere la metrica sbagliata al momento del provisioning dell

Automatically translated with AI from the original post. Read the English original

Quando architetti e amministratori di database si propongono di progettare un'infrastruttura ad alte prestazioni per carichi di lavoro intensivi come SQL Server, si trovano spesso sommersi da una raffica di acronimi tecnici e specifiche di storage. Tra le metriche più critiche, ma anche più spesso fraintese, ci sono IOPS e throughput. Scegliere la metrica sbagliata al momento del provisioning dello storage può portare a query lente, sistemi che si bloccano e budget sprecati. Capire come il tuo database legge e scrive effettivamente i dati è il primo passo per costruire un'architettura resiliente.

In questo post analizzeremo le differenze fondamentali tra IOPS e throughput, vedremo come si applicano ai carichi di lavoro intensivi dei database, esamineremo i colli di bottiglia architetturali più comuni, come i limiti delle macchine virtuali, e capiremo come i modelli di storage condiviso cambiano le regole del gioco negli ambienti cloud moderni.

Introduzione alle metriche di prestazioni del database

Le prestazioni dello storage non si misurano con un'unica formula valida per tutti. Quando si guarda allo storage cloud o all'hardware SAN tradizionale, i fornitori snocciolano cifre impressionanti sulla velocità con cui i dati possono spostarsi e sul numero di operazioni che un disco può elaborare. Tuttavia, un motore di database si comporta in modo completamente diverso da un servizio di streaming video o da un grande file server. Mentre un server video deve far scorrere grandi flussi continui di dati lungo una pipeline, un database passa il suo tempo a cercare righe specifiche, aggiornare i log delle transazioni e mettere in cache le pagine in memoria.

Per progettare un ambiente che non ceda sotto pressione, bisogna prima di tutto capire le caratteristiche distintive dei propri carichi di lavoro. Si parte da un'analisi approfondita dei due pilastri delle prestazioni dello storage: Input/Output Operations Per Second (IOPS) e Megabyte al secondo (throughput).

Definire gli IOPS: perché i database si basano su letture e scritture di piccole dimensioni

IOPS sta per Input and Output Operations Per Second (operazioni di input e output al secondo). È una misura di quante singole richieste di storage un dispositivo può gestire in un solo secondo. Per le piattaforme di database intensive come SQL Server, gli IOPS sono di solito la metrica regina.

I database sono per natura transazionali. Quando un utente accede a un'applicazione, il database di norma non legge né scrive in un colpo solo un file enorme di diversi gigabyte. Esegue invece migliaia di operazioni minuscole e mirate. Può leggere una pagina dati da 8 KB per recuperare un profilo utente, scrivere qualche centinaio di byte in un log delle transazioni o aggiornare un indice. Proprio perché queste operazioni sono così piccole, la capacità del sottosistema di storage di elaborare un volume elevato di comandi individuali, ovvero la sua capacità in IOPS, diventa il fattore principale delle prestazioni. Se il database richiede 10.000 IOPS per reggere le transazioni degli utenti, ma il disco di storage ne può erogare solo 3.000, le query si accoderanno, i blocchi si propagheranno a cascata e i tempi di risposta delle applicazioni crolleranno.

Definire il throughput: quando conta soprattutto la larghezza di banda

Mentre gli IOPS misurano il *numero* di operazioni, il throughput misura il *volume* di dati spostati in un determinato periodo di tempo, espresso di solito in megabyte al secondo (MB/s). Immagina gli IOPS come il numero di auto che percorrono un'autostrada e il throughput come il peso complessivo del carico che trasportano.

Ci sono scenari in cui il throughput conta molto più degli IOPS. Pensa a un backup notturno del database, a un'importazione massiva in un data warehouse o a query analitiche che scandiscono milioni di righe di una tabella. Questi compiti non si preoccupano tanto di quante richieste individuali vengano elaborate al secondo; interessa loro quanto velocemente possa essere acquisito o esportato un flusso continuo di dati pesanti. Se provi a eseguire una migrazione massiva di dati su uno storage con IOPS elevati ma limiti di throughput bassi, scoprirai che la migrazione richiede ore in più del previsto, perché la pipeline dei dati semplicemente non è abbastanza larga.

Associare i carichi di lavoro delle applicazioni alle configurazioni di storage

Ogni applicazione della tua azienda ha un profilo di storage unico. Progettare con successo l'ambiente significa associare questi specifici pattern di lettura e scrittura alla configurazione di storage giusta. Ad esempio, un database per l'elaborazione delle transazioni (OLTP) richiede capacità IOPS elevate per gestire richieste utente concorrenti senza picchi di latenza. Al contrario, un data lake o un server di reporting può richiedere un throughput elevato per macinare query analitiche.

Il problema si presenta quando un ambiente ospita più carichi di lavoro con schemi in conflitto. Un database SQL potrebbe raggiungere il picco durante il reporting finanziario di fine mese, un server di reporting potrebbe registrare un'impennata ogni mattina alle 8:00 e un sistema di backup potrebbe saturare la rete di traffico durante la notte. In passato gli amministratori predisponevano dischi separati per ogni singolo picco, con un sovradimensionamento enorme e risorse inattive.

Il collo di bottiglia della macchina virtuale: oltre i dischi

Anche se calcoli con cura gli IOPS e il throughput richiesti dal tuo database e predisponi i dischi più veloci disponibili, puoi comunque imbatterti in gravi limiti di prestazioni. Il colpevole spesso non è il supporto di archiviazione in sé, ma la macchina virtuale a cui è collegato.

Le macchine virtuali di Azure, per esempio, impongono limiti rigidi su IOPS e throughput totali del disco, in base alle dimensioni e al livello della VM selezionata. Puoi collegare dischi ultraveloci di classe enterprise a una VM di dimensioni modeste, ma la VM limiterà il traffico di archiviazione alla propria soglia massima. Il sistema di archiviazione potrebbe erogare 20.000 IOPS, ma se il percorso della macchina virtuale ti limita a 10.000 IOPS, quello è il tuo tetto. Verifica sempre sia le specifiche dei dischi sia il dimensionamento del calcolo, per assicurarti che il percorso tra i due sia abbastanza ampio da gestire i carichi di picco.

Come i pool di archiviazione condivisi cambiano la pianificazione delle prestazioni

Per spezzare il ciclo di predisposizione di dischi isolati e sovradimensionati per ogni singolo carico di lavoro, le moderne architetture cloud guardano ai pool di archiviazione condivisi, che ricordano le tradizionali Storage Area Network (SAN). Invece di rinchiudere le prestazioni in contenitori separati e rigidi, un modello condiviso raggruppa insieme capacità e IOPS.

Negli ambienti che utilizzano risorse aggregate, le metriche delle prestazioni scalano con la capacità. Per esempio, in Azure Elastic SAN, ogni 1 TiB di capacità di base contribuisce con una quantità specifica di prestazioni — ad esempio 5.000 IOPS e 200 MB al secondo di throughput — a un pool centrale. Questo pool condiviso consente ai diversi volumi di attingere a un budget di prestazioni comune. Se il tuo database finanziario ha bisogno di un afflusso di IOPS durante un intenso ciclo di reporting mentre il sistema del magazzino è tranquillo, queste risorse possono adattarsi dinamicamente per supportare il carico di lavoro attivo.

Evitare i punti critici: bilanciare i picchi di domanda e i limiti condivisi

Sebbene i pool di archiviazione condivisi offrano una flessibilità e un risparmio di costi notevoli, non sono una soluzione miracolosa per prestazioni illimitate. Mettere in comune le risorse significa affidarsi alla probabilità statistica che non tutti i database raggiungano il picco assoluto di domanda esattamente nello stesso istante.

Se più carichi di lavoro intensivi raggiungono il picco contemporaneamente e la loro domanda combinata supera i limiti del pool condiviso, si verificherà il throttling. Il throttling introduce latenza, rallenta le query e può causare timeout a cascata delle applicazioni. Gli amministratori di database e i pianificatori dell'infrastruttura devono analizzare attentamente le metriche storiche, comprendere il loro utilizzo di picco concorrente e assicurarsi che il pool di archiviazione condiviso sia dimensionato con margine sufficiente per assorbire picchi di domanda sovrapposti senza andare in affanno.

Conclusione: scegliere le metriche giuste per il tuo database

Padroneggiare l'equilibrio tra IOPS e throughput è essenziale per chiunque gestisca carichi di lavoro intensivi su database nel cloud. Diagnosticando con precisione se le tue applicazioni sono a corto di operazioni piccole e rapide oppure di larghezza di banda massiccia per i dati, puoi evitare costosi colli di bottiglia nelle prestazioni. Inoltre, adottare paradigmi di archiviazione moderni come i pool condivisi può migliorare notevolmente l'efficienza, facendo sì che la tua infrastruttura scali in modo intelligente insieme alla crescita del business. Per approfondire come le moderne architetture di archiviazione cloud risolvono queste sfide di scalabilità e prestazioni, non perderti il podcast correlato: Azure Elastic SAN — Simply Explained.