Database in scala con dischi rigidi SSD economici


25

Spero che molti di voi stiano lavorando con siti Web basati su database ad alto traffico e che i problemi di scalabilità siano maggiori nel database. Ho notato un paio di cose ultimamente:

  1. I database più grandi richiedono un team di DBA per ridimensionare. Lottano costantemente con le limitazioni dei dischi rigidi e finiscono con soluzioni molto costose (SAN o RAID di grandi dimensioni, finestre di manutenzione frequente per la deframmentazione e il ripartizionamento, ecc.). troppo ripido per me :)

  2. Infine, abbiamo ottenuto diverse aziende come Intel, Samsung, FusionIO, ecc. Che hanno appena iniziato a vendere dischi rigidi SSD estremamente veloci ma convenienti basati sulla tecnologia SLC Flash. Queste unità sono 100 volte più veloci in lettura / scrittura casuale rispetto ai migliori dischi rigidi rotanti sul mercato (fino a 50.000 scritture casuali al secondo). Il loro tempo di ricerca è praticamente zero, quindi il costo dell'I / O casuale è lo stesso dell'I / O sequenziale, il che è fantastico per i database. Queste unità SSD costano circa $ 10- $ 20 per gigabyte e sono relativamente piccole (64 GB).

Quindi, sembra esserci un'opportunità per evitare i costi ENORMI del ridimensionamento dei database nel modo tradizionale semplicemente costruendo un array RAID 5 abbastanza grande di unità SSD (che costerebbe solo poche migliaia di dollari). Quindi non ci importa se il file di database è frammentato e possiamo permetterci 100 volte più scritture su disco al secondo senza dover distribuire il database su 100 mandrini. .

Qualcun altro è interessato a questo? Ho testato alcune unità SSD e posso condividere i miei risultati. Se qualcuno su questo sito ha già risolto il collo di bottiglia degli I / O con gli SSD, mi piacerebbe sentire le tue storie di guerra!

PS. So che ci sono molte soluzioni costose che aiutano con la scalabilità, ad esempio le SAN basate su RAM collaudate nel tempo. Voglio essere chiaro che anche $ 50K sono troppo costosi per il mio progetto. Devo trovare una soluzione che non costa più di $ 10.000 e non richiede molto tempo per essere implementata.


Dave, NXC e Burly,

Grazie per le tue risposte! Vorrei chiarire che la parola "economico" è molto importante nella mia situazione. Quindi, devo usare server Dell economici ($ 4K 2950 che hanno solo 8 banchi di memoria). Ho già installato 32 GB di RAM, quindi non posso continuare a scalare in questo modo. Inoltre, l'aggiunta di RAM non ti salva dai colli di bottiglia del disco WRITE, che è il mio problema principale in questo momento.

Ero preoccupato per la durata degli SSD, ma dopo aver letto i moderni algoritmi di livellamento dell'usura sono abbastanza sicuro che queste unità dureranno abbastanza a lungo. Il mio database scrive 300 GB al giorno e nel 2009 ha previsto di superare 1 TB al giorno. Gli SSD Enterprise sono progettati per gestire circa 10 TB di scritture al giorno per più anni.

Non sarei d'accordo con il punto di Burly sul fatto che ci vuole troppo lavoro per migrare da SAS a SSD. Il mio database è un mirror sincrono, quindi posso aggiornare un lato del mirror, quindi guardarlo per alcuni mesi e se si rompe posso eseguire il failover sul secondo server che ha ancora i vecchi buoni dischi rigidi SAS ...


2
A proposito, mentre affermi come il miglioramento delle prestazioni potrebbe potenzialmente ridurre i costi dell'hardware, non esprimi chiaramente in che modo gli SSD ridurrebbero i tuoi maggiori costi - manodopera. Suppongo che probabilmente si sta arrivando al fatto che una riduzione delle dimensioni dell'installazione può ridurre le richieste di personale
Burly,

2
Il mio database è stato felicemente in produzione per 3 anni senza DBA o consulenti a tempo pieno. Quindi il carico è aumentato al punto in cui ci imbattiamo nei colli di bottiglia degli I / O. Quindi, potrei dover pagare un sacco di soldi ai DBA per il partizionamento e la deframmentazione del database. O semplicemente ottenere alcuni SSD economici.
Dennis Kashkin,

