Che è troppo grande per un database?

Question

Ho un amico che gestisce una web app per le persone sfogliare automobili per la vendita. Ci sono poche migliaia di clienti che lo usano, e ogni cliente ha centinaia e talvolta migliaia di righe nel database (alcuni sono stati avanti per 5 anni con centinaia di auto che vendono ogni mese, e 10s di righe per la vendita (commenti, messaggi, eccetera)). Ha eseguire questo sistema in un database di SQL Server in un server fisico con il simile 20GB di RAM e un paio di processori per tutto il tempo, senza problemi. È questa una sorta di miracolo?

Proprio come la maggior parte dei programmatori, io non sono un DBA e appena ottenere da, grazie a ORM, ecc Dovunque guardo, la gente parla di avere la necessità di frammento o ottenere un server di database separato per i grandi utenti di una web app. Perchè è questo? E 'davvero così inefficiente per avere un grande DB con un sacco o le righe? Dovrei prevede di utilizzare Cassandra o qualcosa, o posso contare su scala bene con Postgres?

Answer 1

Io personalmente non credo che quello che hai descritto è che le grandi di un database. Il server (20 giga di ram;?)) Suona decente. E 'più di utilizzo e il design. Se il database è indicizzato e ben progettato, può crescere molto, molto più grande sul hardware corrente.

Prima di effettuare qualsiasi tipo di interruttore, mi piacerebbe semplicemente guardare l'archiviazione dati inutili e ottimizzare le query se c'è la paura di problemi di prestazioni.

Answer 2

La ragione di sharding e DB server separati è che ad un certo punto che sta per essere più economico di utilizzare più macchine più economiche di un costoso uno. Prezzo di hardware non scala linearmente con prestazioni e una volta raggiunto un certo punto sarà molto più conveniente di ottenere il doppio delle macchine da ottenere una macchina che è due volte più veloce.

Answer 3

Si dovrebbe avere alcun problema in SQL Server, Oracle, o qualsiasi database relazionale o non relazionale moderno. Ho amministrato database con 100 di milioni di record e terabyte di dati.

Answer 4

In genere si divide componenti fino attraverso diversi server in modo da poter gestire il tempo, la resilienza e le prestazioni più facilmente.

E 'certamente del tutto possibile avere una macchina mostro che fa tutto, ma allora potrebbe essere necessario un altro computer mostro nel caso in cui le matrici della scheda madre, o il vostro data center non è disponibile.

Con la scissione di un sito web o un'applicazione istituisce, tra l'altro server è tutto più facile ottenere macchine più economiche, e più di loro. Così si può costruire a resilienza, e non avere componenti che hanno esigenze similiar su scontro hardware.

E 'anche importante pensare a ripristinare gli orari per i server, e piani di recupero.
Cosa succede quando i vostri stampi macchina, possono voi di sostituire nel tempo concordato? Si può eseguire il ripristino da backup in quel momento?

SQL Server o altri database di classe enterprise non dovrebbe avere alcun problema con 10 o 100GB database, fintanto che non sono progettati troppo male. (Abbiamo alcune macchine con quella capacità / uso che non sono alle prese affatto.).

Answer 5

Nella mia mente che è niente. Avere decine di milioni di righe in più tabelle con le dimensioni del database superiore a 10 GB non ha causato problemi per MS SQL Server. Naturalmente non è troppo veloce con i dati che molto, ma per il resto funziona bene.

E per rispondere alla domanda, troppo grande è così grande che non causa problemi. E quando si inizia a causare problemi dipende dalla struttura della tabella e le esigenze prestazionali.

Answer 6

I database sono estremamente efficienti a archiviare e recuperare dati relazionali (dati cioè che è strutturato e ha riferimenti ad altri dati) - questo è quello che sono progettati per fare. Onestamente, il 99% delle persone che fuoriescono sui negozi chiave-valore e Cassandra e quant'altro non hanno idea di quello che stanno facendo. Un server di database è bene per la memorizzazione di grandi quantità di dati, in particolare se siete disposti a mettere un po 'di lavoro in sintonia in modo corretto.

Detto questo, ci sono casi di utilizzo per Cassandra et. al. -. Se si dispone di dati chiave per lo più non strutturati / valore o non hanno bisogno di coerenza o vuoi coccio per la ridondanza, può valere la pena indagare

A meno che non sei un sito estremamente popolare, probabilmente si può ottenere dal proprio bene con un server di database decente - non interruttore fino a quando hai determinato perché è necessario passare. Switching va bene, basta assicurarsi che si sta passando perché serve meglio alle proprie necessità, e non perché è la "cosa bella web-scala per fare"