2012-05-15 11 views
8

Qual è il sovraccarico dell'utilizzo di Java ORM per MongoDB, o è meglio andare al livello di base del driver per leggere o scrivere?Qual è il sovraccarico di Java ORM per MongoDB

Aggiungeremo Mongo DB per uno dei nostri requisiti.

Ci sono un paio di strumenti di mappatura Java ORM per Java
-morphia
-Spring-dati
- others

Morphia ultima versione è stata rilasciata più di un anno fa
ma i dati primavera è attivamente mantenuto. Quale dovrebbe essere usato se sto per iniziare ora,

+1

La "R" in ORM non sta per "relazionale"? – duffymo

+1

Sì, il suo supporto per l'Object/Relational Mapping, tipicamente utilizzato con database relazionali ma genericamente può essere utilizzato con qualsiasi tipo di database. – mtariq

+0

@duffymo in questo caso Morphia in realtà * fa * relazioni tra le collezioni. Alcuni dei wrapper Ruby hanno caratteristiche simili. –

risposta

11

L'uso di ORM riduce le prestazioni ma accelera lo sviluppo. C'è un compromesso qui.

Per gli strumenti ORM, Morphia è il più stabile. Here puoi trovare il confronto tra Morphia e Basic Mongo Driver per le loro prestazioni.

+2

Un confronto delle prestazioni migliore [collegamento] (https://groups.google.com/forum/?fromgroups#!topic/morphia/kGCF2I3ZKRU) – mtariq

+0

Il collegamento aggiunto nella risposta non sembra più disponibile. – sakura

4

C'è un bel po 'di cose da dire qui in generale. Venire con i benchmark è abbastanza difficile in quanto non è possibile testare realmente le prestazioni senza testare anche l'installazione di MongoDB. Quindi si può praticamente modificare e sintonizzare l'ambiente per ottenere i risultati desiderati.

Oltre a ciò è necessario distinguere tra prestazioni di lettura e scrittura. Soprattutto le scritture sono pesantemente influenzate dal WriteConcern utilizzato. Pertanto, quello che potrebbe essere un overhead del 50% in uno scenario WriteConcern.NONE può facilmente ridursi a meno del 5% con un WriteConcern.SAFE.

Sì, c'è sicuramente un sovraccarico in qualsiasi implementazione ODM poiché l'Object < ->DBObject mapping deve ispezionare l'oggetto get e impostare i valori di solito tramite reflection. Quindi, un punto cruciale per IMHO è la possibilità di collegare convertitori personalizzati codificati manualmente che potreste voler fornire per gli oggetti critici per le prestazioni. Per i dati primaverili, la semplice registrazione di una EntityInstantiator personalizzata che fa new Person(…) invece di lasciare che quella di default faccia la sua riflessione, la magia offre un enorme incremento delle prestazioni.

squadra La primavera dei dati ha un build istituito una performance accumulo ponderazione di un'istanza OTS MongoDB per operazioni di scrittura contro diversi WriteConcern s, e la lettura attraverso il driver pianura, il MongoTemplate e il repository di astrazione. I numeri devono essere presi con un pizzico di sale perché a volte mostrano che i repository leggono i dati più velocemente dei modelli che hanno influenzato dall'infrastruttura in qualche modo poiché è praticamente un livello sopra il modello ma non lo fa t davvero aggiungere qualsiasi cache.

+1

Pensi che i dati primaverili possano essere più veloci della morfina? – mtariq

+1

Certo che può. Ma ovviamente la morfina può anche essere più veloce di Spring Data. Penso che il punto cruciale sia - come descritto sopra - in che misura sei in grado di codificare manualmente la mappatura dell'oggetto su DBObject per i tipi che risultano essere strozzature per impedire che l'infrastruttura di mappatura generica influisca troppo sulle prestazioni. Se sei bloccato con un approccio di mappatura non personalizzabile, non va bene. –

Problemi correlati