Ho aggiornato la mia risposta per discutere i vincoli di costo aggiunti. A seconda dello spazio, delle dimensioni, delle prestazioni, della manutenzione e dei requisiti di modifica del proprio DB, gli SSD possono sicuramente offrire una soluzione economica. La progettazione della soluzione e l'analisi dei costi vanno oltre il nostro scopo qui. Buona fortuna!
Burly,

Hai bevuto troppo koolaid, SSD è, nella migliore delle ipotesi, 1,5 volte più veloce per la lettura di un'unità RAID, ma le scritture sono più lente dei dischi magnetici. Un SANS basato su fibra con un RAID ad alta velocità distruggerà qualsiasi SSD, non importa quanto sia buono.
TravisO,

Volevo solo condividere: abbiamo eseguito un database da 400 GB su SSD per 5 mesi. Questo database riceve molte attività di scrittura (fino a 1200 transazioni al secondo). Finora non abbiamo riscontrato problemi e le prestazioni sono state notevolmente migliori rispetto ai RAID10 con unità SAS a 15K rpm. I dischi rimangono inattivi al 96%. Quindi, considerando che ora gli SSD stanno diventando incredibilmente economici ($ 600 per unità Intel da 160 GB), direi che questo è un modo migliore per ridimensionare l'I / O rispetto alle SAN.
Dennis Kashkin,

Risposte:


20

Potenziali problemi

Al momento ho un paio di problemi con l'utilizzo di SSD per i database di produzione

  • La maggior parte delle transazioni di database sulla maggior parte dei siti Web sono letture e non scritture. Come ha detto Dave Markle, massimizzi prima queste prestazioni con la RAM.
  • Gli SSD sono nuovi per i mercati mainstream e aziendali e nessun amministratore degno di nota sposterà un database di produzione che attualmente richiede dischi U320 da 15K RPM in RAID5 che comunicano tramite fibrechannel a una tecnologia non dimostrata.
  • Il costo della ricerca e dei test per passare a questa nuova tecnologia, esaminarla nel proprio ambiente, aggiornare le procedure operative e così via è un costo iniziale maggiore, sia in termini di tempo che di denaro, che la maggior parte dei negozi deve risparmiare.

Benefici proposti

Detto questo, ci sono un certo numero di elementi, almeno sulla carta, a favore degli SSD in futuro:

  • Consumo energetico inferiore rispetto a un HDD
  • Generazione di calore molto più bassa
  • Prestazioni più elevate per watt rispetto a un HDD
  • Produttività molto più elevata
  • Latenza molto più bassa
  • La maggior parte degli SSD di generazione attuale ha un ordine di milioni di cicli di resistenza in scrittura, quindi la resistenza in scrittura non è un problema come una volta. Vedi un articolo un po 'datato qui

Pertanto, per un determinato benchmark delle prestazioni, quando si tiene conto del costo totale di proprietà, compresi i costi di alimentazione diretta e di raffreddamento indiretto, gli SSD potrebbero diventare molto interessanti. Inoltre, a seconda dei dettagli del proprio ambiente, la riduzione del numero di dispositivi richiesti per un determinato livello di prestazioni potrebbe anche comportare una riduzione delle esigenze di personale, riducendo i costi di manodopera.

Costo e prestazioni

Hai aggiunto che hai un vincolo di costo inferiore a $ 50.000 USD e vuoi davvero mantenerlo inferiore a $ 10.000. In un commento hai anche affermato che puoi ottenere alcuni SSD "economici", eludendo che gli SSD saranno più economici dei DBA o dei consulenti. Questo può essere vero a seconda del numero di ore necessarie per un DBA e se si tratta di un costo ricorrente o meno. Non posso fare l'analisi dei costi per te.

Tuttavia, una cosa di cui devi stare molto attento è il tipo di SSD che ottieni. Non tutti gli SSD sono creati uguali. Nel complesso, gli SSD "economici" che si vedono in vendita nei $ 200-400 dollari (2008/11/20) sono destinati ad ambienti a bassa potenza / calore come i laptop. Queste unità hanno in realtà livelli di prestazioni inferiori rispetto a un HDD da 10 K o 15 K RPM, specialmente per le scritture. Le unità di livello aziendale con le prestazioni killer di cui parli, come la serie Mtron Pro, sono piuttosto costose. Attualmente sono in giro:

  • 400 USD per 16 GB
  • 900 USD per 32 GB
  • 1400 USD per 64 GB
  • 3200 USD per 128 GB

A seconda dei requisiti di spazio, prestazioni e ridondanza, potresti facilmente far saltare il tuo budget.

