Di cosa ho bisogno di sapere su come lavorare con i database enormi?

Question

Vorrei sapere quali sono i problemi specifici / soluzioni / consigli / best practice [non mi puniscono per la parola] stanno sorgendo mentre si lavora con i database di grandi dimensioni.

Sotto enorme database voglio dire, che hanno tabelle con milioni di righe e / o database con i petabyte di dati.

risposte Platform-orientate sarà troppo grande.

Answer 1

Alcune idee

• Impara i dettagli del motore di database specifici, come funziona

• Come query optimize (suggerimenti, piani di esecuzione)

• Come sintonizzare il database (non solo gli indici, ma storage fisico e la rappresentanza, l'integrazione del sistema operativo).

• Query "trucchi", come le tabelle temporanee per memorizzare i risultati temporanei che possono essere riutilizzati,

• Come valutare la necessità di denormalizzazione per il miglioramento delle prestazioni

• Come utilizzare gli strumenti di profiling per il database, per identificare i colli di bottiglia.

Answer 2

Un paio di pezzi di consulenza da un DBA di produzione (la mia esperienza è MS SQL, ma questi dovrebbe valere per altre piattaforme):

• Manutenzione diventa un significativi problema (backup notturni, DBCCs, posti di lavoro reindex settimanale / ottimizzazione, ecc). Molto facile da avviare superamento di un ragionevole periodo di manutenzione di notte o nel fine settimana. Questo non è solo un techical problema, la sua anche un attività problema ( "che cosa vuoi dire, ci vorranno 4 ore per ripristinare il database dall'ultimo backup buono ? ")

• Gli sviluppatori devono capire che possono avere bisogno di funzionare in modo diverso. "Vuoi dire che non posso solo DELETE (500m rows) FROM MassiveTable e si aspettano di lavoro?

Sono sicuro che penserò a tutto ...

Answer 3

Il mio primo consiglio è di assumere qualcuno che sa quello che stanno facendo e non fare affidamento su SO, altrimenti si potrebbe essere in per alcuni errori estremamente costosi. Il mio secondo sarebbe quello di scegliere il giusto hardware e software della piattaforma. I dettagli dipenderanno molto dalle esigenze.

Answer 4

Altamente si raccomanda di leggere questa presentazione su SQL antipattern http://www.slideshare.net/billkarwin/sql-antipatterns-strike- torna

L'aiuto presentazione (sì, mi ha aiutato molto) trovare una soluzione alla situazione apparentemente fase di stallo.

Answer 5

Qualsiasi RDBMS può soffrire di scarso rendimento se diventa molto grande, soprattutto quando complesse condizioni di join sono in uso. Gli schemi di database devono essere progettati in scala per grandi quantità di traffico, anche. La maggior parte dei sistemi sono abbastanza bravo a movimentare i pesi, ma è anche possibile incorrere in problemi quando si dispone di un database che deve essere distribuito su più macchine.

Un sacco di nuovi strumenti stanno spuntando a che fare con la scalabilità del database. Uno dei più promettenti è memcached, che memorizza un sacco di dati in memoria, che consente l'accesso molto più veloce e favorisce la sincronizzazione tra più server di database. Alcune delle soluzioni NoSQL, che aumentano sistemi SQL tradizionali con le architetture che non fanno rispettare gli schemi.

Alcuni esempi di tecnologie NoSQL sono Cassandra, CouchDB, Google BigTable, MongoDB. Alcune persone giurano che questi sistemi diventeranno cruciali nella gestione "la venuta esplosione di dati".

Answer 6

Ci sono due aspetti di una banca dati che sono più importanti delle dimensioni, per quanto riguarda la progettazione e la gestione va.

La prima è la complessità. Quante tabelle utente ci sono? Il numero di colonne in tali tabelle? Un database con diverse centinaia di tabelle utente nello schema e di oltre un migliaio di colonne di tali tabelle è molto complessa. Un database con una mezza dozzina di tavoli non è molto complesso, anche se contiene petabyte di dati.

Il secondo è la possibilità di condivisione dei dati. Se un database è costruito per condividere i dati tra sei o più applicazioni, sviluppate da team di programmazione separati, è necessario progettare e gestire in modo molto diverso di quanto si farebbe un database che è incorporato in una singola applicazione.

La maggior parte delle domande di database chiesto a SO riguardare singoli database dell'applicazione.

Qui ci sono alcune cose da imparare, in aggiunta a ciò che è già stato menzionato.

imparare la differenza tra partizioni balilla e ping decomposizione. Alcune persone si decompongono tabelle in più tabelle tutte con le stesse colonne, quando il partizionamento loro sarebbe meglio servire.

Approfondisci la vera differenza tra il modello grafico dei dati e il modello relazionale dei dati. Alcune persone progettano database come se fossero chiavi esterne essenzialmente la stessa come puntatori. Quello che finisce con è un sistema che blocca tutta la lentezza di un sistema relazionale e tutta l'ingovernabilità di un sistema grafico.

. (Nota: il modello grafico è spesso chiamato il modello hiearachical o di rete)

La progettazione di un vero e proprio database relazionale è molto più sottile e molto più utile, di progettazione di un database che finge di essere modellati in modo relazionale, ma è davvero grafico dei modellati.