Modo semplice per archiviare e recuperare oggetti in Java senza utilizzare un DB relazionale? [chiuso]

Question

Conosci un " facile " modo per archiviare e recuperare oggetti in Java senza utilizzare un DB / ORM relazionale come Hibernate ?

[ Nota che non sto prendendo in considerazione la serializzazione così com'è per questo scopo, in quanto non consentirà di recuperare oggetti arbitrari nel mezzo di un grafico a oggetti. Né sto prendendo in considerazione DB4O a causa della sua licenza restrittiva. Grazie. ]

" Facile " significato: non dover gestire dettagli di basso livello come coppie chiave / valore per ricostruire un grafico a oggetti (come con BerkeleyDB o cache tradizionali). Lo stesso vale per la ricostruzione di oggetti da un DB orientato al documento o alla colonna (CouchDB, HBase, ..., persino Lucene).

Forse ci sono progetti interessanti là fuori che forniscono uno strato di integrazione tra i sistemi di archiviazione citati e il modello a oggetti (come ORM sarebbe per RDBMS) di cui non sono a conoscenza.

Qualcuno usa con successo quelli in produzione o sperimenta strategie di persistenza diverse dai DB relazionali? E i negozi RDF?

Aggiornamento : ho trovato un articolo molto interessante: Un elenco di negozi con valori-chiave distribuiti

Answer 1

Suppongo di aver trovato una sorta di risposta alla mia domanda.

Ottenere la mentalità paradigmatica orientata ai documenti non è un compito facile quando hai sempre pensato ai tuoi dati in termini di relazioni, normalizzazione e join.

CouchDB sembra adattarsi al conto. Potrebbe ancora fungere da archivio di valori-chiave, ma le sue grandi capacità di interrogazione (mappa / riduzione, visualizzazione delle regole di confronto), disponibilità alla concorrenza e accesso HTTP indipendente dalla lingua lo rendono la mia scelta.

L'unico inconveniente è dover definire e mappare correttamente le strutture JSON sugli oggetti, ma sono fiducioso che troverò una soluzione semplice da utilizzare con i modelli relazionali di Java e Scala (e mi preoccuperò della memorizzazione nella cache in seguito, poiché la contesa è spostato dal database). La terracotta potrebbe ancora essere utile, ma certamente non come in uno scenario RDBMS.

Grazie a tutti per il vostro contributo.

Answer 2

• Serializzazione di oggetti (aka memorizzazione cose in un file)
• Hibernate (utilizza un database relazionale ma è abbastanza trasparente per lo sviluppatore)

Suggerirei Hibernate perché tratterà della maggior parte dei brutti dettagli che impantanano gli sviluppatori quando usano un database pur consentendo le ottimizzazioni che sono state apportate al software del database nel corso degli anni.

Answer 3

NeoDatis sembra interessante. È concesso in licenza ai sensi della LGPL, quindi non così restrittivo come il GLP vero e proprio.

Dai un'occhiata al tutorial di 1 minuto per vedere se funzionerà per le tue esigenze.

Answer 4

Vorrei raccomandare XStream che semplicemente prende i tuoi POJO e crea XML da loro in modo che tu possa archiviarlo su disco. È molto facile da usare ed è anche open source.

Answer 5

Consiglierei Hibernate (o, più in generale, OR-mapping) come Matt, ma c'è anche un RDBMS sul backend e non sono così sicuro di cosa intendi per

  

... senza usare un DB relazionale? ...

Sarebbe anche interessante sapere di più sull'applicazione, perché OR-mapping non è sempre una buona idea (prestazioni di sviluppo vs. prestazioni di runtime).

Modifica: ho imparato a breve sulla terracotta e c'è una buona discussione su StackOver qui sulla sostituzione di DB con quello strumento. Ancora sperimentale, ma vale la pena leggere.

Answer 6

Penso ancora che dovresti considerare di pagare per db4o .

Se vuoi qualcos'altro, aggiungi " con una licenza in stile MIT " al titolo.

Answer 7

Guarda i commenti su Prevayler su questa domanda . Prevayler è un wrapper transazionale attorno alla serializzazione degli oggetti - approssimativamente, usa gli oggetti in java normale e persisti su disco attraverso l'API java senza sql, un po 'più ordinata rispetto alla scrittura della tua serializzazione.

Avvertenze: con la serializzazione come meccanismo di persistenza, si corre il rischio di invalidare i dati salvati quando si aggiorna la classe. Anche con una libreria wrapper probabilmente vorrai personalizzare la gestione della serializzazione / deserializzazione. Aiuta anche a includere serialVersionUID nella classe in modo da ignorare l'idea della JVM di quando la classe viene aggiornata (e quindi non è possibile ricaricare i dati serializzati salvati).

Answer 8

Hmm ... senza serializzazione e senza una soluzione ORM, ritornerei a una sorta di implementazione basata su XML? Dovresti comunque progettarlo attentamente se vuoi estrarre solo alcuni degli oggetti dal grafico degli oggetti - forse un file diverso per ogni oggetto, dove le relazioni degli oggetti sono referenziate da un URI a un altro file?

Avrei detto che non era "facile". perché ho sempre trovato che progettare la mappatura di XML su oggetti richiedeva un po 'di tempo, ma sono stato davvero ispirato da una conversazione su Apache Betwixt che mi fa sperare di essere appena fuori moda e ora sono disponibili soluzioni più semplici .

Answer 9

Terracotta fornisce un archivio oggetti su disco persistente, altamente disponibile e altamente scalabile. Puoi usarlo solo per questa funzione, oppure puoi usare la sua vasta gamma di funzionalità per implementare un'applicazione completamente cluster, a tua scelta.

Terracotta:

• non rompe l'identità dell'oggetto dandoti l'interfaccia di programmazione più naturale
• non richiede la serializzazione
• cluster (e persiste) quasi tutte le classi Java (Maps, Locks, Queues, FutureTask, CyclicBarrier e altro)
• persiste gli oggetti su disco a velocità di memoria
• sposta solo i delta degli oggetti, offrendo prestazioni molto elevate

Ecco un case study su come gnip utilizza Terracotta per in -memoria persistenza - nessun database. Gnip accoglie tutti gli eventi su Facebook, Twitter e simili e li produce per i consumatori in modo normalizzato. La loro soluzione attuale sta elaborando oltre 50.000 messaggi / secondo.

È OSS e ha un alto grado di integrazione con molti altri framework di terze parti tra cui Spring e Hibernate.