Ad esempio, se i requisiti richiesti richiedessero un totale di 128 GB di spazio di archiviazione disponibile, RAID 0 + 1/10 o RAID 5 con 1 hotspare sarebbero ~ $ 5600

Se avessi bisogno di una TB di spazio di archiviazione disponibile, tuttavia, RAID 0 + 1/10 sarebbe ~ $ 51K e RAID 5 con 2 hotspares sarebbe ~ $ 32K.

Grande immagine

Detto questo, l'installazione, la configurazione e la manutenzione di un ampio database di produzione richiedono un individuo altamente qualificato. I dati all'interno del DB e i servizi forniti da tali dati hanno un valore estremamente elevato per le aziende con questo livello di requisiti prestazionali. Inoltre, ci sono molte cose che non possono essere risolte lanciando hardware al problema. Un DBMS configurato in modo errato, uno schema di database scadente o una strategia di indicizzazione possono / rovinare / le prestazioni di un DB. Basta guardare i problemi che Stackoverflow ha riscontrato nella loro migrazione a SQL Server 2008 qui e qui. Il fatto è che un database è un'applicazione faticosa non solo su disco ma anche su RAM e CPU. Bilanciare il problema delle prestazioni multi-variabile con integrità dei dati, sicurezza, ridondanza e backup è un po 'complicato.

In sintesi, mentre penso che tutti i miglioramenti apportati alla tecnologia hardware e software siano accolti favorevolmente dalla comunità, l'amministrazione di database su larga scala - come lo sviluppo del software - è un problema difficile e continuerà a richiedere lavoratori qualificati. Un dato miglioramento potrebbe non raccogliere i costi di riduzione del lavoro che tu o un'azienda potresti sperare.

Un buon punto di partenza per alcune ricerche potrebbe essere il sito / blog di Brent Ozar qui . Potresti riconoscere il suo nome: è lui che ha aiutato l'equipaggio dello stackoverflow con i loro problemi di prestazioni di MS SQL Server 2008. Il suo blog e le risorse che collega per offrire un po 'di ampiezza e profondità.

Aggiornare

Stackoverflow stesso sta seguendo il percorso SSD basato sul consumatore per la sua memorizzazione. Leggi qui: http://blog.serverfault.com/post/our-storage-decision/

Riferimenti


Risposta eccellente.
NotMe

Hai speso troppo tempo su questo: P
TravisO,

Spiegazioni fantastiche. Ritagliato in legno per tutti. Bel lavoro!
BerggreenDK,

4

Se disponi di un sito a traffico molto elevato che può beneficiare di un SSD per migliorare le prestazioni di scrittura, probabilmente avrai un problema con la durata dell'SSD, quindi non sono ancora venduto su di loro per quello.

Con questo in mente, cosa fare con i database che hanno alti livelli di letture? La risposta è semplice: inceppare il server con tutta la RAM possibile. Scoprirai che le tabelle più calde sono quasi sempre mantenute nella cache RAM e che qualsiasi grande hit su disco sarà probabilmente dovuto a una grande tabella o alla scansione dell'indice, che spesso può essere ottimizzata con una corretta indicizzazione.


Vorrei rivisitare il tuo commento sulla preoccupazione della durata di vita dell'SSD. In termini di MTBF, l'SSD ha una valutazione molto più alta di un HDD. In termini di durata del ciclo di scrittura - in precedenza un problema, l'attuale generazione è> 1 milione di cicli di scrittura, il che rende questo un problema, soprattutto nelle configurazioni RAID.
Burly,

(Fuori dai personaggi) ... Non è che non dovresti preoccuparti della vita di un SSD, è solo che le attuali valutazioni tecniche suggeriscono che gli SSD sono uguali o superiori a una controparte dell'HDD. Il fatto che gli SSD non abbiano decenni di esperienza nella produzione significa che non sono provati.
Burly,

Gli SSD sono più lenti nella scrittura rispetto agli
HD

Gli SSD sono generalmente notevolmente più veloci nelle scritture casuali, in particolare le scritture casuali 4K. Possono essere più lenti per le scritture sequenziali, ma ciò non è necessariamente importante per i server di database.
ChrisInEdmonton,

1

Ho lavorato come DBA per oltre 5 anni e pensare ai modi per migliorare le prestazioni del DB è sempre alla base della mia. Ho osservato lo spazio SSD e penso che stiano diventando sempre più un'opzione praticabile.

Controllalo;

