News for hackers. Stuff that matters.

A comment on Building a MongoDB Clone in Postgres. Parent comment

Re:Building a MongoDB Clone in Postgres by randomdata on Monday June 04, 2012 @02:21PM (#4065149)
Wouldn't that kind of defeat the purpose of using a document database in the first place? Being able to throw unstructured data into the system, and then being able to query on that data once the space is better understood is where the document databases really shine.

If you are able to start with rigid structure, you, in many cases, could have just used a relational database to begin with.

[ Parent | on HN ]
Re:Building a MongoDB Clone in Postgres by qeorge on Monday June 04, 2012 @10:07PM (#4066977)
In my (limited) experience with Mongo, its just not like that.

You can't just (quickly) query any key in the document - you have to define indexes anyway or you'll be doing the equivalent of a table scan or Map/Reduce.

Document databases shine when you're just not doing that kind of query anyway, and you've got a ton of data to store. If you need to do e.g., fulltext and/or geospatial search you should probably use a search server anyway (I like Sphinx), and then just lookup by PK in whatever datastore you're using.

Its been mentioned elsewhere on this thread, but I'm also quite fond of the old FriendFeed method: serialize your arbitrary data into a (MySQL) BLOB, and then run a background process to build "indexes" (really tables) when you find out you need them.

Its ridiculously simple to start doing that, and there's no new tech to learn.

[ Parent | on HN ]
Re:Building a MongoDB Clone in Postgres by rhizome on Monday June 04, 2012 @03:05PM (#4065346)
Wouldn't that kind of defeat the purpose of using a document database in the first place?

Yes. Use the right tool for the job.

[ Parent | on HN ]
Re:Building a MongoDB Clone in Postgres by mgkimsal on Monday June 04, 2012 @10:01PM (#4066955)
Defining 'right', and being able to predict 'right' for future iterations/versions of an app's life is where that mantra seems to fall down.

I'm not a huge nosql fan right now, given that I sometimes need document-style schemaless data storage, but I always (eventually) need adhoc reporting and relational querying capabilities on projects. With that (fore)knowledge, I may as well always choose a relational db.

[ Parent | on HN ]