Hacker News Reader

Hacker News

Comment by megaman821 | Hacker News Reader

Parent Full thread

megaman821

I am never sure what niche MongoDB is supposed to fill.

If I want a large cluster to handle "big data" Riak or Cassandra seem to fit the bill better.

If I want speed Redis is great.

If I want a schema-less SQL-like (but not SQL) database, MongoDB?

View on HN

Well, you could look at their own use-cases document: http://www.mongodb.org/display/DOCS/Use+Cases

Personally, Mongo maps so nicely to Ruby that sometimes, I just use the regular driver rather than an ORM. A database that naturally understands hashes and arrays is lots of fun.

Also, it seems like with Mongo, I can often design most of my pages to need just one query, and therefore they're crazy fast. This might be possible with other NoSQL stores too, and I'm trying to get more experience with more of them.

In my admittedly limited experience with mongo, it felt like they were designing the ultimate database for the web. Not in a "web-scale" sort of way, more in a swiss army database for the web dev way. This came to me when I wanted to do location queries on a db. Most people using standard DBs do this with PostGIS for postgres, which is incredibly powerful and accurate. But mongoDB supports the "find shit near me with good enough accuracy" query that 90% of people want to run right now.

I was able to make a simple test page that told you the IP of the previous visitor who was closest to you. It took me thirty minutes from "hey mongo has some sort of geo support" to that (and I'm not a web dev and was using ATT 3G to read doc). PostGIS took me longer to figure out how to set a lat,long pair in the DB.

I'm not saying raw speed of development is the best measure of a database, but if your #1 priority is the ability to rapidly prototype, I'd imagine mongo is a good fit in your toolbelt.

I assure you that that anyone who has used any kind of SQL database can do the same stuff you did on Mongo in the same time or less. Development speed is much faster on the SQL database once you have some more data and you can start using joins and searches and all the other nice RDBMS features.

I've built a lot of stuff on RDBMSen, and often, those 'nice features' are actually what I call 'a giant pain in the ass.'

Sometimes, data doesn't fit a relational model well. In those cases, something like Mongo is a godsend. And yeah, you could de-normalize your data and get halfway to Mongo, but I'd rather use each tool for what it's good at.

"Sometimes, data doesn't fit a relational model well."

I keep hearing this but I've yet to see any good examples.

Here's what I posed last time someone asked me this, I got no answer: http://news.ycombinator.com/item?id=1637903

We have exactly the same kind of data relationships in our database. Sure it's complicated and in your example sure you'll end up with a bunch of tables if you normalize it all the way to 3NF. But there's a lot of GOOD STUFF you get when you do, for example if you decide to rename a FooType or a FooSize then you only have to update one record rather than searching every document in your document DB for instances of those names so you can rename them. Hell if you have many documents and 24/7 clients this may become IMPOSSIBLE to do while still guaranteeing consistency in your data.

Your example is not that unusual or even that complicated. What is about it that doesn't work on a RDBMS? You can't just say the solution sucks because it uses more tables that you feel it should.

It's good to know that I'm not totally spewing bullshit, and that's the way it should be done.

In this case, I would have less than 200 types, and probably under 1000 Foo records total. Updates wouldn't have been a problem. The pain was much bigger than the upside. Especially designing the forms that would end up creating those rows...

It's not that it doesn't work. It's that it's not a 'this always fits' solution.

This is what views are for. If it is easier to work with the data denormalized, create a view with a few joins. Some views can even have updates directly applied to them.

You're not exactly helping with the "Mongo is significantly less complicated to model my data with" argument. ;)

But still, good to know. I'm bad with views. :[

If the amount of data you're storing is so small you should definitely consider de-normalizing it until it's easy enough to work with. When you eventually scale up to millions of Foos you'll probably want to get it back to 3NF.

There is nothing wrong with denormalized data in your DB and denormalizing doesn't mean you'd have been better off with some random NoSQL solution. Especially considering that the entire rest of your DB is still very much relational data so what happens to all of that when you dump Postgre for Mongo?

It's not really random, though. I made a comment elsewhere in this thread, but Mongo is _almost_ a freaking Object database as far as Ruby is concerned. I could do it either way, but doing it with an RDBMs feels like BDSM compared to the loose and fast feel of developing with Mongo.

That said, I always try to use what's right. I don't care how easy it is to store credit card numbers is... I'll just use BrainTree's Vault product instead. ;)

this is what MongoDBs $rename operator is for...

$rename will not magically remove the expense of updating millions of rows in your data store (compared to updating a single row in a normalised DB)

Just like most things, it's not that simple. For example...

Cassandra is good for 'big data' if you're ok dealing with the repercussions of eventual consistency, and questionable performance characteristics. Not to mention the mediocre community support.

Redis is a fantastic choice, if you're ok with a limited data model and no diskstore option(coming soon though!)

Picking a datastore that fits your data model, access patterns, support needs, etc. can be a daunting task, and simplifying it to this degree just leaves too much out of the equation.

Reply on news.ycombinator.com