Schema di archiviazione dei dati binari (salvataggio dei file caricati dall'utente)

Question

Schema di archiviazione dei dati binari (salvataggio dei file caricati dall'utente)

#1 da (3 voti)

2

Nella nostra app stiamo attualmente salvando dati binari nel database (terribile, lo so, ma si tratta di materiale legacy e non è stata una mia decisione). Stiamo provando a migrare questi dati su un dispositivo esterno e sto cercando di trovare uno schema per salvare questi file.

Abbiamo più inquilini, mi piacerebbe avere una directory per inquilino. Il mio schema è quello di costruire il percorso usando le prime tre lettere dell'inquilino. Quindi se avevi un tenant chiamato apple , i suoi file sarebbero a /a/p/p/apple . All'interno di queste directory, salverò i file. Per i file, desidero generare un nome alfanumerico casuale di 6 caratteri (solo caratteri minuscoli per il momento a causa di motivi interni). Quindi se generiamo un nome di file chiamato 6a8jxo , verrà memorizzato come <tenant>/6/a/6/6a8jxo . Con questa strategia, ogni inquilino può avere un massimo di circa 916 miliardi di file unici (non che stiamo tentando di salvarne così tanti), con un massimo di 46.656 file per directory. Se scelgo un nome di 5 caratteri, avremo un massimo di 60,5 miliardi di file unici con 1,296 file per directory.

Ci sono degli svantaggi in questo approccio? Mi rendo conto che certe directory possono contenere solo uno o due file, ma nella mia mente non è un problema enorme.

Il mio collega non vuole farlo in questo modo; vuole usare un campo autoincrementato nel database e quindi basare la struttura della directory sul valore esadecimale (presumo 32 bit) anziché utilizzare l'inquilino. Con la sua strategia il valore esadecimale verrebbe utilizzato come segue: il file verrà archiviato nella directory situata in <tenant>/aa/bbb dove aa è i primi due caratteri (i più significativi nibble) del valore esadecimale e bbb è il i prossimi tre. Il suo ragionamento è che vuole solo creare nuove directory quando si riempie invece di avere numerose directory parzialmente riempite.

Questo approccio introduce numerose difficoltà sul lato del codice delle cose e non vedo di avere directory completamente piene come argomento che giustifica lo sforzo extra richiesto per farlo.

Ci sono altre strategie o approcci che non ho considerato?

java file-storage

posta Vivin Paliath 10.12.2013 - 19:16

fonte

1 risposta

Leggi altre domande sui tag java file-storage

La garbage collection di Python mi ha reso difficile Compressione JavaScript e memorizzazione nella cache delle risorse

score 3 · Accepted Answer

L'idea di hashing delle directory (da non confondere con la generazione di un hash del nome del file) e quindi di suddividerla in più directory è buona. Se è multi-tenant, probabilmente hai un id di database per i client. Ed è una buona idea tenere traccia dell'esistenza dei file nel tuo db con un ID univoco (incremento automatico o altro). Quindi potresti semplificare il tuo approccio e fare qualcosa del tipo:

/(client id)/(thousands)/(file-id).txt

crea una singola directory per il titolare, quindi genera il percorso del file in base all'ID del database univoco del file, raggruppandoli in migliaia o decine di migliaia. Quindi il file che ha un ID di riga autoincrementante di 53445 per il titolare numero 8 potrebbe apparire come

/8/53/53445.txt

Se è necessario supportare un'impostazione più distribuita, è possibile utilizzare un uuid anziché un campo autoincrement durante il tracciamento dei file. Non utilizzerei il nome del client come parte del percorso, perché i nomi cambiano, e potreste finire per incontrare un cliente con un carattere nel nome che non può essere usato come parte di un nome di file - basta saltare tutta quella complessità e usa l'id del database.

La rottura dei file per inquilino potrebbe non essere necessaria tecnicamente (di solito non lo farei), ma potrebbe esserti d'aiuto se devi fornire quei file al client. Se è saggio farlo in realtà dipende dalla natura della tua applicazione.