Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

I have a Mongo task in front of me

  1. Feb 21, 2014 #1

    Borg

    User Avatar
    Gold Member

    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.
     
  2. jcsd
  3. Feb 21, 2014 #2

    SixNein

    User Avatar
    Gold Member

    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.
     
    Last edited: Feb 21, 2014
  4. Feb 21, 2014 #3

    Borg

    User Avatar
    Gold Member

    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...
     
  5. Feb 21, 2014 #4
    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.
     
  6. Feb 21, 2014 #5

    SixNein

    User Avatar
    Gold Member

    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.
     
    Last edited: Feb 21, 2014
  7. Feb 22, 2014 #6

    Borg

    User Avatar
    Gold Member

    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.
    ACID
    I'll have to look into how big of a requirement this might be for the project.
     
  8. Mar 5, 2014 #7

    harborsparrow

    User Avatar
    Gold Member

  9. Mar 6, 2014 #8

    Borg

    User Avatar
    Gold Member

    Not too late at all. Thanks!
     
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook




Similar Discussions: I have a Mongo task in front of me
Loading...