2010-03-01 14 views
55

L'azienda per cui lavoro sta tentando di passare a un prodotto che utilizza il formato di file flat in un formato di database. Gestiamo file di dati piuttosto grandi (ad es .: 25 GB/file) e vengono aggiornati molto rapidamente. Abbiamo bisogno di eseguire query che accedono casualmente ai dati, oltre che in modo contiguo. Sto cercando di convincerli dei vantaggi dell'utilizzo di un database, ma alcuni dei miei colleghi sembrano riluttanti a questo. Quindi mi stavo chiedendo se voi ragazzi potete aiutarmi qui con alcune ragioni o collegamenti ai post dei motivi per cui dovremmo usare i database, o almeno chiarire perché i file piatti sono migliori (se lo sono).database vs file flat

+7

Si dovrebbe menzionare che tipo di struttura dei dati si sta parlando qui. Se ognuno di questi file da 25 GB si traduce in 25 righe da 1 GB ciascuna, probabilmente stai meglio con i tuoi file flat. –

+0

In realtà sono più curioso di sapere perché i tuoi colleghi non vogliono utilizzare un Database relazionale come archivio dati? Geezus – Jeff

+0

tutto dipende da tutti i tipi di variabili. Impossibile dire che uno è migliore dell'altro. –

risposta

73
  1. Basi di dati in grado di gestire l'esecuzione di query attività, in modo da non dover camminare sopra file manualmente. I database possono gestire query molto complicate.
  2. Basi di dati in grado di gestire le attività di indicizzazione, quindi se compiti come ottenere il record con id = x può essere molto veloce
  3. Basi di dati in grado di gestire multiprocesso/accesso multithread.
  4. database possono gestire l'accesso da rete
  5. database possono controllare i dati integrità
  6. database possono aggiornare i dati facilmente (vedi 1))
  7. database sono affidabili
  8. database possono gestire le transazioni e concorrenti accesso
  9. I database + ORM consentono di manipolare i dati di in modo molto facile da programmare.
2

Le capacità di query ad hoc SQL sono una ragione sufficiente per me. Con un buon schema e indicizzazione sui tavoli, questo è veloce ed efficace e avrà buone prestazioni.

4

Non costruirlo se è possibile acquistarlo.

Ho sentito questa citazione di recente e mi sembra davvero una linea guida. Chiediti questo ... Quanto tempo è stato dedicato alla gestione della porzione di file della tua app? Sospetto che sia stata spesa una buona quantità di tempo per ottimizzare questo codice per le prestazioni. Se avessi utilizzato un database relazionale per tutto il tempo, avresti speso molto meno tempo a gestire questa parte della tua applicazione. Avresti avuto più tempo per il vero aspetto "business" della tua app.

+0

In realtà, l'intera applicazione è solo un paio di strani script di bash ... l'intero sistema è una serie di singoli file in movimento. Triste, lo so ... – hyperboreean

+2

Cool, ma l'ultima volta che ho controllato i migliori database sono gratuiti. – rook

+4

Ahimè, il contrario è altrettanto vero. Un detto migliore è "Acquistare buone soluzioni su misura per le tue esigenze, se esistono, altrimenti costruiscile" –

5

Databases fino in fondo.

Tuttavia, se si ha ancora bisogno di archiviare file, non si ha la capacità di assumere un nuovo RDBMS (come Oracle, SQLServer, ecc.) Piuttosto che cercare in XML.

XML è un formato di file di struttura che offre la possibilità di archiviare le cose come un file ma di fornire potenza di interrogazione sul file e sui dati al suo interno. I file XML sono più facili da leggere rispetto ai file flat e possono essere facilmente trasformati applicando un XSLT per una migliore leggibilità umana. XML è anche un ottimo modo per trasportare i dati in giro se necessario.

Suggerisco caldamente un DB, ma se non è possibile seguire questa strada, XML è un secondo ok.

+3

Ma Oracle e SQL Server costano denaro, perché pagare per qualcosa quando è meglio gratuitamente? MySQL fino in fondo. – rook

+3

Se hanno un file CSV da 25 gb, questo potrebbe facilmente raddoppiare le dimensioni (se non di più) con tag XML per righe e colonne. Il solo dire che è significativo è tenere in considerazione quando si passa da file flat a XML. –

