Scelta database per volume di dati di grandi dimensioni?

Question

Sto per iniziare un nuovo progetto che dovrebbe avere un database piuttosto grande.

Il numero di tabelle non sarà grande (< 15), la maggior parte dei dati (99%) sarà contenuta in una grande tabella, che è quasi solo inserimento/sola lettura (nessun aggiornamento).

L'importo stimato dei dati in una tabella che sta per crescere a 500.000 record al giorno, e dovremmo tenere almeno 1 anno di loro di essere in grado di fare i vari rapporti.

Deve esserci (solo lettura) database replicato come backup/failover e, forse, per scaricare i report nei momenti di punta.

Non ho esperienza di prima mano con quei grandi database, quindi chiedo a chi ha quale DB è la scelta migliore in questa situazione. So che Oracle è la scommessa sicura, ma sono più interessato se qualcuno ha esperienza con Postgresql o Mysql con impostazione simile.

Answer 1

Ho usato PostgreSQL in un ambiente in cui vediamo 100K-2M nuove righe al giorno, la maggior parte aggiunte a una singola tabella. Tuttavia, tali file tendono a essere ridotte a campioni e quindi eliminate in pochi giorni, quindi non posso parlare di prestazioni a lungo termine con più di ~ 100 milioni di righe.

Ho trovato che le prestazioni degli inserti sono abbastanza ragionevoli, soprattutto se si utilizza la COPIA di massa. Le prestazioni delle query vanno bene, anche se a volte le scelte del pianificatore mi fanno venire in mente; in particolare quando si fa JOIN/EXISTS. Il nostro database richiede una manutenzione abbastanza regolare (VACUUM/ANALYZE) per mantenerlo senza intoppi. Potrei evitare un po 'di ciò ottimizzando più accuratamente l'autovacuum e altre impostazioni, e non è tanto un problema se non stai facendo molti DELETE. Nel complesso, ci sono alcune aree in cui ritengo sia più difficile da configurare e gestire di quanto dovrebbe essere.

Non ho usato Oracle e MySQL solo per dataset di piccole dimensioni, quindi non posso confrontare le prestazioni. Ma PostgreSQL fa funziona bene per dataset di grandi dimensioni.

Answer 2

Google BigTable database e Hadoop sono due motori di database in grado di gestire grandi quantità di dati.

Answer 3

Utilizziamo Firebird per un database davvero enorme (mantenendo i dati per oltre 30 anni) e si adatta molto bene.

Il meglio è che si dispone di proprietà da configurare, ma a differenza di Oracle lo si installa e funziona molto bene senza la necessità di avviare la configurazione prima di poterlo utilizzare.

Answer 4

Alcuni punti interessanti per quanto riguarda Google BigTable in ci sono ...

Bigtable Vs DBMS

• tasso Query veloce
• No entra a far parte, Nessun supporto SQL, database di colonna-oriented
• Utilizza un Bigtable invece di avere molte tabelle normalizzate
• Non è nemmeno in 1NF in una vista tradizionale
• Progettato per supportare le query cronologiche campo data/ora => che aspetto ha questa pagina Web ieri?
• La compressione dei dati è più facile -rows sono scarsi

ho evidenziato le giunture e nessun supporto SQL come lei ha ricordato che si avrà bisogno di eseguire una serie di rapporti. Non so quanto (se ce ne fosse qualcuno) che non ha l'abilità di farlo, avrò su di te rapporti in esecuzione se tu dovessi usare questo.

Answer 5

Avete una copia di "The Data Warehouse Toolkit"?

Il suggerimento è quello di fare quanto segue.

1. Separare i valori (misurabili, numerici) dalle dimensioni che qualificano o organizzano tali fatti. Un grande tavolo non è proprio la migliore idea.È una tabella dei fatti che domina il design, oltre a una serie di tabelle di piccole dimensioni per consentire di "affettare e tagliare a cubetti" i fatti.

2. Conservare i dati in file flat semplici fino a quando non si desidera creare report in stile SQL. Non creare e eseguire il backup di un database. Creare e eseguire il backup di file; carica una base dati solo per i report che devi eseguire da SQL.

3. Dove possibile creare un riepilogo o datamat aggiuntivi per l'analisi. In alcuni casi, potrebbe essere necessario caricare l'intero oggetto in un database. Se i file riflettono la progettazione della tabella, tutti i database dispongono di strumenti di caricamento in blocco che possono popolare e indicizzare le tabelle SQL dai file.

Answer 6

La quantità di dati (200m record per anno) non è davvero grande e dovrebbe andare con qualsiasi motore di database standard.

Il caso è ancora più semplice se non hai bisogno di resoconti dal vivo. Mi piacerebbe speculare e pre-aggregare i dati su qualche altro server, ad es. lotto giornaliero Come suggerito da S.Lott, ti potrebbe interessare leggere il data warehousing.