4 ms·

The video does provide some quantitative data and the slides underneath do as well. I'd prefer a proper article, but it's not that bad. Companies seem to be ju

by RyanZAG 13y ago

The video does provide some quantitative data and the slides underneath do as well. I'd prefer a proper article, but it's not that bad. Companies seem to be jumping off mongodb left and right, with the only ones sticking to it being small ones with lower replication requirements - the kind of situation that pgsql etc deals with far better. Mongodb seems to be the worst of both worlds - a lack of scalability and a lack of per-node rich joins and similar.

bsg75 13y ago
> The video does provide some quantitative data and the slides underneath do as well. Two of the worst places to put data. Edit: Data that describes the problem and solution should be part of a narrative, not a slide presentation. Video is a trend of laziness when the author does not take the time to produce actual documentation.
raverbashing 13y ago
MongoDB solves the problem of developer time being expensive. It's simple to use and understands JSON data. Once you grow past it you know where the problems in your data are and can optimize accordingly.
- tracker1 13y ago
  I have to completely agree... MongoDB does do okay in terms of small-mid scale needs, and is dead-simple to work with. It's a very natural fit with node.js, and does "good enough" for most. I do think that over the next 2-3 years as PostgreSQL adapts and expands the V8 extensions (and JSON data type) that it will probably take over MongoDB, and that we may well see a "mongo" adapter for a postgresql based backend. The place where I have MongoDB in the wild, it's a great/natural fit for what it's being used for... searching (including geolocation) on about 30k active records for a vehicle classifieds site. It should work on up to 10x the current load on the single server instance it's on, and can be re-deployed to a larger cloud/vm instance. The SQL db is the source of record, and data is replicated to the mongo instance. ElasticSearch was also considered, but didn't work as well when development was done (over a year and a half ago).
- collyw 13y ago
  > MongoDB solves the problem of developer time being expensive. I don't know about this argument. I am involved with a project to build a rare diseases database, and it might get moderately big (maybe ~1Tb). Somewhere on a related project a MySQL server crashed, so the guys building this new system have jumped right on the NoSQL bandwagon (despite the fact we clearly have relational data). 6 months ago, it was all Mongo DB. Last week it was Tokyo Cabinet. I am currently benchmarking Postgres (they seem not to have done that). I think I could achieve similar functionality in two weeks what these guys have taken 6 months to do using all the NoSQL solutions they have had tried (and needed to learn). When you have mature frameworks like Rails or Django that take a lot of the grunt work out of traditional RDMBS systems, I don't think it really is correct to say that Mongo DB saves developer time. In Certain areas, yes, but think there is a bigger picture to take into account.
  - raverbashing 13y ago
    "When you have mature frameworks like Rails or Django that take a lot of the grunt work out of traditional RDMBS systems, I don't think it really is correct to say that Mongo DB saves developer time." Depends. Sometimes Django ORM is great. Sometimes, it is awful (yes, sometimes the models have crazy links between them, this is the most frequent cause of problems) Sure, if your data is relational, go for a RDBMS. But sometimes it isn't. And yes, if they're taking 6 months to do something in MongoDB there's something wrong with what/how they're trying to do it.
    - collyw 13y ago
      They are choosing NoSQL hype for relational data. That's what they are doing wrong.
      - raverbashing 13y ago
        You can have relations in MongoDB of course, however they are not as in an Relational DB. The problem is that they get the "MongoDB == no relations" literally and are trying to put a round peg in a square hole. I personally find it hilarious when someone is hitting their head in the desk with the "no relations" thing, as if it's a huge sin to have a id (or other information) of an item in another table.
