Posso memorizzare una grande quantità di dati (<= 4 GB) in una colonna della tabella. Ma è una buona idea?

Question

Per fare una lunga storia breve, una parte della domanda su cui sto lavorando necessità di memorizzare un po 'grande volume di dati in un database, per un'altra parte della domanda per prendere in seguito. Normalmente questo sarebbe <2000 righe, ma può occasionalmente superare 300.000 righe. I dati devono essere memorizzati temporaneamente e può essere cancellato in seguito.

Ho giocato in giro con varie idee e una cosa è venuto in mente oggi. Il tipo di dati LONGTEXT può memorizzare un massimo di 2 ^ 32 byte, che equivale a 4 GB. Ora, questo è un sacco di roba da stipare in una riga della tabella. Intendiamoci, i dati non dovrebbero superare le 60-80 MB al massimo. Ma la mia domanda è, è una buona idea per fare in realtà che?

Le due soluzioni Attualmente sto giocando con utilizzo sono qualcosa di simile:

• Inserimento di tutti i dati come singole righe in una tabella "temporanea" che sarebbe troncato dopo rivestimento.
• L'inserimento di tutti i dati come una stringa serializzata in una colonna LONGTEXT di fila che sarebbe stato cancellato dopo rivestimento.

Puramente dal punto di vista delle prestazioni, sarebbe meglio per memorizzare i dati come potenzialmente> 300.000 singole righe, o come voce 60 MB LONGTEXT?

Se si tratta di un lavaggio, io probabilmente andare con l'opzione LONGTEXT, in quanto renderebbe la parte dell'applicazione che raccoglie i dati più facile da scrivere. Sarebbe anche legare meglio con un'altra parte, che aumenterebbe le prestazioni complessive dell'applicazione.

Apprezzerei tutti i pensieri su questo.

Answer 1

serializzazione di tutti i dati in un LONGTEXT ... bestemmia !! :)

Seriamente, però, mi viene in mente che se si fa questo, si avrebbe avuto altra scelta che per estrarre tutto in un unico, gigantesco, pezzo. Se si spalmano in singole righe, d'altra parte, si può avere il front-end recuperare in lotti più piccoli.

Almeno voi stessi dando l'opzione sembra la cosa più intelligente da fare. (Tenete a mente che sottovalutare i requisiti di dimensione future di una volta dati può essere un errore fatale!)

E se si progetta le tabelle a destra, dubito molto che 60MiB di diffusione di dati su 300.000 righe sarebbe meno efficiente di recupero 60MiB del testo e analisi che sul front-end.

In definitiva, la domanda è: pensi che il tuo front-end in grado di analizzare il testo in modo più efficiente rispetto a MySQL può prenderlo

?

Answer 2

Questo dovrebbe andare bene fino a quando si utilizza un motore di memoria di archiviazione . In MySQL, ciò significa usare il motore invece di InnoDB MyISAM o memoria di archiviazione. In caso contrario, l'utilizzo del disco porterà la vostra applicazione in ginocchio.

Answer 3

Che tipo di dati e come verrà utilizzato? Probabilmente sarà molto meglio per memorizzare ed elaborare in memoria della vostra applicazione. Almeno, sarà molto più veloce e non caricherà il motore DB.

Answer 4

Si può sempre memorizzare nel database come formato di 300.000 riga e utilizzare memcached per memorizzare nella cache i dati in modo non c'è bisogno di farlo di nuovo. Si prega di notare che i negozi di memcached nella memoria della macchina, quindi se si sta utilizzando un sacco di questi dati si può modo per impostare un basso scadono su di esso. Ma memcached velocizza notevolmente il tempo necessario per recuperare i dati, perché non dovete fare domande ogni caricamento della pagina.

Answer 5

Se avete intenzione di essere solo la scrittura di un grande, BLOB temporanea si potrebbe prendere in considerazione la scrittura di un file temporaneo su un file system condiviso, invece.