Domanda

Ho un'idea per una semplice applicazione che monitorerà un gruppo di cartelle e indicizzerà tutti i file che trova.Una GUI mi consentirà di taggare rapidamente nuovi file e di spostarli in un unico database per l'archiviazione e fornirà anche un meccanismo semplice per interrogare il db per tag, nome, tipo di file e data.Al momento ho circa 100+ GB di file su un paio di dischi rigidi rimovibili, il database sarà almeno altrettanto grande.Se possibile, vorrei supportare la ricerca full-text dei documenti binari e di testo incorporati.Questa sarà un'applicazione per utente singolo.

Non sto cercando di iniziare una guerra tra DB, ma quale DB open source funzionerà meglio per me?Sono abbastanza sicuro che SQLLite sia fuori discussione ma potrei sbagliarmi.

È stato utile?

Soluzione

Sto ancora cercando questa opzione per uno dei miei progetti, ma CouchDB potrebbe valere la pena dare un'occhiata.

Altri suggerimenti

Perché archiviare i file nel database?Memorizza semplicemente i tuoi metadati e un nome file.Se per qualche motivo è necessario copiarli in una nuova posizione, è sufficiente farlo come copia del file system.

Una volta rimosso il contenuto del file, qualsiasi database competente sarà in grado di gestire i metadati per alcune centinaia di migliaia di file.

La mia preferenza sarebbe quella di archiviare il documento con i metadati.Uno dei motivi è l’integrità relazionale.Non è possibile spostare facilmente i file o modificare i file senza che l'azione venga intermediata dal db.Sono sicuro di poter gestire questi problemi, ma non è così pulito come vorrei e la mia esperienza è stata che la maggior parte dei fornitori è in grado di gestire enormi quantità di dati binari nel database al giorno d'oggi.Immagino che mi chiedessi se PostgreSQL o MySQL presentassero evidenti vantaggi in queste aree, ho familiarità principalmente con Oracle.Comunque grazie per la risposta, se il DB sa dove si trova il file esterno sarà anche facile importarlo in un secondo momento, se lo desidero.Un altro aspetto della domanda era se fosse più facile lavorare con uno dei due database quando si utilizza Python.Presumo che sia un lavaggio.

Odio sempre rispondere "non farlo", ma faresti meglio a indicizzare con qualcosa come Lucene (PyLucene).Questo e la memorizzazione dei percorsi nel database anziché del contenuto del file è quasi sempre consigliabile.

In aggiunta a ciò, nessuno di questi motori di database memorizzerà i LOB in uno spazio dati separato (saranno incorporati nello spazio dati della tabella), quindi anche tutti questi motori dovrebbero funzionare quasi allo stesso modo (beh, tranne sqllite).È necessario passare a Informix, DB2, SQLServer o altri per ottenere questo tipo di gestione degli oggetti binari.

Praticamente ognuno di essi funzionerebbe (anche se SQLLite non è stato pensato per essere utilizzato in un ambiente multiutente simultaneo, il che potrebbe essere un problema...) poiché non vuoi indicizzare il contenuto effettivo dei file.

L'unico fattore limitante è la dimensione massima del "pacchetto" del DB specificato (per pacchetto mi riferisco a una query/risposta).Di solito questo limite è di circa 2 MB, il che significa che i tuoi file devono essere più piccoli di 2 MB.Naturalmente si potrebbe aumentare questo limite, ma l'intero processo è piuttosto inefficiente, dato che ad esempio per inserire un file bisognerebbe:

  • Leggere l'intero file in memoria
  • Trasforma il file in una query (che di solito significa codificarlo esadecimale, raddoppiando così la dimensione dall'inizio)
  • Esecuzione della query generata (che di per sé significa, per il database, che deve analizzarla)

Sceglierei un semplice DB e i file associati archiviati utilizzando una convenzione di denominazione che li renda facili da trovare (ad esempio in base alla chiave primaria).Naturalmente questo design non è "puro", ma funzionerà molto meglio ed è anche più facile da usare.

perché stai perdendo tempo emulando qualcosa che il filesystem dovrebbe essere in grado di gestire?più spazio di archiviazione + grep è la tua risposta.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top