victorhooi 13y ago
I think this FUD gets repeated a lot - however, is there any evidence that Mongodb "doesnt' scale"? I don't think MongoDB (or anything) is a magic bullet, - however, like any technology, it optimises for certain technical trade-offs. There is no free lunch. If you're a real engineer, you should do your background reading before using any product (MongoDB, Couchbase, Postgres etc.) There are a lot of very large MongoDB installations (e.g. Stripe, FourSquare, eBay etc.) - and I'm sure a lot of large Couchbase installations). Probably larger than most people here would ever deal with. Hence, I suspect an inability to get either to scale to your dataset if probably more an issue with how you're using it, or a failure to READ THE FINE MANUAL. Remember that hoax article from a few years ago, "Don't use MonogDB" - one of the claims was, we were at capacity, and we had issues adding in sharding. Gee, your system is at max capacity, and you wonder why you can't tack on sharding and re-balance your shards. I know it probably sucks to hear, but don't you think you should have monitored your systems, to know before they were full? It's like say, running ZFS on a Raspberry Pi and complaining, gee, why the performance suck? ZFS SUCKS!!! If you're read the docs, you'd know that ZFS needs RAM for the ARC cache. Oh, and running on that little RAM, you expose yourself to FS corruption issues. ZFS is a great filesystem, if used correctly. Use the right tool for the right job, and read the docs.
- eksith 13y ago
  I'm curious whether anyone has done any recent, and hopefully unbiased and comprehensive, Mongo comparisons with other DBMS with a large dataset. It's been a while since I've seen any new information.
  - victorhooi 13y ago
    Performance (for any system) is really going to be dependent on your particular hardware, your database schema, and the sorts of queries you'll likely be running. Somebody else's benchmarks numbers may not mean very much for your own real-world use case. So in short - you should be running your own tests/benchmarks. Nonetheless, ServerDensity has some of their numbers here: https://blog.serverdensity.com/mongodb-benchmarks/ https://blog.serverdensity.com/mongodb-benchmarks/ Also, MongoDB (the company) dogfoods MongoDB (the product) to run their online monitoring/backup service, MMS (http://mms.mongodb.com/ http://mms.mongodb.com/). The scale on that thing (in terms of writes/updates) is huge. There are also several other well-known very-large installations of MongoDB: * Trello * FourSquare * Craigslist * Server Density * Trello * Bit.ly * Chartbeat Most of these DB products are reasonably mature (for a given value of mature) by now - so any of them could probably scale to your workload. So you also need to look at other features as well - developer ease-of-use, ecosystem/tooling, support etc. Put it this way - needing to scale is usually a good problem you want to be having =) - and as the above shows, MongoDB is more than capable of doing it. If you have specific questions - the MongoDB Google Group is a fantastically friendly place to ask: https://groups.google.com/forum/#!forum/mongodb-user https://groups.google.com/forum/#!forum/mongodb-user and the answers they give are pretty detailed.

by RyanZAG 13y ago

bsg75 13y ago

> The video does provide some quantitative data and the slides underneath do as well. Two of the worst places to put data. Edit: Data that describes the problem and solution should be part of a narrative, not a slide presentation. Video is a trend of laziness when the author does not take the time to produce actual documentation.

raverbashing 13y ago

MongoDB solves the problem of developer time being expensive. It's simple to use and understands JSON data. Once you grow past it you know where the problems in your data are and can optimize accordingly.

tracker1 13y ago
I have to completely agree... MongoDB does do okay in terms of small-mid scale needs, and is dead-simple to work with. It's a very natural fit with node.js, and does "good enough" for most. I do think that over the next 2-3 years as PostgreSQL adapts and expands the V8 extensions (and JSON data type) that it will probably take over MongoDB, and that we may well see a "mongo" adapter for a postgresql based backend. The place where I have MongoDB in the wild, it's a great/natural fit for what it's being used for... searching (including geolocation) on about 30k active records for a vehicle classifieds site. It should work on up to 10x the current load on the single server instance it's on, and can be re-deployed to a larger cloud/vm instance. The SQL db is the source of record, and data is replicated to the mongo instance. ElasticSearch was also considered, but didn't work as well when development was done (over a year and a half ago).
collyw 13y ago
> MongoDB solves the problem of developer time being expensive. I don't know about this argument. I am involved with a project to build a rare diseases database, and it might get moderately big (maybe ~1Tb). Somewhere on a related project a MySQL server crashed, so the guys building this new system have jumped right on the NoSQL bandwagon (despite the fact we clearly have relational data). 6 months ago, it was all Mongo DB. Last week it was Tokyo Cabinet. I am currently benchmarking Postgres (they seem not to have done that). I think I could achieve similar functionality in two weeks what these guys have taken 6 months to do using all the NoSQL solutions they have had tried (and needed to learn). When you have mature frameworks like Rails or Django that take a lot of the grunt work out of traditional RDMBS systems, I don't think it really is correct to say that Mongo DB saves developer time. In Certain areas, yes, but think there is a bigger picture to take into account.
- raverbashing 13y ago
  "When you have mature frameworks like Rails or Django that take a lot of the grunt work out of traditional RDMBS systems, I don't think it really is correct to say that Mongo DB saves developer time." Depends. Sometimes Django ORM is great. Sometimes, it is awful (yes, sometimes the models have crazy links between them, this is the most frequent cause of problems) Sure, if your data is relational, go for a RDBMS. But sometimes it isn't. And yes, if they're taking 6 months to do something in MongoDB there's something wrong with what/how they're trying to do it.
  - collyw 13y ago
    They are choosing NoSQL hype for relational data. That's what they are doing wrong.
    - raverbashing 13y ago
      You can have relations in MongoDB of course, however they are not as in an Relational DB. The problem is that they get the "MongoDB == no relations" literally and are trying to put a round peg in a square hole. I personally find it hilarious when someone is hitting their head in the desk with the "no relations" thing, as if it's a huge sin to have a id (or other information) of an item in another table.