+4

Radice di @Scott: personalmente tendo a detestare l'XML perché lo considero un metodo pesante per trasmettere i dati. – hyperboreean

3

Che dire di un database non relazionale (NoSQL) come SimpleDB di Amazon, Tokio Cabinet, ecc.? Ho sentito che Google, Facebook, LinkedIn li utilizzano per archiviare i loro enormi set di dati.

Puoi dirci se i tuoi dati sono strutturati, se lo schema è corretto, se hai bisogno di una facile replicabilità, se i tempi di accesso sono importanti, ecc.?

+0

Anche noi ci stiamo occupando di questo ... prima dobbiamo accertarci che siamo tutti sulla stessa pagina. Tuttavia, se è necessario eseguire alcuni report complessi, non sono sicuro di come nosql gestisca questo. – hyperboreean

3

quali tipi di file non sono menzionati. Se sono file multimediali, vai avanti con i file flat. Probabilmente hai solo bisogno di un DB per i tag e un modo per associare i "BLOB esterni" ai record nel DB. ma se la ricerca full text è qualcosa di cui hai bisogno, non c'è altro modo di fare altro che migrare a un DB completo.

un'altra cosa, il tuo filesystem potrebbe fornire il limite massimo per quanto riguarda il numero di file fisici.

4

Sono più veloci; a meno che non si carichi in memoria l'intero file flat, un database consentirà un accesso più rapido in quasi tutti i casi.

Sono più sicuri; i database sono più facili da salvare in sicurezza; hanno meccanismi per controllare la corruzione dei file, che non sono i file flat. Una volta che la corruzione nel tuo file flat è migrata ai tuoi backup, hai finito e potresti persino non saperlo ancora.

Hanno più funzionalità; i database possono consentire a molti utenti di leggere/scrivere contemporaneamente.

Sono molto meno complessi con cui lavorare, una volta impostati.

32

Questo è an answer I've already given qualche tempo fa:

dipende interamente sulle esigenze di applicazione specifici del dominio. A file di testo diretto/binario l'accesso ai file può essere estremamente veloce, efficiente, oltre a fornire tutte le funzionalità di accesso ai file di del file system del sistema operativo.

Inoltre, il linguaggio di programmazione molto probabilmente ha già un modulo incorporato (o è facile fare uno) per specifica analisi.

Se quello che vi serve è che molti accoda (INSERTI?) E pochi di accesso/sequenziale poca/nessuna concorrenza, i file sono il modo di andare .

D'altra parte, quando le vostre esigenze per la concorrenza, lettura non sequenziale/scrittura, atomicità, permessi atomiche, i dati è relazionale dalla natura, ecc, si sarà meglio con un database relazionale o OO.

C'è molto che può essere realizzato con SQLite3, che è estremamente leggero (sotto i 300 KB), acido compliant, scritto in C/C++, e altamente onnipresente (se non è già incluso nel il tuo linguaggio di programmazione -per esempio Python-, ce n'è sicuramente uno disponibile). Può essere utile anche con su file db grandi come 140 terabyte o 128 tebibyte (Link to Database Size), possibili in più.

Se le vostre esigenze in cui maggiore, non ci sarebbe nemmeno una discussione, andare per un RDBMS in piena regola.

Come dici in un commento che "il sistema" è solo un mucchio di script, quindi dovresti dare un'occhiata a pgbash.

2

A meno che non si stiano caricando i file nella memoria ad ogni avvio, utilizzare un database. Semplice come quella.

Ciò presuppone che i college abbiano già il programma per gestire le query sui file. In caso contrario, utilizzare un database.

1

Differenza tra database e file piatti sono i seguenti:

  • Database fornire maggiore flessibilità, mentre file flat fornire meno flessibilità.

  • Il sistema di database fornisce la coerenza dei dati mentre il file piatto non può fornire la coerenza dei dati.

  • Il database è più sicuro su file flat.
  • Supporto database DML e DDL mentre i file flat non supportano questi.

  • Meno ridondanza dei dati nel database mentre maggiore ridondanza dei dati nei file flat.

Problemi correlati