4 ms·

Having done a large personalization project (25 million+ users) with Mongo as a proof of concept I tend to agree. It's great for small POC, but it still has pro

Having done a large personalization project (25 million+ users) with Mongo as a proof of concept I tend to agree. It's great for small POC, but it still has problems under large applications. We took tailored our data collections to take advantage of memory locality, but for that project it wasn't a good fit. I'm more interested in Hyperdex at this point. Mongo is great for getting something up and running quickly.

corresation 13y ago
MongoDB is very suitable for some tasks (though it has the inevitable young product edge issues that early adopters get to enjoy), but my core issue with the lead-in is that the author sounds like the problem with NoSQL, which is the "everything is a nail, here is my hammer" mentality, assuming that products like MongoDB are the successors of RDBMS', when that is absolutely not true. They are different tools for different purposes.
- tomsthumb 13y ago
  What are the different purposes, and how do I know that have have one versus the other, versus another, etc?
  - niggler 13y ago
    Ultimately most of the technical differences boil down to a single tradeoff between performance and reliability. In some use cases, you have many transactions against a data store that won't be modified once it is set. In a case like that, mongodb is acceptable. In other use cases, you have more complicated transactions involving lots of separate logical units. For example, lets say you are building an inventory and order management system. Someone wants to buy a widget. You need to reduce the widget inventory and push it into a customer's order, essentially an "Atomic" operation. AFAICT there's no "simple" data model under which MongoDB can give you atomicity. In order to make a decision, the best bet is to figure out those requirements and just try one that fits the bill.
  - vec 13y ago
    SQL databases are strongly typed and extremely good at enforcing consistency, whether you want them to or not. They are quite good at preventing many classes of bad data from being recorded in the first place, and allow you to do some types of low level data manipulation (joining datasets, eliminating duplicates, finding mins and maxes, etc) extremely efficiently. NoSQL, on the other hand, is weakly typed and makes few if any attempts to validate your data, pushing that responsibility back onto you. They are very well suited to storing inherently inconsistent data (which, as a corollary, makes them very good for prototyping, when your data model is rapidly changing and growing). They also allow you to link much larger datasets into a 'document' which is retrieved as a unit with no extra computation. So it mostly boils down to what kind of data you want to store. If you find yourself almost exclusively saying things like "All users have a username that is a string" or "I want to be able to find all products that cost less than $20" then you're probably looking for a traditional SQL database. If, on the other hand, you find yourself saying "some products have a width and height, but some just have a height, and a few have a volume instead" or "I want to be able to add custom fields to products on the fly" or "I never want to see purchases on their own, I always want to see them joined to the user that bought them" then you should probably consider a NoSQL solution.
    - tomsthumb 13y ago
      > SQL databases are strongly typed and extremely good at enforcing consistency, whether you want them to or not. They are quite good at preventing many classes of bad data from being recorded in the first place >NoSQL, on the other hand, is weakly typed and makes few if any attempts to validate your data, pushing that responsibility back onto you. They are very well suited to storing inherently inconsistent data Actually, I've had to deal with that first hand. It gets particularly nasty when multiple languages with varying type-tightness interact with the same data. It's nice to hear someone else put this into words.

corresation 13y ago

MongoDB is very suitable for some tasks (though it has the inevitable young product edge issues that early adopters get to enjoy), but my core issue with the lead-in is that the author sounds like the problem with NoSQL, which is the "everything is a nail, here is my hammer" mentality, assuming that products like MongoDB are the successors of RDBMS', when that is absolutely not true. They are different tools for different purposes.

tomsthumb 13y ago
What are the different purposes, and how do I know that have have one versus the other, versus another, etc?
- niggler 13y ago
  Ultimately most of the technical differences boil down to a single tradeoff between performance and reliability. In some use cases, you have many transactions against a data store that won't be modified once it is set. In a case like that, mongodb is acceptable. In other use cases, you have more complicated transactions involving lots of separate logical units. For example, lets say you are building an inventory and order management system. Someone wants to buy a widget. You need to reduce the widget inventory and push it into a customer's order, essentially an "Atomic" operation. AFAICT there's no "simple" data model under which MongoDB can give you atomicity. In order to make a decision, the best bet is to figure out those requirements and just try one that fits the bill.
- vec 13y ago
  SQL databases are strongly typed and extremely good at enforcing consistency, whether you want them to or not. They are quite good at preventing many classes of bad data from being recorded in the first place, and allow you to do some types of low level data manipulation (joining datasets, eliminating duplicates, finding mins and maxes, etc) extremely efficiently. NoSQL, on the other hand, is weakly typed and makes few if any attempts to validate your data, pushing that responsibility back onto you. They are very well suited to storing inherently inconsistent data (which, as a corollary, makes them very good for prototyping, when your data model is rapidly changing and growing). They also allow you to link much larger datasets into a 'document' which is retrieved as a unit with no extra computation. So it mostly boils down to what kind of data you want to store. If you find yourself almost exclusively saying things like "All users have a username that is a string" or "I want to be able to find all products that cost less than $20" then you're probably looking for a traditional SQL database. If, on the other hand, you find yourself saying "some products have a width and height, but some just have a height, and a few have a volume instead" or "I want to be able to add custom fields to products on the fly" or "I never want to see purchases on their own, I always want to see them joined to the user that bought them" then you should probably consider a NoSQL solution.
  - tomsthumb 13y ago
    > SQL databases are strongly typed and extremely good at enforcing consistency, whether you want them to or not. They are quite good at preventing many classes of bad data from being recorded in the first place >NoSQL, on the other hand, is weakly typed and makes few if any attempts to validate your data, pushing that responsibility back onto you. They are very well suited to storing inherently inconsistent data Actually, I've had to deal with that first hand. It gets particularly nasty when multiple languages with varying type-tightness interact with the same data. It's nice to hear someone else put this into words.