Scelta del database per grandi volumi di dati?

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 tabella grande, che è quasi solo inserire / leggere (nessun aggiornamento).

La quantità stimata di dati in quella tabella crescerà a 500.000 record al giorno e dovremmo conservarne almeno 1 anno per poter fare vari rapporti.

È necessario disporre di un database (di sola lettura) replicato come backup / failover e forse per scaricare i report nelle ore di punta.

Non ho esperienza diretta con quei database di grandi dimensioni, quindi sto chiedendo quelli che hanno 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 una configurazione 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, quelle righe tendono ad essere ridotte a campioni e quindi eliminate entro pochi giorni, quindi non posso parlare di prestazioni a lungo termine con più di ~ 100 milioni di righe.

Ho scoperto che le prestazioni di inserimento sono abbastanza ragionevoli, specialmente se usi la COPIA di massa. Le prestazioni delle query vanno bene, anche se le scelte che il pianificatore fa a volte mi sconcertano; in particolare quando si effettuano JOIN / EXISTS. Il nostro database richiede una manutenzione abbastanza regolare (VACUUM / ANALYZE) per mantenerlo regolare. Potrei evitare un po 'di questo ottimizzando più attentamente l'autovacuum e altre impostazioni, e non è un grosso problema se non stai facendo molte DELETE. Nel complesso, ci sono alcune aree in cui ritengo sia più difficile da configurare e mantenere di quanto non dovrebbe essere.

Non ho usato Oracle e MySQL solo per piccoli set di dati, quindi non posso confrontare le prestazioni. Ma PostgreSQL funziona bene per set di dati di grandi dimensioni.

Answer 2

Hai una copia di " Il Data Warehouse Toolkit & Quot ;?

Il suggerimento è di fare quanto segue.

1. Separare i valori dei fatti (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 un numero di piccole tabelle delle dimensioni per consentire & Quot; slicing and cubing & Quot; i fatti.

2. Conserva i fatti in semplici file flat fino a quando non desideri eseguire rapporti in stile SQL. Non creare e eseguire il backup di un database. Creare e eseguire il backup dei file; caricare una base di dati solo per i report che è necessario eseguire da SQL.

3. Ove possibile, creare riepiloghi o dati aggiuntivi per l'analisi. In alcuni casi, potrebbe essere necessario caricare tutto su un database. Se i tuoi file riflettono il design della tua tabella, tutti i database dispongono di strumenti di caricamento in blocco che possono popolare e indicizzare tabelle SQL dai file.

Answer 3

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

Answer 4

La quantità di dati (200 milioni di record all'anno) non è molto grande e dovrebbe andare con qualsiasi motore di database standard.

Il caso è ancora più semplice se non hai bisogno di report live su di esso. Specificherei e preregistrerei i dati su qualche altro server, ad es. lotto giornaliero. Come suggerito da S.Lott, potresti voler leggere sul data warehousing.

Answer 5

Alcuni punti interessanti riguardanti Google BigTable ci sono ...

Bigtable Vs DBMS

• Velocità query veloce
• Nessun join, nessun supporto SQL , database orientato alla colonna
• Usa una Bigtable invece di avere molte tabelle normalizzate
• Non è nemmeno in 1NF in una vista tradizionale
• Progettato per supportare query cronologiche timestamp field = > com'era questa pagina web ieri?
• La compressione dei dati è più semplice & # 8211; le righe sono sparse

Ho evidenziato Joins and No SQL Support, come hai menzionato, dovrai eseguire una serie di report. Non so quanto (se ce ne fosse) se non avessi la possibilità di farlo, avrai se esegui rapporti se dovessi utilizzarlo.

Answer 6

Usiamo Firebird per un database davvero enorme (che conserva i dati da oltre 30 anni) e si adatta molto bene.

La cosa migliore è che hai proprietà da configurare, ma a differenza di Oracle, lo installi e funziona molto bene senza la necessità di iniziare la configurazione prima di poterlo usare.