MySql INSERTO vs PHP file_put_contents

Question

Possiedo un'applicazione PHP/MySql in rapida crescita e con scrittura che inserisce nuove righe a una velocità di circa una dozzina al secondo in una tabella INNODB di diverse milioni di righe.

Ho iniziato a utilizzare le istruzioni INSERT in tempo reale e poi ho spostato in PHP file_put_contents per scrivere le voci in un file e LOAD DATA INFILE per ottenere i dati nel database. Qual è l'approccio migliore?

Ci sono delle alternative che dovrei considerare? Come posso aspettarmi che i due metodi gestiscano le collisioni e aumentino il carico in futuro?

Grazie!

Answer 1

Pensa a LOAD DATA INFILE come metodo batch di inserimento dati. Elimina il sovraccarico di accendere una query di inserimento per ogni istruzione, quindi è molto più veloce. Tuttavia, si perde parte del controllo durante la gestione degli errori. È molto più semplice gestire un errore su una singola query di inserimento o una riga nel mezzo di un file.

Answer 2

Il modo in cui gestiamo i nostri inserti è quello di inviarli a un sistema di messaggi in coda come ActiveMQ. Da lì abbiamo un'applicazione separata che carica gli inserti utilizzando LOAD DATA INFILE in batch di circa 5000. La gestione degli errori può ancora aver luogo con l'infile, tuttavia elabora gli inserti molto più velocemente. Se l'impostazione di una coda di messaggi non rientra nell'ambito dell'applicazione, non vi è alcun motivo per cui file_put_contents non sia un'opzione accettabile, specialmente se è già implementata e funziona correttamente.

Inoltre, è possibile testare gli indici di disabilitazione durante le scritture per vedere se ciò migliora le prestazioni.

Answer 3

Non sembra che dovresti usare innoDB. Indipendentemente da ciò, una dozzina di inserti al secondo non dovrebbe essere problematica nemmeno per l'hardware crappy - a meno che, forse, il tuo modello di dati sia molto complesso, ma per questo, LOAD DATA INFILE è molto buono perché, tra le altre cose, ricostruisce gli indici una sola volta, al contrario di ogni inserto. Quindi usare i file è un approccio decente, ma assicurati di aprirli in modalità solo aggiunta.

a lungo termine (1k + di scritture/s), consultare altri database, in particolare cassandra per applicazioni di scrittura pesanti.

Answer 4

LOAD DATA è disattivata su alcuni server per motivi di sicurezza:

http://dev.mysql.com/doc/mysql-security-excerpt/5.0/en/load-data-local.html

Inoltre non mi piace scrivere le mie applicazioni a testa in giù per mantenere l'integrità del database.

Answer 5

A seconda che si possa permettere che i dati inseriti da PHP non siano immediatamente disponibili nella tabella, allora l'opzione INSERT DELAYED potrebbe essere un'opzione.

MySQL accetterà i dati da inserire e tratterà l'inserimento in seguito, mettendolo in coda. Quindi questo non bloccherà la tua applicazione PHP mentre MySQL garantisce che i dati vengano inseriti in seguito.

As it says in the manual:

Un altro grande vantaggio di utilizzare INSERT DELAYED è che gli inserti da molti clienti sono raggruppati e scritti in un unico blocco. Questo è molto più veloce di molti inserti separati.

Ho usato questo per i dati di registrazione in cui una perdita di dati non è fatale, ma se volete essere protetti da crash del server quando i dati provenienti da INSERT DELAYED non erano stati ancora inserito, si poteva guardare in replicare le modifiche via per una macchina slave dedicata.

Answer 6

se si esegue la procedura di inserimento sql, eseguire il wrapping delle istruzioni di esecuzione pdo in una transazione. farlo accelererebbe notevolmente il processo.