L'avvento dell'SSD ha implicazioni per l'ottimizzazione del database?

Oggi stavo sfogliando un libro sull'ottimizzazione di SQL Server e sembrava che una certa quantità di idee fosse basata su un modello lineare di archiviazione. Poiché gli SSD hanno un modello di archiviazione completamente diverso, cambiano in qualche modo il gioco riguardo a come si pensa all'ottimizzazione o all'ottimizzazione del database?

Sì, cambiano il gioco. Le ottimizzazioni basate sulle caratteristiche dei dischi magnetici rotanti (come il tempo di ricerca e il ritardo di rotazione ) potrebbero non essere rilevanti 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 agli algoritmi di archiviazione e recupero) che possono essere implementate in modo efficace dagli sviluppatori di database. Probabilmente non influenzeranno molto gli utenti del database.

^* IEEE Xplore: ottimizzazione delle query di archiviazione orientata alle colonne per database basati su flash

Prestazione

Gli SSD sono performanti: non devono cercare e il throughput è ardente. La maggior parte dei software che si occupano di 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 ricerca nella memoria persistente, i nuovi sistemi di memorizzazione dei dati non richiederanno più tali complessità.

durabilità

Gli SSD hanno attualmente alti tassi di fallimento. Il tuo SSD fallirà.I tuoi SSD falliranno a una velocità molto più alta rispetto ai dischi magnetici. È necessario aggirare questo problema con la replica, i backup, ecc. Questo introduce una propria serie di complessità.

La riduzione complessiva del prezzo di archiviazione ha effetti molto più profondi.

Prima di disporre di SQL, disponevamo di database gerarchici e di rete super-ottimizzati in cui i DBA dovevano pianificare con cura il posizionamento dei dati in tracce e cilindri.

I database SQL sono molto meno efficienti. Ma ora che i dischi sono economici, enormi e veloci, a malapena ci preoccupiamo.

I database NoSQL ("Document") possono essere in qualche modo meno efficienti di SQL perché non esiste la stessa capacità di mappatura logico-fisica tra lo schema logico SQL e lo schema fisico sottostante di file o tablespace o altro. E a malapena ci preoccupiamo.

È probabile che i miglioramenti delle prestazioni dell'SSD andranno persi nelle modifiche causate dall'uso dei database NoSQL nel modo in cui progettiamo i sistemi in generale.

Il problema principale con l'ottimizzazione di qualsiasi cosa per gli 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 addirittura al di sotto di tale livello.

Gli SSD presentano alcuni svantaggi per quanto riguarda le scritture:

• Una dimensione di scrittura minima del blocco di circa 4-8 KB.
• Le scritture possono essere eseguite solo su una pagina intera, in genere 256 KB.
• Solo i blocchi vuoti possono essere scritti su.

Uno scenario tipico da incubo, chiamato amplificazione Write , è quando si desidera scrivere un singolo byte in una posizione sul disco che ha già alcuni blocchi in uso. Per scrivere lì, devi prima copiare l'intera pagina da 256 KB in memoria, cancellare l'intero blocco, cambiare il singolo byte nella pagina, quindi riscrivere l'intera pagina da 256 KB modificata. Quindi, per scrivere un singolo byte, c'è stato circa mezzo megabyte di "traffico"!

Esistono molte ottimizzazioni per questo problema implementate a livello di SSD, controller e persino a livello di sistema operativo, ma senza dubbio i DBMS possono trarre vantaggio dall'adattamento di queste ottimizzazioni ai loro specifici meccanismi.

Questo, tuttavia, non è qualcosa a cui gli utenti del database (come in, utilizzando un database nella loro applicazione) devono pensare, poiché dipenderà fortemente dalle decisioni di progettazione / implementazione a livello di DBMS.

Da quello che raccolgo dal blog ServerFault , i server di database devono avere hardware corpulento. Il server di database dei siti di scambio di stack esegue SSD (vedere http://blog.serverfault.com/post/our-storage-decision/ ) e immagino che l'ottimizzazione delle query sia ancora molto necessaria. CPU e memoria sono influenzate dalle query del database e da IO.

Tuttavia, le prestazioni del database dipendono molto dall'IO, quindi gli SSD sarebbero sicuramente di aiuto.

Sì, per i motivi che tutti hanno affermato.

Stavo ascoltando un podcast che diceva che grandi pezzi di RDBMS come Oracle, SQL Server ecc. Inizieranno ad essere "opzionati" se riescono a risolvere correttamente la separazione. Rileva se si tratta di un'unità SSD e ottimizza di conseguenza.

C'è un sacco di codice extra integrato 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 disco rigido fatto di chip RAM con un UPS X ora incorporato e la possibilità di scrivere in background su memoria HDD a lungo termine.