C'è un motivo per cui la maggior parte dei registri sembra essere in testo normale, invece di essere inserita in un database MySQL/altro?utilizzando un database per la registrazione
Mi sembra che metterli in un database renderebbe l'analisi molto, molto più facile ... ma arriverà al sacrificio della velocità o qualcos'altro?
(io non sono così preoccupato con la portabilità, e, ovviamente, si avrebbe registri di testo per la connessione al database.)
posso pensare a due grandi motivi:
In primo luogo, i database sono più lenti rispetto file di testo quando si tratta di aggiungere semplicemente informazioni a un file. Con un database, è necessario stabilire una connessione, trasmettere i dati attraverso la rete, archiviarli in una struttura indicizzata, eccetera. Con un file, è sufficiente scrivere l'errore sul disco locale.
In secondo luogo, a volte le cose che si desidera accedere riguardano il database interrotto. Se il disco locale è rotto, hai problemi più grandi che provare a generare file di registro. Ma puoi registrare le interruzioni del database anche quando tutto il resto funziona.
Detto questo, ci sono molte situazioni in cui le informazioni che voglio registrare sono rilevanti solo mentre l'applicazione funziona correttamente e quando ho già una connessione al database. In questi casi, eseguo direttamente il log in MySQL.
Anche se non si è interessati alla portabilità, credo che sia una grande parte della ragione. File I/O è quasi universale e con un'API estremamente coerente. Altri vantaggi includono:
Detto questo, non c'è nulla di male nel registrare su un DB se la natura dell'app si presta a questo e ho visto molte app che lo fanno.
I database contengono un sovraccarico significativo in termini di memoria, spazio di archiviazione ed efficienza. L'aggiunta di nuovi record a un database o la modifica di record esistenti è molto più lenta. (Inoltre, molti non hanno familiarità con SQL e/o le specifiche di impostazione di un database.)
Se, tuttavia, sono necessarie capacità di analisi o di valutazione della metrica che sono difficili da ottenere tramite un semplice file di testo, allora c'è sicuramente niente di sbagliato in questo. È molto una situazione caso per caso.
(Altri hanno già evidenziato una serie di vantaggi per quanto riguarda la registrazione basata su file.
Penso che il log di DB diventi più utile quando i registri vengono raccolti su una macchina remota (ad esempio, tramite syslog/rsyslog su Linux), per il backup: ciò può essere utile se la macchina originale viene compromessa e i suoi log modificati. La raccolta dei registri in un database (forse in particolare sulla macchina remota) è utile in questo caso, poiché può aiutare a smistare i registri. È inoltre possibile sfogliare i registri in modo più pratico tramite strumenti come phpLogCon o sfogliarli utilizzando pagine Web personalizzate (è spesso più semplice accedere al computer se si esegue un monitoraggio casuale).
Detto questo, la registrazione remota, la registrazione in un DB e uno strumento piacevole per sfogliare i registri sono piuttosto indipendenti (penso che phpLogCon possa funzionare anche con i registri dei file). Se memorizzo i log in un DB, memorizzo anche i registri in un file contemporaneamente, se non altro per poter leggere quando la connessione al DB è inattiva.
È importante notare che non vi è alcun motivo per cui non è possibile scrivere registri su un file (che come altri hanno sottolineato, è molto veloce, efficiente e affidabile) e quindi scaricare i dati in un database (probabilmente su qualche altra macchina) al fine di eseguire analisi che saranno accelerate con le caratteristiche tipiche del database in giro. Ciò è possibile, ovviamente, poiché i dati di registro di solito non hanno bisogno di essere scricchiolanti immediatamente - quindi ha senso rimandare tutto il sovraccarico e la fragilità di un database finché non è necessario.
Storicamente, i database erano costosi e non si vorrebbe mai sprecare le preziose licenze di database sui registri. Tuttavia, oggi i database sono relativamente economici e così anche l'elaborazione. L'utilizzo di un database per i log probabilmente non ti ucciderebbe finanziariamente.
Il vantaggio di un file di registro è che si continua a scrivere fino alla fine. Questa è un'operazione relativamente efficiente rispetto all'uso di un server di database.
Il vantaggio di un database è la possibilità di strutturare i dati del registro in relazioni dati, che possono essere analizzati mediante SQL. Questo può darti delle informazioni dettagliate sul funzionamento del tuo software.
Si potrebbe avere il meglio di entrambi i mondi utilizzando SQLite come database di registro. SQLite è una libreria con un motore SQL collegato al tuo programma. Invece di fopen/fwrite/fclose, si utilizza l'API SQLite per aprire il database, eseguire SQL e chiudere il database. Non esiste un server database perché le operazioni del motore SQLite vengono eseguite nel processo dell'applicazione ... proprio come fopen/fwrite/fclose. Una volta acquisiti i dati in un database SQLite (tutti archiviati in un file semplice), è possibile utilizzare SQL per analizzare i dati del registro. Controlla http://www.squidoo.com/sqlitehammer#module5800826 per un esempio.
-------- EDIT agosto 2010 ------------
Gli sviluppatori di SQLite hanno implementato la registrazione writeahead come di SQLite version 3.7.0. Ciò consente scritture molto più veloci. Controlla this video per maggiori dettagli. Con una scrittura più veloce, SQLite è ancora più utile come database di registrazione.
C'è un problema "piccolo" con questo suggerimento: SQLite non supporta l'accesso simultaneo in lettura/scrittura, il che significa che non sarà possibile visualizzare il file di registro in tempo reale .. che è un enorme svantaggio IMHO. Liron –
@Liron Levi - Con la versione 3.7.0 e la registrazione writeahead abilitata, sarà possibile visualizzare il file di registro in tempo reale perché uno scrittore non blocca i lettori. –