La possibilità di ridimensionare dipenderà dall'uso specifico.

• Se prendo il tuo esempio di righe inserite in un database, il modello più vicino è un log. Un'applicazione, ad esempio un server Web, scrive alcuni dati in un registro. Ogni giorno (o una volta all'ora o in qualsiasi altro periodo di tempo), il registro è ruotato , cioè l'applicazione libera il file corrente e inizia a scrivere su un altro. Una volta che il file è stato liberato, un ETL può elaborare questo file e caricare i dati trasformati nel database.

• Se prendo un esempio diverso, ad esempio un file di grandi dimensioni (e per esteso, intendo diversi gigabyte o terabyte) che dovrebbe essere letto in un contesto in cui è necessario accedere rapidamente a tutte le informazioni in esso contenute, quindi il formato sarebbe diverso e probabilmente utilizzerà pagine e indici per indicare il contenuto giusto; inoltre, la frammentazione sarà una preoccupazione anche se i dati nel file vengono modificati. Puoi trovare ulteriori informazioni su questo tipo di utilizzo leggendo il formato di file PST utilizzato da Microsoft Outlook (può spesso richiedere gigabyte) o formati di file utilizzati dai file di database.

Ciò significa che il formato che stai effettivamente utilizzando è forse estremamente scalabile nel contesto in cui viene utilizzato.

How are they typically built?

Come qualsiasi struttura dati e qualsiasi software in generale.

Idealmente, durante la fase di progettazione e architettura, gli sviluppatori pensano ai modi in cui possono archiviare le informazioni in un file, dati i diversi requisiti, priorità e vincoli. Quindi il formato del file può evolvere per tenere conto di nuovi requisiti, priorità e vincoli, pur essendo, se necessario, compatibile all'indietro.

Esempi:

• Se un requisito nel formato che hai mostrato nella tua domanda è che i valori possono essere multilinea e contenere "=", questo porta un problema specifico di un valore come "12345¶ = PREZZO = 123".

  Se un requisito è seguire gli standard, allora può essere usato qualcosa come EDIFACT invece del formato corrente (magari con alcuni metadati se necessario).

• Se la priorità è rendere il file leggibile, "item" e "price" vanno bene o possono anche essere espansi per essere più espliciti. Se la priorità è ridurre la dimensione del file, "elemento" potrebbe diventare "i", "quantità" - "q", ecc. Ancora meglio, il file può diventare:

  > 22943:3544,1,299.99;11269,5,29.57…
  

  o essere trasformato in un formato binario.

• Se un vincolo è mantenere i dati al sicuro, verrà utilizzata la crittografia. Se un altro vincolo indica che alcuni dei sistemi coinvolti non supportano Unicode, questo è un ulteriore problema da risolvere.

How does a file format evolve from being something basic like to this?

Non pensando in anticipo e rifiutando di utilizzare gli standard esistenti perché è bello reinventare la ruota.

Ci sono vari standard di settore, tutti formati che hanno le loro peculiarità, e tutti hanno subito lo stesso dramma quando sono stati "scalati" (cioè utilizzati al di fuori dell'azienda che li ha creati). Codifiche di caratteri, finali di linee, ripetizioni, parser, tutto deve essere reinventato non appena un'organizzazione utilizza il proprio formato sviluppato internamente per comunicare al mondo esterno.

Quello che una volta era un modo "veloce e sporco" di scambiare messaggi tra due macchine ora diventa un patrimonio che non perderai mai.

A volte però, il pensiero è inserito nella struttura di tali formati. Quando stai cercando di creare un nuovo formato da utilizzare per archiviare o trasmettere dati da o alla tua applicazione, assicurati assolutamente che nessun formato esistente soddisfi le tue esigenze.

YAGNI

Ci sono molti modi diversi per "scalare". Se provi a progettare un formato di file a prova di futuro senza conoscere con un alto grado di certezza su come sta andando il futuro, sei associato a fallire.

I formati leggibili con un editor di testo semplice hanno un enorme vantaggio per il debug. Puoi sempre aprirli e controllarli con gli occhi e gli strumenti di fortuna utilizzando la semplice ricerca e sostituzione del testo. Il tempo di sviluppo risparmiato rispetto al formato binario per il quale è necessario scrivere strumenti di debug è significativo. Finché il tuo semplice formato di testo funziona, segui semplicemente.

Un file di record elaborati sequenzialmente verrà scalato linearmente con la quantità di dati indipendentemente dal formato. Se lo si modifica in formato binario, sarà probabilmente più piccolo, ma continuerà a scalare linearmente. Lo stesso effetto può essere ottenuto comprimendo e mantiene la maggior parte dei vantaggi del formato di testo.

Hai bisogno solo del formato "avanzato" quando hai bisogno dell'accesso casuale. Di solito non prendi semplicemente un contenitore esistente. Se è necessario raggruppare insieme le risorse, il più popolare è il vecchio archivio zip (ha un indice alla fine, quindi è possibile leggere direttamente qualsiasi membro). Se hai bisogno dell'accesso casuale a piccoli elementi, vuoi "* dbm" (berkeley db, ndbm, gdbm, odbm) o sqlite. Oppure un server di database, ovviamente (sqlite è più veloce di qualsiasi server rdbm, ma consente solo un accesso concorrente limitato e nessun cluster e trigger limitati ecc.)

Non è chiaro cosa significhi "scala" in questo contesto, ma se stai considerando che il file diventa grande, ti suggerisco di suddividerlo in più file che possono essere elaborati in parallelo e con qualche tipo di parola chiave di associazione (es. include 'file2' ) che consente di raggruppare più file in una singola unità. Quindi hai la possibilità di spawnare un altro thread o processo per gestire ogni file, possibilmente quindi unendo tutti i risultati alla fine. Se non c'è modo di eseguire alcuna elaborazione in parallelo, non potrai mai scalare veramente.

È bello pensare a cose del genere, però. Gli ultimi file di dati di grandi dimensioni con cui ho lavorato provenivano da un pacchetto di progettazione, ed erano un malvagio miscuglio di dati a campo fisso incorporati all'interno di tag di markup in stile SGML ...

Vedi, secondo il mio punto di vista, finché si possono "salvare" i file nel formato non x, le cose andranno bene. Ma non si può mai essere sicuri di quale versione abbia un destinatario, il salvataggio nel formato "non-x" è il più sicuro.