The Bit Zesty Blog - Ruby on Rail web development, design, social media and business
About Me

The Bit Zesty Homepage

We Build Bespoke Web Applications.

We are experts in Ruby on Rails development. We're also agile and this helps us ensure your project is launched on time and on budget.

My Other Sites
 
Contributors
Tags
Get Updates
Filed under

mongodb

See all posts on posterous with this tag ยป

Document Stores vs Relational Databases for Domain Modeling

I am quite excited about the rising popularity of document stores, we have been using MongoDB and CouchDB for some time now, both for internal and client projects. Both databases are similar (although built on different technologies) as they are schema-free, scalable, document-oriented.

The concept of a document database isn't new. It was pioneered by MUMPS in the 1970s for health-care and financial applications and by IBM in 1989 with the Lotus Notes Database. It's interesting to see the main concepts behind these legacy databases evolve and reemerge in new open-source projects.

Benefits of document stores
The NoSQL argument is that data should not be stored only in SQL databases, but should utilize other forms of data-store when they are better suited for the domain model. Speed and scalability are just some benefits, but I believe that the ability to quickly and concisely model complex domains is main advantage.

Modeling a CRM
Let's take the example of a simple Customer Relationship Management system (CRM), to model a business card in a relational database you would have a number of tables, for example:
  • Contacts
  • Phone Numbers
  • Email Addresses
The data in each table would have to be joined together to display all the contact details. Even in this contrived example, the data model can quickly grow in complexity as you include more types of data.

This is where the power of a document store shines through, all the contact's information can be stored in a single document. Document stores are schema-free so you do not have to define all the possible data types, you can just add new data to the document if needed. See below for an example contact document which models the business card as it would appear in the real world:

Possible drawbacks
As with all things there is a trade off, these databases typically lack row-level database transaction and 'table joins' in order to achieve higher performance. The lack of joins is not a major issue as all the related information should be in one document. However, If you currently make heavy use of database transactions, migrating to a document store isn't a good idea.

With these drawacks in mind, you probably don't want to build a banking platform on-top of these databases, however for the vast majority of applications these constraints are not a problem.

Further Reading
My personal preference is currently MongoDB as it has better support for dynamic queries, but there isn't much between the two. Following on from my previous post on MongoDB with MongoMapper and Ruby on Rails I'll ether do a series of blog posts or a screen-cast on building a simple application with MongoDB and Rails 3. 

Loading mentions Retweet
Filed under  //  mongodb   nosql  
Comments (0)
Posted 1 month ago by Matthew Ford 

MongoDB with MongoMapper and Ruby on Rails

I'm sure we've all heard the pros & cons of the NoSQL movement so these will not be covered here. I've been experimenting with a number of alternatives to RDBMS for a while such as CouchDB, TokyoCabinet, Redis and recently MongoDB.

MongoDB (from "humongous") is a scalable, high-performance, open source, schema-free, document-oriented database. Written in C++, MongoDB features:

MongoDB bridges the gap between key-value stores (which are fast and highly scalable) and traditional RDBMS (which provide structured schemas and powerful queries).

- from the MongoDB site.

The reason I've settled on MongoDB is (for me) it's been the most useful, more so than straight KV stores such as Redis and Tokyo. Technically CouchDB is very similar to MongoDB being a document store too, however MongoDB seems to 'gel better' (that's a technical term).

To be able to use this MongoDB goodness in my Rails app, I'm making use of the MongoMapper gem as it's the most popular one (github forks and watchers metric). There are other ORMs which you can use with MongoDB, Mongoid seems like a good alternative and the rest are documented here: http://www.mongodb.org/display/DOCS/Ruby+Language+Center.

Installation

Download and run mongod http://www.mongodb.org/display/DOCS/Downloads

Install the gems:

Configure your environment, and remove AR:

Add a config file for your database:

And add an initializer to setup MongoMapper and friends:

Getting stuff done

Now I know what you might be thinking, 'oh no not another ORM all my favorite gems won't work!', that is not the case! (*in some cases)

Usage

These Models are stripped down but you get the idea. Let say you're using Devise, then your User model could look like this:

And if that user had comments the model could look like:

These are just to help kick-start your app development, for more complete examples see the open source apps and http://www.mongodb.org/display/DOCS/MongoDB+Data+Modeling+and+Rails :

Open Source Ruby Applications using MongoDB (and MongoMapper)

NewsMonger - A simple social news application demonstrating MongoDB and Rails


Oupsnow - A bugtracker in Rails/MongoMapper
http://github.com/shingara/oupsnow/

Watchtower - An example app built with Sinatra, Mustache and MongoDB
http://github.com/kneath/watchtower/

Shapado - stackoverflow like question and answer site: 
http://gitorious.org/shapado/shapado

mmmblog - a blogging engine by the same guys as Shapado (http://blog.ricodigo.com/)
http://gitorious.org/mmmblog

More at http://wiki.github.com/jnunemaker/mongomapper/projects-using-mongomapper

Pro Tips

  • MongoMapper uses a fork of the validatable gem - which has some differences with AR validations
  • Denormalization is needed to reduce round-trips to the DB
  • Change how you think of your data models - this is closer to an object store
  • The finders have nifty options checkout http://wiki.github.com/jnunemaker/mongomapper/whats-new (0.5.7)
  • Don't be afraid to drop down and use to the Ruby MongoDB driver directly http://www.mongodb.org/display/DOCS/Ruby+Tutorial
  • Keep an eye out on the github commit feed as it's a bit of a moving target still

Summary
No migrations (yes!), storing arrays and hashes as attribute keys (sweet), and inplace updates (ftw). We're not going to use MongoDB to build transactional systems any time soon, but for the majority of web applications it's a perfect fit.


Bit Zesty - Ruby on Rails Development (and MongoDB) UK

Loading mentions Retweet
Filed under  //  development   mongodb   nosql   ruby on rails  
Comments (9)
Posted 2 months ago by Matthew Ford