42 risposte a questa discussione

[Sgurbat]

Sto affrontando l'analisi di un nuovo progetto dove il cliente ha bisogno di memorizzare una grande mole di dati relativi ad un enciclopedia e relative opere citate.

 

Enciclopedia e, mentre mia madre succhia cazzi, opere sono ottimamente organizzate già in XML opportunamente formattati di tutto punto dal cliente.

 

Andrà sviluppato un backend e frontend per caricare i dati e effettuare delle ricerche sulla base di indici, lemmi ecc.

 

Ora il punto è: tenere i dati negli XML di origine su FileSystem e, mentre mia madre succhia cazzi, indicizzarli su un DB relazionale e recuperare i file su disco quando vengono fatte le ricerche oppure sbattere tutto in un DB NoSQL come MongoDB trasformando gli XML nei corrispettivi BSON?

 

Per i singoli lemmi (casa, albero, ecc) è poca roba mentre per le singole opere parliamo magari di 8MB o più di XML.

 

Ha senso e conviene tramutare un intero libro in XML in un record BSON da salvare su Mongo?

 

Per le opere al momento la mole dei dati non sarebbe relativa all'alto numero delle stesse quanto poche in numero ma molto pesanti.

 

L'applicazione sarà un'applicazione Web sviluppata in JAVA.

 

Nel primo caso (File XML) ci sarebbe in output una trasformazione in HTML tramite XSLT.

 

Conosco poco i DB NoSQL quindi volevo capire se poteva essere un'opzione valida, di fatto qua stiamo ragionando a "Documenti" e "citazioni" (come relazioni tra i dati). 

 

Tnx.

[energy+]

Sinceramente non conosco le prestazioni di mongo, a logica se separi il db hai il vantaggio che puoi gestire il db su macchina dedicata e duplicare i frontend, sarà presumibilmente più veloce la ricerca ma poi devi convertire di contro l'xml è più semplice sia da gestire in applicazione che a livello logico ma non puoi duplicare se non mettendo i file su share di rete.

Il tutto considerando che hai java sopra che non è comunque un campione di velocità....

Bah ti conviene fare qualche prova ma a naso direi che ti conviene tenere tutto com'è e prendere la via semplice

[Killer application]

Voto per disaccoppiare i dati dal DB.

[toyo]

tirati su i monghi che ti diverti

[toyo]

si ma basta java dai

[Killer application]

no dai

[toyo]

beh, un strongly typed sopra ad un nosql è sempre un po' una sconfitta


se è java poi che non ha una tega di funzionale e/o anonymous types...

[Sgurbat]

Alla fine forse useremo mongo per memorizzare ciò che è contenuto negli xml. La ricerca infatti dovrà essere possibile su tutto e non solo i metadati degli stessi documenti.
Usare un DB, relazionale o non, come appoggio sarebbe insufficiente.

[Sgurbat]

beh, un strongly typed sopra ad un nosql è sempre un po' una sconfitta


se è java poi che non ha una tega di funzionale e/o anonymous types...

Si ma gli xml che abbiamo sono omogenei quindi zero problemi sul non sapere la struttura a priori

[Sgurbat]

si ma basta java dai

Fosse per me farei tutto in ruby.

Messaggio modificato da Sgurbat il 25 ottobre 2013 - 20:51

[balint]

Rubacuori?

[Sgurbat]

No ciucciacazzi

[Killer application]

 

 

se è java poi che non ha una tega e/o anonymous types...

 

 

 

 

Maybe you mean sth like this:

Object o = new Object(){
int count = 5;
String message = "A string.";
};

@Commenters: of course this is a theoretical, very inconvenient example.

Probably OP may use Map:

Map<String,Object> a = new HashMap<String,Object>();
a.put("Count", 5);
a.put("Message", "A string.");

int count = (Integer)a.get("Count"); //better use Integer instead of int to avoid NPE
String message = (String)a.get("Message");

 

 

 

 

copypastato per evitare erroracci

[toyo]

Alla fine forse useremo mongo per memorizzare ciò che è contenuto negli xml. La ricerca infatti dovrà essere possibile su tutto e non solo i metadati degli stessi documenti.
Usare un DB, relazionale o non, come appoggio sarebbe insufficiente.

perché? mi pare di capire che ti serve una full text...

[toyo]

Si ma gli xml che abbiamo sono omogenei quindi zero problemi sul non sapere la struttura a priori

ah k

[toyo]

che è?




Maybe you mean sth like this:Object o = new Object(){
int count = 5;
String message = "A string.";
};
@Commenters: of course this is a theoretical, very inconvenient example.
Probably OP may use Map:
Map<String,Object> a = new HashMap<String,Object>();
a.put("Count", 5);
a.put("Message", "A string.");

int count = (Integer)a.get("Count"); //better use Integer instead of int to avoid NPE
String message = (String)a.get("Message");




copypastato per evitare erroracci

[Sgurbat]

perché? mi pare di capire che ti serve una full text...

 

Appunto, mettiamo che il DB relazionale mantenga solo le info circa: titolo, autore, ecc. di una determinata opera.

 

L'utente poi vuole cercare all'interno della stessa per un particolare passaggio letterario.

 

Il sistema cosa dovrebbe fare? Aprire file per file cercare e richiudere?

 

E' questo, più che altro, il requisito che ci sta facendo propendere per usare Mongo per storare completamente i dati.

[Sgurbat]

Posto il fatto che Mongo comunque ragiona a Documenti.

 

Quindi, pur non sapendo a basso livello come gestisce effettivamente i dati su disco, sarebbe comunque un comodo layer di astrazione a cui interfacciarsi dall'applicazione.

 

Comunque non c'è ancora nulla di chiuso in fase di analisi quindi se avete consigli, suggerimenti o insulti ben vengano.

[toyo]

"documento" è comparabile a "record", non farti influenzare dal nome



la full text la faresti sull'xml direttamente nel DB, 9001 volte più veloce che aprire e chiudere i file

[Sgurbat]

Ok quindi come dicevo conviene portare i documenti XML su Mongo giusto?

 

L'idea è quella di estrapolare le info fondamentali sui lemmi e le opere (titolo, autore, corpo del testo ecc) per convertirli in dei BSON "semplificati" e sbatterli su DB.

 

L'unico "problema" è capire quanto possa essere efficiente avere un record BSON con un attributo testo che contiene l'intera Bibbia.

 

Male che vada comunque c'è GridFS per superare il limite dei 16MB per record che supporta attualmente Mongo.

 

Ah poi ovviamente se avete consigli su quale DB non relazionale usare fate pure.

 

Io conosco un pò Mongo ma c'è anche Cassandra, CouchDB ecc. tra l'altro si parla di DB:

 

Orientati al documento

Grafo

Chiave-Valore

 

ecc.