My eyes hurt from reading so much PRese. Look, every organization from from Solution A to Solution B in due course-- and that is a PR Story. But for it to be useful programmers, there has to be some amount of quantitative data to support the decision ;a video embed doesn't count. Surely Couchbase folks can do better than this to catch our attention.
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.
> 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.
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).
> 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.
"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.
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.
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.
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.
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:
Also, MongoDB (the company) dogfoods MongoDB (the product) to run their online monitoring/backup service, MMS (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:
Is anyone else using Couchbase? I'm evaluating it for a project with a mobile component and Couchbase Mobile with its automatic syncing seems like a great solution. Would love to hear peoples thoughts.
Despite sharing a common name, Couchbase and CouchDB have very little in common. It was a bad move by the original developers of CouchDB that left the project to give Couchbase the name Couchbase.
Couchbase was designed for write-heavy applications and built with clustering in mind from day one. CouchDB was designed for read-heavy applications where versioning and replication are important. Cloudant, by way of their BigCouch product, has done a lot of great work on clustering for CouchDB and all that work is slowly making its way into CouchDB core.
I don't entirely know what Viber does, but given how very different MongoDB and Couchbase are, I think they made a terrible choice of using MongoDB in the first place. You can't fault MongoDB for that. Viber announcing this change is more of an admission that their architects/engineers made a bad choice than it is a slight against MongoDB.
Also, I don't like MongoDB very much and almost always find another more suitable database (both SQL and NoSQL) for the projects that I have worked on.
Do you mind to disclose your country or continent where Viber (or video chat) is popular.
I can only speak of myself, in central Europe Skype (voice, video) and WhatsApp (group chat) are popular. Facebook is increasingly used by elder population and shunt by younger generations.
As I avoid WhatsApps (it sucks IMHO ..no Web and Tablet support, shady company), I would welcome any competitor.
Couchbase and MongoDB are both excellent databases and have their place. I work with a MongoDB implementation that has over 12.75 billion records, adds over a billion records per year, and runs in a high availability, high read environment.
http://jaihirsch.github.io/straw-in-a-haystack//mongodb/2014...
Know your problem domain, do your research, benchmark, test multiple solutions, and don’t be afraid to reengineer. That is how you scale.
27 comments
[ 2.9 ms ] story [ 67.1 ms ] threadCompanies 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.
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.
Once you grow past it you know where the problems in your data are and can optimize accordingly.
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).
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.
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.
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.
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.
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/
Also, MongoDB (the company) dogfoods MongoDB (the product) to run their online monitoring/backup service, MMS (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
and the answers they give are pretty detailed.
Of course there are smart people at Couchbase too, I'd just suggest giving Cloudant some serious consideration.
Couchbase was designed for write-heavy applications and built with clustering in mind from day one. CouchDB was designed for read-heavy applications where versioning and replication are important. Cloudant, by way of their BigCouch product, has done a lot of great work on clustering for CouchDB and all that work is slowly making its way into CouchDB core.
If you want the comparison of CouchDB vs Couchbase from Couchbase directly, you can read that here: http://www.couchbase.com/couchbase-vs-couchdb
In my opinion, the next closest NoSQL DB to CouchDB would be ElasticSearch.
Also, I don't like MongoDB very much and almost always find another more suitable database (both SQL and NoSQL) for the projects that I have worked on.
As an added bonus, it works flawlessly from overseas as well, so you can call anyone else that's using Viber for free.
I can only speak of myself, in central Europe Skype (voice, video) and WhatsApp (group chat) are popular. Facebook is increasingly used by elder population and shunt by younger generations.
As I avoid WhatsApps (it sucks IMHO ..no Web and Tablet support, shady company), I would welcome any competitor.
They're both document databases. They're both distributed. They're both supposed to scale.
Know your problem domain, do your research, benchmark, test multiple solutions, and don’t be afraid to reengineer. That is how you scale.
Sounds like Mongo was a great choice and they're just growing up.