Limite superiore per il numero di righe nei database Open Source?

Question

Ho un progetto in cui sto eseguendo il data mining di un database di grandi dimensioni.Attualmente memorizzo tutti i dati in file di testo, sto invece cercando di comprendere i costi e i vantaggi dell'archiviazione del database relazionale dei dati.I punti appaiono così:

CREATE TABLE data (
    source1 CHAR(5),
    source2 CHAR(5),
    idx11   INT,
    idx12   INT,
    idx21   INT,
    idx22   INT,
    point1  FLOAT,
    point2  FLOAT
);

Quanti punti come questo posso ottenere con una prestazione ragionevole?Al momento dispongo di circa 150 milioni di punti dati e probabilmente non ne avrò più di 300 milioni.Supponiamo che io stia utilizzando una scatola con 4 CPU Xeon dual-core da 2 GHz e 8 GB di RAM.

Answer 1

MySQL è più in grado di servire le vostre esigenze così come il suggerimento di Alex di PostgreSQL. prestazioni ragionevoli non dovrebbe essere difficile da raggiungere, ma se la tabella sta per essere pesantemente accedere e hanno una grande quantità di DML, si vorrà sapere di più sul blocco utilizzato dal database si finisce per scegliere.

Credo PostgreSQL può utilizzare il blocco a livello di riga, fuori dalla scatola, in cui MySQL dipenderà dal motore di archiviazione che si sceglie. MyISAM blocca solo a livello di tabella, e quindi la concorrenza soffre, ma i motori di memorizzazione come InnoDB per MySQL può e utilizzerà il blocco a livello di riga per aumentare la velocità. Il mio suggerimento sarebbe quello di iniziare con MyISAM e passare a InnoDB solo se si scopre che è necessario il blocco a livello di riga. MyISAM funziona bene in molte situazioni ed è estremamente leggero. Ho avuto tavoli oltre 1 miliardo di righe in MySQL utilizzando MyISAM e con una buona indicizzazione e il partizionamento, è possibile ottenere grandi prestazioni. Si può leggere di più su storage engine di MySQL in a MySQL bagagli Motori e circa il partizionamento delle tabelle a partizionamento delle tabelle . Ecco un articolo sulla in pratica su una tavola di 113m righe che si possono trovare utili.

Credo che i benefici di memorizzazione dei dati in un database relazionale superano di gran lunga i costi. Ci sono così tante cose che si possono fare una volta i vostri dati sono all'interno di un database. Punto nel tempo di recupero, garantendo l'integrità dei dati, accesso di sicurezza a grana più fine, il partizionamento dei dati, la disponibilità ad altre applicazioni attraverso un linguaggio comune. (SQL), ecc ecc.

Buona fortuna con il vostro progetto.

Answer 2

PostgreSQL dovrebbe essere in grado di ospitare ampiamente i dati - fino a 32 terabyte al tavolo, ecc, ecc Se ho capito bene, si sta parlando di 5 GB al momento, 10 GB max (circa 36 byte / riga e fino a 300 milioni di righe), in modo quasi tutti i database dovrebbe infatti essere in grado di ospitare facilmente.

Answer 3

PER TUA INFORMAZIONE:Postgres si adatta meglio di MySQL su richieste multiprocessore/sovrapposte, da una recensione che stavo leggendo qualche mese fa (scusate, nessun collegamento).

Presumo dal tuo profilo che si tratti di una sorta di problema biometrico (sequenze di codoni, sequenza di amminoacidi di enzimi vs proteine ​​o qualcosa del genere).Se hai intenzione di attaccare questo con richieste simultanee, andrei con Postgres.

OTOH, se i dati verranno caricati una volta, quindi scansionati da un singolo thread, forse MySQL nella sua modalità "ACID non richiesto" sarebbe la soluzione migliore.

Hai qualche pianificazione da fare in caso di casi d'uso di accesso prima di poter selezionare lo stack "migliore".