1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

Looking for experiences with MongoDB

Discussion in 'Databases' started by s.molinari, Jun 21, 2013.

  1. #1
    Hi,

    Is there any one out there who uses MongoDB? Can you share your likes, dislikes, it's strengths or weaknesses? I don't need long explanations, just some bullet points. I've already read a lot on the subject, I'd just like to get some first hand experiences. Thanks in advance to anyone who should answer.:)

    Scott
     
    s.molinari, Jun 21, 2013 IP
  2. khodem

    khodem Well-Known Member

    Messages:
    206
    Likes Received:
    8
    Best Answers:
    3
    Trophy Points:
    120
    #2
    Hi Scott.

    first of all MongoDB is one of the many NoSQL database which means there is no SQL query involved to talk to the database... for you to talk to the database you need to know JavaScript as this language is MongoDBs internal language to communicate with data... in general there is 4 types of NoSQL database:
    Key value, Document, column and graph and MongoDB comes under the Document category...

    - Faster when you have big database like bigger than 1TB
    - Concurrent connection when your site or your application have more connection like 1000+ user log in and use your application at one time
    - scale-ability
    - redundancy

    and the real power of MongoDB or any other NoSQL database comes in the picture when they are used with Hadoop...Hadoop is another buzz in the big data industry.. you can read my couple post in my blog in signature which showed even installation I know the English is a bit bad but you will get the idea lol.... i'm reviewing them all...
     
    khodem, Dec 15, 2013 IP
  3. s.molinari

    s.molinari Member

    Messages:
    82
    Likes Received:
    7
    Best Answers:
    0
    Trophy Points:
    45
    #3
    The only thing I disagree with is number 6. An advantage to a No-Sql database is not needing a separate language to address the data in the database. Developers can persist objects directly without having to rewrite them in queries. That is actually a huge advantage.:) It is also why things like ORMs were created.

    We are actually looking at MySql Cluster too and might even have it running in parallel with MongoDB for different database needs. This is one of our hardest decisions, because we know the database can cause the most costs and the most headaches, if we don't get it/ them right. We are actually planning to also use Elasticseach too.

    One of our biggest challenges is, we need a system which can change schema on the fly with no performance issues. An Sql system like MySql doesn't like additional fields being added or subtracted, as the table locks, when adding or subtracting the field to a table. If the table is big, this could cause issues with site performance.

    A No-Sql database would handle the new field more elegantly, with less to no performance issues, but we would be missing some of the things you've mentioned, which we will definitely need.

    There are ways to programmatically add the missing functionality you've listed, but then we'd be losing performance on the NoSql side and we'd also be wasting a lot of time to make things already created and running well in an Sql database.

    Decisions, decisions.:)

    I had found an image that sort of shows the differences and complexities between Mongo and MySql.

    [​IMG]

    Scott
     
    s.molinari, Dec 15, 2013 IP
    khodem likes this.
  4. khodem

    khodem Well-Known Member

    Messages:
    206
    Likes Received:
    8
    Best Answers:
    3
    Trophy Points:
    120
    #4
    Well I have not compared them with Relation databases...NoSQL is completely different database structure developed from ground up it's fact the both stored data but they all do it different ways and using different technology... there is pro and con in every technology but you fill the gap with third part softwares like in NoSQL you can over come those cons with Hadoop and MapReduce :)

    - why it's not Relation DB because the name itself says it NoSQL
    - about SQL language originally there is none supported but when you use it with Hadoop there is a lot of option like Hive, you can use hive and write normal queries like you do
    in mysql it support most function of ACID sql standard and it keeps improving Hive is one of many options
     
    khodem, Dec 15, 2013 IP
    s.molinari likes this.
  5. s.molinari

    s.molinari Member

    Messages:
    82
    Likes Received:
    7
    Best Answers:
    0
    Trophy Points:
    45
    #5
    Yeah, I'd say, there really is no comparison between No-Sql and Sql databases. Their purposes are aimed to solve different problems and thus why we are looking at a polyglot database system. Although, MySql Cluster is dipping a bit into No-Sql territory with its NoSql APIs. This, however, doesn't solve our open schema needs.

    Scott
     
    s.molinari, Dec 16, 2013 IP
  6. dansari

    dansari Well-Known Member

    Messages:
    50
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    108
    #6
    Some good answers here, but I'll throw something into the mix.

    I started developing a web app last year with Rails and MongoDB. It seemed really cool at first and performance was fine (note, not spectacular). But then when you start to build things that web apps require, such as requiring relationships between the global collections, I quickly realized that you run into something equivalent to the N+1 selects problem (i.e., one query to retrieve the appropriate collection, followed by one query for every item to fetch extra attributes that are present in another global collection). Googling around a lot, I also discovered that there was another developer that cited their reason for moving from MongoDB to a relational DB (it might have been MySQL, I forgot), and it was that the app was inherently relational. I would argue that most web apps are like this.

    Another thing is that there are certain limitations in the query syntax, so if you want to do things that are natural in a set-based language such as SQL, and retain the speed of server-side processing, you'll need to use server-side javascript. This slows things down somewhat (but performance might still be acceptable). I never got to load-testing the app, and since have migrated from that platform to ASP.NET MVC 4 + MS SQL Server 2012.

    Not everything fits into the document/subdocument (i.e., strictly hierarchical) paradigm, but for those domains where this is the pattern, MongoDB might be an appropriate technology.

    Hope this helps.
     
    dansari, Jan 1, 2014 IP
    khodem likes this.
  7. s.molinari

    s.molinari Member

    Messages:
    82
    Likes Received:
    7
    Best Answers:
    0
    Trophy Points:
    45
    #7
    Thanks for that dansari.

    I would have thought, if you keep the collections relatively small (in terms of schema), then Mongo's need to requiry to pull up related data would be about the same as having to join tables within an RDBM. There might be a bit more overhead in the network traffic, but negligible, or so I thought.

    Scott
     
    s.molinari, Jan 2, 2014 IP
  8. dansari

    dansari Well-Known Member

    Messages:
    50
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    108
    #8
    Sorry for the delayed response; I've been going crazy choosing a VPS host and playing around with Nginx.

    I agree, if you can keep the collections small, you can load them into memory and not have to join in the DB (it's what some people term as joining in the application). But that's only good for smaller lookup-type data.
     
    dansari, Jan 4, 2014 IP
  9. s.molinari

    s.molinari Member

    Messages:
    82
    Likes Received:
    7
    Best Answers:
    0
    Trophy Points:
    45
    #9
    Well, we are going to be trying to split data up into field types. i.e. numbers, small text, large text, dates, etc. This means, for the "data collections", we only need to index on 3 fields, as ID is a given. Altogether we'll have 6 collections holding the data for the field types and fields, another one for the field descriptions (meta data), one for the data object meta data. It will take 8 queries at most to pull the data together to build the complete data object. What ends up happening is we can have very, very flexible schema with the ability to have many, many fields and can change them at will. This is because a new field is added simply as new data to the field type collection. So, for instance, if the user adds a new "small text" field, the meta data is stored in the meta data collections (object and field) and the data is simply stored in the short text collection. That is our goal with our data object concept.:) Not sure it will work at all. But we are working on building now to test it, as we've also decided to give Mongo a try too. Theoetically, this concept could also work in an RDBMS too. That would mean a schema-less RDBMS, in sense.;)

    Scott
     
    s.molinari, Jan 4, 2014 IP