Viber Replaces MongoDB with Couchbase
couchbase.com
couchbase.com
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.
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.
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.
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.
Sounds like Mongo was a great choice and they're just growing up.
Know your problem domain, do your research, benchmark, test multiple solutions, and don’t be afraid to reengineer. That is how you scale.