Struttura corretta Struttura NoSQL con focus sulla ricerca full-text

Question

Struttura corretta Struttura NoSQL con focus sulla ricerca full-text

#1 da (1 voti)

2

Sviluppo un'app con struttura ad albero (file di cartelle), su cui dovrei eseguire ricerche full-text con MongoDB. Ho fatto una ricerca sulle migliori pratiche di struttura ad albero e ho trovato questo grande articolo, ma ho ancora non posso decidere quale struttura DB si adatta alle mie esigenze.

Ho in mente i seguenti requisiti:

Dovrei essere in grado di eseguire ricerche full-text su singole cartelle, nonché tutto da utenti specifici
Le cartelle / i file devono essere condivisibili, quindi devo essere in grado di eseguire ricerche full-text su tutti gli elementi accessibili da un utente specifico

Ho pensato alle seguenti strutture.

Struttura 1

Fields of Users collection

 1. _id - objectid
 2. name - string

Fields of Folders collection

 1. _id - objectid
 2. name - string
 3. owner - objectid
 4. sharedWith - array of objectIds
 5. location - objectid of parent folder, null if in root
 6. createDate - datetime

Fields of File collection

 1. _id - objectid
 2. name - string
 3. owner - objectid
 4. sharedWith - array of objectIds
 5. data - string
 6. location - objectId of folder
 7. createDate - datetime

Quindi ecco le mie domande:

Devo utilizzare le strutture ad albero del modello con Referenze principali o Riferimenti figlio?
Devo usare 1 collezione per entrambi i file e le cartelle (con campo tipo) o dovrei separarli.
Vale la pena avere solo la raccolta di cartelle e nidificare i documenti al suo interno.

Queste sono state le mie domande più importanti, ho pensato che apprezzerei molto qualsiasi consiglio su come migliorare la struttura.

database nosql database-design mongodb

posta Deepsy 11.11.2014 - 23:56

fonte

1 risposta

Leggi altre domande sui tag database nosql database-design mongodb

DDD: memorizzazione di dati aggiuntivi con il modello problemi di prestazioni durante la sincronizzazione su una stringa internata

score 1 · Answer 1

Alcune risposte dipendono dal modo in cui si prevede che il sistema venga utilizzato. Senza sapere di più sulle vostre esigenze specifiche, la mia risposta è rivolta a un sistema generalmente flessibile che potrebbe funzionare bene con un'ampia varietà di casi d'uso, e non assumendo alcuna "scorciatoia" (come, limite assoluto sul numero di cartelle ecc.). Più in particolare:

Should I use model tree structures with Parent References or Child References?

Se si utilizzano riferimenti parent, quindi non importa quanti documenti possa avere una cartella, la dimensione dell'oggetto che rappresenta quella cartella rimarrà costante. Se si utilizzano riferimenti secondari, è necessario aggiornare l'oggetto documento della cartella ogni volta che viene creato un file: questo potrebbe introdurre problemi di sincronizzazione (2 file aggiunti alla stessa cartella nello stesso momento) o problemi relativi alle dimensioni del documento (si immagini cartella con un milione di file al suo interno). Tuttavia, avere una struttura così "normalizzata" renderà più costoso fare cose come "trovare tutte le cartelle / i file annidati in questa cartella radice" senza ulteriori ottimizzazioni.

Should I use 1 collection for both files and folders(with type field) or I should separate them.

I file system generalmente rappresentano sia i file che le cartelle come "nodi" che quindi contengono informazioni aggiuntive di tipo / dati. Suddividerli in raccolte separate ha senso solo se hai alcune operazioni molto specializzate che devi eseguire su questi set di dati (non riesci a pensare a niente di meglio di me) e avere collezioni separate potrebbe aiutarti.

Does it worth to have only folder collection and nest documents in it.

Perderai la possibilità di accedere ai singoli file senza caricare tutto il resto che si trova in quella cartella. Inoltre, questo sarà problematico se il numero di file per cartella aumenterà e gli oggetti cartella diventeranno molto grandi. Documenti separati che rappresentano "nodi" separati del tuo file system sono probabilmente la strada da percorrere.

Scambio: se sai che avrai una struttura di cartelle rigida con una manciata di cartelle e non troppi documenti, una struttura nidificata potrebbe essere conveniente.

Quando rispondi a domande come queste, è molto utile conoscere in anticipo tutte le tue esigenze, OPPURE se i requisiti sono vaghi, sviluppa un sistema generalmente flessibile che è facile (er) modificare / mantenere una volta che i requisiti sono compresi meglio.

In genere trovo utile porre domande estreme, come "cosa succede se ho un miliardo di cartelle con miliardi di file ciascuna?" o "cosa succede se ho una struttura che annida un miliardo di cartelle in profondità?". Domande del genere tendono a illuminare il problema in modo utile.