victorhooi 13y ago

I think this FUD gets repeated a lot - however, is there any evidence that Mongodb "doesnt' scale"? I don't think MongoDB (or anything) is a magic bullet, - however, like any technology, it optimises for certain technical trade-offs. There is no free lunch. If you're a real engineer, you should do your background reading before using any product (MongoDB, Couchbase, Postgres etc.) There are a lot of very large MongoDB installations (e.g. Stripe, FourSquare, eBay etc.) - and I'm sure a lot of large Couchbase installations). Probably larger than most people here would ever deal with. Hence, I suspect an inability to get either to scale to your dataset if probably more an issue with how you're using it, or a failure to READ THE FINE MANUAL. Remember that hoax article from a few years ago, "Don't use MonogDB" - one of the claims was, we were at capacity, and we had issues adding in sharding. Gee, your system is at max capacity, and you wonder why you can't tack on sharding and re-balance your shards. I know it probably sucks to hear, but don't you think you should have monitored your systems, to know before they were full? It's like say, running ZFS on a Raspberry Pi and complaining, gee, why the performance suck? ZFS SUCKS!!! If you're read the docs, you'd know that ZFS needs RAM for the ARC cache. Oh, and running on that little RAM, you expose yourself to FS corruption issues. ZFS is a great filesystem, if used correctly. Use the right tool for the right job, and read the docs.

eksith 13y ago
I'm curious whether anyone has done any recent, and hopefully unbiased and comprehensive, Mongo comparisons with other DBMS with a large dataset. It's been a while since I've seen any new information.
- victorhooi 13y ago
  Performance (for any system) is really going to be dependent on your particular hardware, your database schema, and the sorts of queries you'll likely be running. Somebody else's benchmarks numbers may not mean very much for your own real-world use case. So in short - you should be running your own tests/benchmarks. Nonetheless, ServerDensity has some of their numbers here: https://blog.serverdensity.com/mongodb-benchmarks/ https://blog.serverdensity.com/mongodb-benchmarks/ Also, MongoDB (the company) dogfoods MongoDB (the product) to run their online monitoring/backup service, MMS (http://mms.mongodb.com/ http://mms.mongodb.com/). The scale on that thing (in terms of writes/updates) is huge. There are also several other well-known very-large installations of MongoDB: * Trello * FourSquare * Craigslist * Server Density * Trello * Bit.ly * Chartbeat Most of these DB products are reasonably mature (for a given value of mature) by now - so any of them could probably scale to your workload. So you also need to look at other features as well - developer ease-of-use, ecosystem/tooling, support etc. Put it this way - needing to scale is usually a good problem you want to be having =) - and as the above shows, MongoDB is more than capable of doing it. If you have specific questions - the MongoDB Google Group is a fantastically friendly place to ask: https://groups.google.com/forum/#!forum/mongodb-user https://groups.google.com/forum/#!forum/mongodb-user and the answers they give are pretty detailed.