I have a Mongo task in front of me

[Borg]

My latest project at work involves working with Mongo DB. It is unlike any database that I have ever dealt with in the past. I am just starting to teach myself how it works and I'm wondering if anyone has any insight, hints, gotchas, or other information that might help me better understand Mongo.

 

[SixNein]

My latest project at work involves working with Mongo DB. It is unlike any database that I have ever dealt with in the past. I am just starting to teach myself how it works and I'm wondering if anyone has any insight, hints, gotchas, or other information that might help me better understand Mongo.

Bet someone is about to do some business intelligence work. And if I'm right, congrats on becoming BI curious =P

And yes its quit a bit different from relational. Basically, the thing to keep in mind is the needs of analytics influences the way things are done in mongo. In other words, how to deal with lots of data.

 

[Borg]

Bet someone is about to do some business intelligence work. And if I'm right, congrats on becoming BI curious =P

And yes its quit a bit different from relational. Basically, the thing to keep in mind is the needs of analytics influences the way things are done in mongo. In other words, how to deal with lots of data.

I wouldn't say that I'm business intelligence curious - just want to do the task that I've been assigned to the best of my ability. I'm not sure what to think of the statement "needs of analytics influences the way things are done in mongo". We're still flushing out the use cases but from what I've seen in meetings, it's going to be complex as hell. The user wants it all from predefined through fine grained settings to letting the users query like they did via relational databases.

The best pointer that I've gotten so far is that Mongo collections are like tables and Mongo documents are like records in the tables. That's my starting point. I need to figure out what I can do in Mongo like I did in a relational DB (and how to do it), what I can't do in Mongo, and what I need to completely change my thinking on. I will be lost for a while...

 

[voko]

It is interesting how "database" has become practically synonymous with "relational database". I think the trend started in mid-eighties. Initially it was all good, but eventually things got ugly, to the point that "peer pressure" pretty much became mandating that all data must be persisted in a relational database, period. I like seeing that trend reversed.

 

[SixNein]

I wouldn't say that I'm business intelligence curious - just want to do the task that I've been assigned to the best of my ability. I'm not sure what to think of the statement "needs of analytics influences the way things are done in mongo". We're still flushing out the use cases but from what I've seen in meetings, it's going to be complex as hell. The user wants it all from predefined through fine grained settings to letting the users query like they did via relational databases.

The best pointer that I've gotten so far is that Mongo collections are like tables and Mongo documents are like records in the tables. That's my starting point. I need to figure out what I can do in Mongo like I did in a relational DB (and how to do it), what I can't do in Mongo, and what I need to completely change my thinking on. I will be lost for a while...

To put the above in a different way, it's a database designed for clusters. Outside of replication, relational databases are really geared for vertical approaches. So a join on a relational database is straight forward, but on a cluster it's not straight forward at all. The data needed for the join may be spread out over other servers.

So acid is simply not there outside of documents. Think denormalized data.

 

[Borg]

To put the above in a different way, it's a database designed for clusters. Outside of replication, relational databases are really geared for vertical approaches. So a join on a relational database is straight forward, but on a cluster it's not straight forward at all. The data needed for the join may be spread out over other servers.

So acid is simply not there outside of documents. Think denormalized data.

Thanks. I need to keep in mind that the data will likely be clustered. I guess that I'll have to handle all data relationships programmatically. I've had several projects where we've had to perform programmatic pseudo-joins on two different relational databases so I think I can handle that.

So acid is simply not there outside of documents. Think denormalized data.

ACID

(Atomicity, Consistency, Isolation, Durability) is a set of properties that guarantee that database transactions are processed reliably.

I'll have to look into how big of a requirement this might be for the project.

 

[harborsparrow]

It's probably too late to be of help to you but...

http://en.citizendium.org/wiki/Nosql might be of help, as well as other articles about the topic "NoSQL"

 

[Borg]

It's probably too late to be of help to you but...

http://en.citizendium.org/wiki/Nosql might be of help, as well as other articles about the topic "NoSQL"

Not too late at all. Thanks!