CODEWITHSUNDEEP
mongodbarchitecturecouchdbdatabasenosql
Kevin Lawrence
Kevin Lawrence

Reputation: 748

Is a document-oriented DB appropriate for this use case?

I have a large, complex, legacy relational database containing our user data. I want to build an application that will segment user populations by various criteria (show me everyone who weighs more than 200 pounds and wears a red shirt ). Queries will be composed from predefined, parameterized predicates (think of the message rules UI in outlook or gmail). Completely ad-hoc queries will be rare.

Building SQL queries against the source data is impractical because of the complexity of the legacy schema.

A first, naive, idea might be to denormalize the data to be used for segmentation into a very wide table in the RDBMS:

id  | hat size | shirt color | weight | ....
123 | 7        | blue        | 175    | 
456 | 6        | red         | 205    |

But that's not too appealing because the data will be sparse and the columns will vary quite often (weekly?). Schema changes are logistically difficult in my environment.

I could further normalize the table to a simple key/value table but, at that point, NoSQL becomes interesting.

So here's my question:

Would a document-oriented db like MongoDB or CouchDB be a good fit for this use case?

I don't have massive amounts of data (10s of millions of rows, 300 or so columns in the hypothetically denormalized table). Writes are fairly infrequent (10,000 per day). Queries would happen several times a day and response times will need to be in seconds.

I've spent the last couple of days reading up on the various approaches to NoSQL and document-oriented DBs seem most appropriate to me. Feel free to suggest a better approach.

Bonus question _Do the benefits of a document db justify the overhead of introducing a new technology into our data centers?_

I mean, I could probably satisfy the performance requirements with our existing relational database just fine but I am interested to dip my toe in the NoSQL waters because I have other applications down the line where a document-oriented database would really pay-off and I'd like to get my feet wet with a simple application first.

Upvotes: 4

Views: 658

Answers (1)

Ciaran Archer
Ciaran Archer

Reputation: 12446

We've started to 'mix in' NoSQL into our technology stack recently but I started with using capped collections via Mongo for simple logging to get a feel for the technology and to ensure it was robust and, importantly, to ensure that application code made sense when using NoSQL as the persistence later. How data and objects are persisted will change with this move and this needs to be factored in too.

There is very little that cannot be done with traditional methods, and you'll be sure it'll work as you expect too. It's low risk. But I too wanted to use it in a other future project so I dipped my toe in.

With any new technology, until it is proven in your language domain, and until you can prove you are comfortable with it, I would suggest you take 'baby steps' and work up to a project of the scale you are describing.

My the way, have you thought about using indexed views to 'normalise' your data and select from them? Just a thought.

I hope that helps!

Upvotes: 4

Related Questions