1

Should I store my relational data in MongoDB?

Any insight given my unique situation (outlined below) would be greatly appreciated!! As with any project, my resources are extremely limited. I'm looking to improve performance with as little cost as possible. :)

Background

  1. I'm working on a project with an expansive and complex data model.
    1. 84 primary tables
    2. 44 views into secondary tables
    3. 600k instances of the main item type
    4. 500,000,000+ tuples supporting the 600k main items
  2. The model is well normalized, and was well thought out.
  3. Many items have been denormalized for performance.
  4. Our data access layer uses Hibernate for ORM.

Problem Statement

Hibernate joins the 84 tables + 44 views together to map the primary data item together (I'll refer to the primary data item as THEObject). This construction is extremely expensive (single Oracle db node). It can take minutes to assemble THEObject and its children.

There is very little data shared between instances of THEObject. The data that is shared, is primarily read-only (Stuff like user data, references to general configuration...)

Saving THEObject is also extremely expensive.

As a side project, I created a set of beans to represent THEObject's data, copied data from an expensive instance of THEObject into the beans, then serialized the bean to XML using xstream. The conversion from THEObject to a bean, serialization of the bean, and storage of the XML representing the bean took a mere 26ms. (Nowhere near the 6minutes required to save THEObject back using hibernate over our relational representation). O.o

I think my application would be better served by a Document based database because the data I work with comes in 3 main chunk types (thinking collections), and the chunk representing THEObject shares data from 2 of the other main chunks, but doesn't share any of its own data amongst other instances of THEObject. This would allow me to read THEObject as a whole item with no joins or performance degradation related to normalized storage.

Is it reasonable to store my data in a document based database despite the fact that it's really relational data?!

Relevant Reading

Why should I use document based database instead of relational database?

Non-Relational Database Design

MongoDB vs. Cassandra

What is NoSQL, how does it work, and what benefits does it provide?

Community
  • 1
  • 1
Ultimadj
  • 83
  • 1
  • 1
  • 5
  • Article: [NoSQL Doesn't Mean Non-Relational](http://www.xaprb.com/blog/2010/03/08/nosql-doesnt-mean-non-relational/) – Ultimadj Aug 10 '12 at 15:12
  • yes, this sounds very reasonable. for validation, why not create a mongo instance, get the Java driver and try persisting the object there as a document. You can then look and see what your access patterns will be (reads) and what indexes you may need in addition to _id (primary key equiv) – Asya Kamsky Aug 10 '12 at 15:41
  • We're building up a prototype using Spring-data/JPA over Oracle and Mongo to create an ETL tool capable of migrating our data. I'll let you know what we find in terms of HBM vs Spring-data/JPA/Oracle vs Spring-data/JPA/MongoDB. :) – Ultimadj Aug 14 '12 at 03:39

0 Answers0