Come vengono costruiti i nuovi formati di file?

Question

Ho utilizzato una suite di software installata negli uffici e su navi remote.Le installazioni comunicano avanti e indietro e lo fanno utilizzando un semplice formato di file proprietario che assomiglia a questo:

/SHIP:16
MILES=45213

/ORDER:22943
STATUS=OPEN
TOTAL=447.84
URGENCY=HIGH

/ORDERLINES:22943
ITEM=3544
QUANTITY=1
PRICE=299.99
ITEM=11269
QUANTITY=5
PRICE=29.57

Di recente, ho scritto un software per un cliente che salva le informazioni nello stesso tipo di formato di file flat.

Quando il file viene aperto, le righe vengono ripetute e "accadono cose" alle righe (cioè vengono inserite in un database o altro).

Ma mi è venuto in mente di pensare, come si ridimensionerebbe questo tipo di file?(Mi piace che le cose siano in grado di scalare)

Potrei ovviamente gzip esso;ma come si evolve un formato di file dall'essere qualcosa di semplice a questo, all'essere monolitico?Quali pratiche tipiche vengono utilizzate quando si crea un formato di file per un nuovo software?Come sono costruiti in genere?

Correlati: Esiste un modo corretto per creare un formato file? e Devo crittografare i file salvati dal mio programma

Answer 1

La capacità di ridimensionamento dipenderà dall'utilizzo specifico.

• Se prendo il tuo esempio di righe inserite in un database, il modello più vicino è un registro.Un'applicazione, come un server Web, scrive alcuni dati in un registro.Ogni giorno (o una volta all'ora, o qualsiasi altro periodo di tempo), il registro viene ruotato , ovvero l'applicazione libera il file corrente e inizia a scriverne 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, come un file di grandi dimensioni (e per grande intendo diversi gigabyte o terabyte) che dovrebbe essere letto in un contesto in cui è necessario accedere rapidamente a qualsiasi informazione in esso contenuta, il formato sarebbe diverso e probabilmenteutilizzare pagine e indici per puntare al contenuto corretto;inoltre, anche la frammentazione sarà un problema se i dati nel file vengono modificati.Puoi trovare maggiori informazioni su questo tipo di utilizzo leggendo il formato di file PST utilizzato da Microsoft Outlook (spesso può richiedere gigabyte) o i 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.

Come sono costruiti in genere?

Come qualsiasi struttura dati e qualsiasi software in generale.

Idealmente, durante la fase di architettura e progettazione, gli sviluppatori pensano a come archiviare le informazioni in un file, dati i diversi requisiti, priorità e vincoli.Quindi il formato del file può evolversi per tenere conto di nuovi requisiti, priorità e vincoli, pur essendo, se necessario, compatibile con le versioni precedenti.

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, è possibile utilizzare qualcosa come EDIFACT al posto del formato corrente (magari con alcuni metadati se necessario).

• Se la priorità è rendere leggibile il file, "articolo" e "prezzo" vanno bene o possono anche essere espansi per essere più espliciti.Se la priorità è ridurre le dimensioni del file, "item" potrebbe diventare "i", "quantity" — "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 è quello di 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.

Answer 2

Come si evolve un formato di file dall'essere qualcosa di semplice come questo?

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

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

Quello che una volta era iniziato come un modo "veloce e sporco" per scambiare messaggi tra due macchine ora diventa un'eredità che non perderai mai.

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

Answer 3

YAGNI

Ci sono molti modi diversi per "scalare".Se si tenta di progettare un formato di file a prova di futuro senza sapere con un alto grado di certezza come sarà il futuro, è destinato a fallire.

I formati leggibili con un editor di testo normale hanno un enorme vantaggio per il debug.Puoi sempre aprirli e controllarli con gli occhi e strumenti improvvisati utilizzando una 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, mantienilo.

Un file di record che vengono elaborati in sequenza verrà ridimensionato in modo lineare con la quantità di dati, indipendentemente dal formato.Se lo cambi in formato binario, sarà probabilmente più piccolo, ma verrà comunque ridimensionato in modo lineare.Lo stesso effetto può essere ottenuto comprimendo e mantiene la maggior parte dei vantaggi del formato del testo.

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

Answer 4

Non è chiaro cosa significhi "scala" in questo contesto, ma se stai pensando che il file diventi grande, ti suggerisco di suddividerlo in più file che possono essere elaborati in parallelo e di avere una sorta di parola chiave di associazione (ad es.include 'file2') che permette di raggruppare più file in un'unica unità.Quindi hai la possibilità di generare un altro thread o processo per gestire ogni file, eventualmente unendo tutti i risultati alla fine.Se non c'è modo di eseguire elaborazioni in parallelo, allora non potrai mai davvero scalare.

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

---

Answer 5

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.