Data Storage Architecture: Memorizzazione di dati gerarchici (JSON / BSON)

1

Supponiamo di avere il concetto di archiviazione gerarchico di "Foo". "Foo" contiene un id, vari valori e zero a molti "Foo". Ovviamente, a sua volta, gli elementi figli possono contenere zero a molti Foos. I dati sono puramente gerarchici: un dato Foo apparterrà a zero a uno Foos, e quindi non c'è mai una preoccupazione di più genitori.

I dati sono memorizzati in una sorta di formato dati (JSON, BSON, XML, ecc.) all'interno di una tecnologia di archiviazione (come MongoDB, file flat, ecc.). Supponiamo che entrambi siano sconosciuti, quindi è auspicabile un'architettura agnostica del sistema.

Quali principi / scelte di architettura detterebbero se gli oggetti dovessero essere archiviati gerarchicamente (direttamente nel supporto di memorizzazione con bambini esistenti come bambini effettivi) o in modo piatto, con tutti i genitori e i bambini allo stesso livello (e riferimenti ai bambini tramite id) .

La mia inclinazione è che l'archiviazione degli oggetti nel modello gerarchico naturale è l'ideale, tuttavia sono incerto se questo è probabilmente un problema di prestazioni (se è necessario trovare un bambino specifico, che richiederebbe una sorta di ricerca attraverso la struttura ad albero?).

Ho visto le API Web esposte in entrambi i modi e gli archivi di codice che si occupano di entrambi i moduli. Tuttavia, non riesco a trovare i punti decisionali / le questioni di architettura formalmente trattate.

    
posta Nex Terren 23.05.2016 - 18:30
fonte

1 risposta

2

Penso che due aspetti da considerare siano:

  1. (e ti viene fatto riferimento sopra) - hai bisogno di trovare nodi figli? In tal caso, si consiglia di evitare la memorizzazione di gerarchie di dimensioni considerevoli e invece di memorizzare il singolo Foo s in modo da renderli immediatamente ricercabili. Ciò potrebbe influire sui tempi di costruzione / recupero degli alberi
  2. Vuoi spostare i bambini tra gli alberi? Se lo fai, di nuovo, vorrei cercare di tenerli separati altrimenti dovrai cercarli e poi staccarli e riassegnarli a un nuovo albero

Penso che le API per i clienti riflettano ciò che i client vogliono fare, piuttosto che il meccanismo di archiviazione sottostante. Capire cosa vogliono i clienti (come sopra, vogliono cercare, ricostruire ecc.) Informerà ulteriormente la tua decisione.

Nota anche che sei completamente indeciso sul meccanismo di archiviazione sottostante. Un database orientato ai documenti avrà molto caratteristiche diverse da una soluzione di file flat. Pertanto, dovresti considerare l'API rivolta al cliente separatamente dalla tecnologia sottostante e lasciare che i requisiti del cliente informino i tuoi requisiti non funzionali.

    
risposta data 23.05.2016 - 19:08
fonte

Leggi altre domande sui tag