Ho bisogno di aiuto! Non riesco a risolvere il problema, sto incontrando delle limitazioni hardware - pagina 4
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Ci ho pensato. Chiesto un parere:
Quale sarebbe la velocità rispetto alla lettura di un file e quale sarebbe il rallentamento rispetto al lavoro in memoria?
Il DBMS mette le sue tabelle in memoria quando possibile.
ma non nel tuo caso, a meno che, ovviamente, tu non abbia 32 GB di RAM
quindi come mettere 20GB in 4GB è una vera sfida di ottimizzazione.
Se volete semplificare il vostro compito, è meglio fare un'unità RAM regolare in memoria.
Se non puoi, allora scegli un disco rigido.
Quanto sarà più veloce rispetto alla lettura di un file e quanto sarà più lento rispetto al lavoro in memoria?
Beh, non avete solo bisogno di leggere il file, ma anche di cercare, calcolare, convertire il testo in numeri, eseguire l'ordinamento, ecc.
In primo luogo, se i dati non vengono aggiornati spesso, puoi creare tutti gli indici che vuoi per gli attributi coinvolti nella ricerca dei dati (compresi gli attributi aggregati). Così, la ricerca sarà più veloce (usando gli indici), quindi anche il calcolo.
In secondo luogo, diciamo che MySQL, MS SQL, Oracle e altri database usano la tecnologia di caching dei dati per le query ripetitive, che dà anche un certo vantaggio di velocità di elaborazione.
In terzo luogo, si può dividere una tabella in parti (partizioni), per esempio, per anni. Così le query che selezionano i dati per un anno non leggeranno/ricercheranno i dati situati in altre partizioni.
In quarto luogo, dato che i vostri dati sorgente sono in forma di testo, quando li caricate nel database, dovrebbero essere di dimensioni più piccole a causa della conversione naturale del tipo. Per esempio, il numero 124.223456221 in forma di testo prenderà 13 byte, nel database a seconda del tipo 4-8; data e ora "2014-08-17 10:23:35" prenderà 19 byte, e nel database 8 byte.
Quinto, se usate frequentemente informazioni aggregate per certi periodi, potete aggregare quei dati una volta e memorizzarli in un'altra tabella.
Naturalmente, se stiamo parlando solo di leggere dati in memoria, WinApi lo farà più velocemente, ma cosa fare con i dati dopo? Immaginate, anche per cercare la parte giusta dei dati, dovete leggere tutti i dati dal disco. Oppure devi scrivere la funzionalità di indicizzazione, ordinare i dati nel file, creare file di indice per tutte le operazioni di ricerca e riscrivere metà delle funzionalità del DBMS. Per elaborare una tale quantità di dati e volere prestazioni ragionevoli, è necessario.
La mia opinione è inequivocabile - un DBMS server (file DBMS come MS Access, SQLite non funzionerà qui) su una macchina dedicata. Sarà abbastanza performante e facile da elaborare i dati (query SQL). Altrimenti, perderete un sacco di tempo a scrivere "interni" di basso livello per elaborare il file.
Ci ho pensato. Chiesto un parere:
Quale sarebbe la velocità rispetto alla lettura di un file e quale sarebbe il rallentamento rispetto al lavoro in memoria?
(Ho esperienza con database oltre 3TB e database relativamente nani da 10-100gigs)
ma con un certo hardware... diciamo 64gb di RAM e superiori con un buon sottosistema di dischi
In questa situazione rispetto al lavoro con un file enorme
SQL accelererà notevolmente, ma la velocità dipenderà dalle implementazioni SQL, ovviamente.
- progettazione corretta del database - indici corretti - configurazione corretta del database
questo significa dividere i file (il modo in cui elugovoy scrive è vero)
Un'implementazione completa richiederebbe un server separato e un sistema operativo server - database SQL
se MS SQL non deve essere inferiore a 2008 (sul software anche preferibilmente non inferiore a 64)
Ma secondo me sarà un'implementazione piuttosto laboriosa e che richiederà molto hardware... (64 bit è l'ideale)
--
Se avete solo 16 giga sulla vostra macchina e viene utilizzata come stazione
Basta mettere il server SQL su di esso, non sarà così grande - ma meglio che preoccuparsi di un file di testo
Ma se non avete alcuna esperienza con SQL, un po' di sforzo sarà necessario nell'implementazione.
E se questo file viene compresso con un archiver, quanto sarà grande (perché il testo dovrebbe essere molto ben compresso)?
Il tempo necessario per decomprimere ogni passaggio uccide le prestazioni
il tempo necessario per disarchiviare ogni passaggio ucciderà le prestazioni
Non intendo disarchiviare. Se l'archiviazione può ridurre notevolmente il volume, allora ha senso comprimere le informazioni in un file di indice.
originariamente era
E se questo file è compresso con un archiviatore, qual è il volume (dopo tutto, il testo dovrebbe comprimere molto bene)?
Da qui la reazione al tuo post!
file indice - creare... Questo è un altro argomento
È ancora più figo scrivere il proprio server (SQL-like) - ma perché?
dall'inizio era
Da qui la reazione al tuo post!
file indice - per creare... Questo è un altro argomento
È ancora più figo scrivere il proprio server (come SQL) - ma perché?
La domanda originale all'autore era quanto il file è compresso. ....
Posso chiedere perché?
Sarà compresso del 70-80% e cosa farà l'autore per risolvere il problema che ha descritto?