È inopportuno archiviare i dati come json in testo normale? [duplicare]

La domanda da porre è efficiente in che modo? Sembra che i tuoi record possano essere archiviati in un modo più efficiente di spazio assumendo una struttura di record fissa (come farebbe un database) e salvando i valori in binario.

I numeri dei record sembrano essere adatti a un int a 64 bit, mentre attualmente sono memorizzati in una stringa di 16 caratteri più 2 doppi apici, oltre alla formattazione. Se i campi di testo possono avere un limite di lunghezza, anche questo sarebbe d'aiuto. I valori dell'account sembrano essere adatti a 16 bit int, anche se probabilmente vorrai inserti a 32 bit per il ridimensionamento. Quindi diciamo che le stringhe "Valore" e "serie" possono essere limitate a 31 caratteri più un byte di lunghezza. Stai guardando tutti i record:

• 8 byte per il numero di record
• 32 byte per il valore
• 4 byte per l'account 1
• 4 byte per l'account 2
• 32 byte per la serie

Questo è 80 byte per record. Il primo record nell'elenco è 150 byte. Naturalmente, se le stringhe devono essere almeno 1k, ma hanno una media di 150 byte, allora l'equazione cambia. Naturalmente, non è necessario lasciare che le stringhe abbiano una lunghezza fissa. È possibile memorizzare un byte di lunghezza e avere una dimensione del record variabile. Ora è molto efficiente da archiviare su disco, ma potrebbe richiedere più tempo per leggere e scrivere. Soprattutto se devi fare un sacco di accesso casuale.

L'intero set di record si adatta alla memoria? Quindi forse tempi di lettura / scrittura lenti non sono importanti perché si legge solo una volta all'avvio dell'app e si scrive una volta all'arresto dell'app. (Probabilmente no, ma sto dando un esempio estremo.)

Ci sono modi in cui puoi ottimizzare ognuna di queste cose o trovare compromessi ragionevoli in situazioni in cui l'ottimizzazione di una qualsiasi cosa comprometterebbe l'efficienza in caso contrario. Ma tutto dipende da cosa farai con questi dati.

È meno efficiente archiviare un piccolo bit di dati come il tuo esempio codificato in una stringa piuttosto che come binario? Sì. Quanto meno? Non abbastanza per preoccuparsi.

È meno efficiente memorizzare migliaia di tali record in una stringa piuttosto che in binario? Oh Dio, sì.

Ecco perché: non riesco a prevedere l'indice di "account1" nel 42esimo record perché i campi dei record precedenti non avevano una lunghezza fissa. Ciò significa che non riesco a trovarlo senza analizzare tutto prima di esso.

Ora certo, potresti anche fare un testo con una lunghezza fissa, ma nessuno lo rispetterà mai, quindi nessuno lo fa. Per qualche strana ragione anche se la rispettano quando è fatta in binario. Perché? Non lo so, forse avrai una classe migliore di programmatore quando li costringerai a battere in un editor esadecimale invece che nel blocco note.

È proprio vero che i database di grande importanza ti danno davvero un valore sul tuo file system. Bene, oltre alle transazioni.

Come per 80 byte contro 150 byte? Feh! Se mi preoccupassi di un fattore O (n) come quello (che non lo faccio) mi limiterò a comprimere la cosa.

Ciò che mi interessa è imbattersi in un problema schlemiel the painter in cui non posso fare piccole cose , che prima potevo fare bene, perché la quantità di dati è diventata grande. Questo non è qualcosa che puoi risolvere semplicemente lanciando un disco rigido più grande al problema. Pensa a come questi record vengono usati.

Questo è il motivo per cui le persone che chiedono informazioni sulla dimensione massima del file di un sistema prima di creare i file JSON devono davvero essere seduti e discusso.

Da una prospettiva diversa rispetto alle altre risposte:

Sono d'accordo sul fatto che un DBMS è probabilmente eccessivo in termini di complessità dello spazio, ma un DBMS può anche darvi garanzie di integrità dei dati e sicurezza. Spesso dispongono di funzionalità di backup integrate e consentono di crittografare i dati sul disco (oltre a qualsiasi crittografia a livello di sistema operativo che può essere o non essere installata).

Questa potrebbe non essere una risposta diretta alla tua domanda, ma ogni volta che vedo XML, JSON, INI o altri formati di testo leggibili da umani che memorizzano dati potenzialmente sensibili (corrispondenti numeri di account con chiavi API, ad esempio), penso sempre a quanto sarebbe facile per un utente malintenzionato ottenere quel file e utilizzarne il contenuto. Il file indica anche cosa significa ogni dato quando è nel formato nell'OP.

Se un utente malintenzionato ottiene quel file JSON, ha tutto. Conoscono tutti i tuoi clienti e hanno accesso alle loro chiavi API, il che significa che possono facilmente accedere a tutti i dati forniti tramite tale API. Un DBMS può essere configurato per crittografare le voci singolarmente. Quindi, se un utente malintenzionato ottiene il database: vabbè, è crittografato. Se l'attaccante ottiene un record del cliente: Ok, è un po 'male, ma non hanno accesso a tutti i record dei clienti.

Se si tenta di ripristinare l'integrità dei dati, backup, crittografia, ecc., posso quasi garantire che si otterrà qualcosa di sbagliato. I DBMS "hanno già sbagliato" molte volte e tutti hanno dovuto risolvere questi problemi. Qualsiasi difficoltà percepita che si interfaccia con un DBMS a livello di programmazione è nulla rispetto alla protezione dei dati in modo corretto.

Forse non è una grande preoccupazione - non so quale accesso forniscano queste chiavi API - ma menzionare "account" e "pagamenti" mi mette un po 'in secondo piano. Sembra un dato che deve essere protetto correttamente. Per quanto riguarda lo spazio, tutti hanno assolutamente ragione che l'importo risparmiato è banale. Ma per quanto riguarda la sicurezza, un file JSON è piuttosto spaventoso.

L'efficienza dell'elaborazione in batch non è la principale preoccupazione. Memorizza i dati in un database. È molto più semplice scrivere i dati corretti usando sql piuttosto che modificare un file di testo, e ci sono più controlli di coerenza con il database (se si usano chiavi esterne e tipi di dati corretti). Un database relazionale è anche più veloce, ma, stai eseguendo l'elaborazione in batch, quindi l'elaborazione di un file di testo sarà probabilmente abbastanza veloce.

Mi rendo conto che questo è contrario ai commenti seguenti (JSON è così facile da usare con qualsiasi linguaggio, è leggibile dall'uomo, ...). Molti dei problemi che ho riscontrato si sono ridotti a qualcuno che non modificava correttamente un file di testo. E sì, nonostante la mia età ho usato JSON. Sento che JSON è ingannevolmente facile da fare errori che possono essere controllati da vincoli di database comuni.

Per 100-1000 record elaborati alcune volte al giorno, l'efficienza è totalmente irrilevante . Sarà più veloce di premere un pulsante in ogni caso.