http://i.gizmodo.com/5166798/24-solid-state-drives-open-all-of-microsoft-office-in-5-seconds

Esiste anche un nuovo prodotto prodotto da Acard chiamato ANS-9010 che è una versione migliorata di GC-Ramdisc che consente di utilizzare ram DDR2 per creare un'unità SATA (fino a 64 gig) utilizzando stick DDR2 con un valore teorico di 400 MB / s massimo.

http://techreport.com/articles.x/16255/3

^^ Ma l'altra cosa utile in quell'articolo è che confronta l'ANS-9010 con tutti i giocatori sul mercato SSD e si scopre che Intel ha SSD x25-E da 64 GB che è praticamente paragonabile ad avere un ramdisk hardware.

La cosa che mi preoccuperebbe dell'SSD è usurarli con tutto lo stress che un grande DB li avrebbe sottoposti e quindi dovresti usare il raid per rispecchiare le unità, il che significa che stai pagando il doppio;

E il rovescio della medaglia con il ramdisk hardware è che la batteria, nel caso di un'interruzione di corrente, la alimenta solo per così tanto tempo, quindi dovresti trovare un modo elegante per eseguirne il backup. Credo che tu possa anche acquistare una spina di alimentazione per loro, ma che si basa ancora sul tuo UPS.

Ti suggerisco di utilizzare il disco RAM hardware per il DB temporaneo e il file di scambio di Windows e di posizionare il database sull'Intel X25-E Extreme (circa 600 USD per 64 gig).

Ad ogni modo urlerebbe e renderebbe tutti noiosi molto gelosi.

(Considera anche di usare un altro ANS-9010 per ospitare il sito Web)

Saluti, Dave


1

Abbiamo appena messo insieme un server w2k3 r2 64 bit Sql 2008 su doppio mirror ibrido Seagate Momentus XT da 2,5 pollici - 1/4 di corsa per sistema operativo e 1/4 di corsa per DB. Quindi usavamo 125 GB per OS e 125 GB per DB. stavano ottenendo letture seq da 1500 MB / sa 1900 MB / s. Su un Intel i7 2600K 3,4 Ghz 8 GB


0

Ci sono prodotti sul mercato come questo che fanno questo genere di cose. Inoltre, come dice l'altro poster, l'aggiunta di RAM aggiuntiva al server DB ti darà migliori percentuali di accessi alla cache, riducendo il traffico su disco.

I server Opteron a 8 socket come un Sun X4600 ti permetteranno di inserire fino a 256 GB di RAM a prezzi ancora più economici di un grande team DBA. Puoi anche prendere in considerazione l'utilizzo di file flat anziché di un DBMS (come ha fatto questa azienda ), che ti offrirà prestazioni migliori rispetto a un DBMS. In questo caso, una SAN ti fornirà un certo grado di integrità dei dati. Tuttavia, dovrai progettare attentamente la tua strategia di accesso ai dati per evitare di metterti nei guai. Apparentemente alcuni abiti dot-com di grande volume lo fanno. È considerevolmente più efficiente di un DBMS, consentendo all'hardware abbastanza pedonale di gestire grandi carichi ed evita i costi di licenza DBMS.


-1

Le unità SSD si basano sulla memoria flash NAND (MLC o SLC). Se stai acquistando unità SSD in un fattore di forma SATA (2 o 3), stai limitando le prestazioni che puoi ottenere da esse. In genere, le unità SSD basate sul veloce controller Sandforce SF-1200 producono 220 MB / secondo di lettura e 205 MB / secondo di scrittura - molto più velocemente di un vecchio disco meccanico rotante.

Tuttavia, se passi a una soluzione PCIe come FusioIO, che non ha il connettore SATA 2 o SATA 3 lento coinvolto, stai cercando soluzioni che sono 10-50 volte più veloci dei tori meccanici rotanti (intendo i dischi).

Quindi, per la tua soluzione "economica", scegli un SDD SATA 2/3 basato sul controller Sandforce SF-1200. Questo ti consentirà un miglioramento della velocità di circa 3-5 volte (basato sull'esperienza del mondo reale). Se hai il budget, scegli FusioIO. Niente lo batterà in termini di prestazioni. È follemente veloce. Aspettatevi di spendere $ 20.000 a $ 50.000 però.


2
Fallacia. Un SSD moderno va bene per circa 50.000 IOPS, offrendo una velocità di trasmissione di 580mb. Un SAS produce meno di 500 IOPS. I database non sono file server.
TomTom,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.