Oggi stavo navigando in un libro sull'ottimizzazione di SQL Server e sembrava che una certa quantità di idee fosse basata su un modello lineare di archiviazione. Dato che gli SSD hanno un modello di storage completamente diverso, cambiano in qualche modo il gioco rispetto a come si pensa all'ottimizzazione o all'ottimizzazione del database?
Sì, cambiano il gioco. Ottimizzazioni basate sulle caratteristiche dei dischi magnetici rotanti (come tempo di ricerca e ritardo di rotazione ) potrebbe non essere rilevante sulle unità SSD. Un recente articolo * pubblicato su FITME 2010 presenta un nuovo algoritmo di ottimizzazione delle query basato sulle caratteristiche degli SSD.
Tuttavia, queste modifiche saranno probabilmente modifiche di basso livello (ad esempio algoritmi di archiviazione e recupero) che possono essere implementate in modo efficace dagli sviluppatori di database. Probabilmente non interesseranno molto gli utenti del database.
Gli SSD sono performanti: non devono cercare e il throughput è sfolgorante. La maggior parte dei software che gestiscono i dischi, nella misura in cui sono ottimizzati, sono ottimizzati per ridurre il numero di ricerche sincrone. In tal modo, introducono host di complessità. Con l'avvento di scritture veloci e senza seek per lo storage persistente, i nuovi sistemi di archiviazione dati non richiedono più tali complessità.
Gli SSD attualmente hanno alti tassi di errore. Il tuo SSD fallirà. I tuoi SSD falliranno a un ritmo molto più alto dei dischi magnetici. È necessario aggirare questo problema con repliche, backup, ecc. Questo introduce il proprio insieme di complessità.
La riduzione complessiva del prezzo di stoccaggio ha effetti molto più profondi.
Prima che avessimo l'SQL, disponevamo di database gerarchici e di rete ottimizzati in modo eccellente, in cui gli amministratori di database dovevano pianificare attentamente il posizionamento di tracce e cilindri dei dati.
I database SQL sono molto meno efficienti. Ma ora che i dischi sono economici, enormi e veloci, ci importa a malapena.
I database NoSQL ("Document") possono essere un po 'meno efficienti di SQL perché non esiste la stessa capacità di mappatura da logica a fisica tra lo schema logico SQL e lo schema fisico sottostante di file o tablespace o qualsiasi altra cosa. E a noi importa a malapena.
È probabile che i miglioramenti delle prestazioni dell'SSD vadano persi nelle modifiche causate dall'utilizzo dei database NoSQL nel modo in cui progettiamo i sistemi in generale.
Il problema principale con l'ottimizzazione di qualsiasi cosa per SSD ha a che fare con il modo in cui scrivono i dati. Un disco rigido tradizionale in genere memorizza i dati in piccoli settori di circa 512 byte e può effettivamente manipolare i settori direttamente o anche al di sotto di tale livello.
Gli SSD hanno alcuni svantaggi per quanto riguarda le scritture:
Uno scenario da incubo tipico, denominato Scrivi amplificazione , è quando vuoi scrivere un singolo byte in una posizione su disco con alcuni blocchi già in uso. Per scrivere lì, è necessario prima copiare l'intera pagina da 256 KB in memoria, cancellare l'intero blocco, modificare il singolo byte nella pagina, quindi riscrivere l'intera pagina modificata da 256 KB. Quindi, per scrivere un singolo byte, c'è stato circa mezzo megabyte di "traffico"!
Esistono molte ottimizzazioni per questo problema implementato a livello di SSD, controller e persino a livello di sistema operativo, ma indubbiamente i DBMS possono trarre beneficio personalizzando queste ottimizzazioni per il loro funzionamento specifico.
Tuttavia, questo non è qualcosa a cui gli utenti del database (come in, usando un database nella loro applicazione) devono riflettere, poiché sarà altamente dipendente dalle decisioni di progettazione / implementazione a livello di DBMS.
Da quanto ricavato dal ServerFault blog, i server di database devono avere un hardware robusto. Il server di database dei siti di scambio stack esegue SSD (vedi link ) e immagino che la query l'ottimizzazione è ancora molto necessaria. CPU e memoria sono influenzati dalle query del database e dall'IO.
Tuttavia, le prestazioni del database dipendono molto da I / O, quindi gli SSD sarebbero sicuramente di aiuto.
Sì, per i motivi indicati da tutti.
Stavo ascoltando un podcast che diceva che grossi pezzi di RDBMS come Oracle, SQL Server etc inizieranno a essere "esclusi" se riescono a risolvere correttamente la separazione. Rileva se è un'unità SSD e ottimizza di conseguenza.
C'è un sacco di codice aggiuntivo incorporato nella memorizzazione nella cache e nella scrittura di dati che semplicemente non è più necessario.
Ancora più interessante è il RAMSAN e le sue varianti. Fondamentalmente un'unità disco rigido composta da chip RAM con un X ora integrato e la possibilità di scrivere in background su un disco rigido a lungo termine.
Leggi altre domande sui tag sql database-design optimization ssd