10 ms·

Viber Replaces MongoDB with Couchbase

65 points by naryad 13y ago

manishsharan 13y ago
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.
- 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.
  - 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.
vosper 13y ago
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.
- jchrisa 13y ago
  Here are a few Couchbase users (but there's a lot we can't tell you about.) http://www.couchbase.com/customers http://www.couchbase.com/customers
- rdtsc 13y ago
  Cloudant also has this mobile sync capability, they just released recently. They are also compatible with CouchDB (which Couchbase I think is not).
  - rch 13y ago
    +1 for Cloudant - there are some truly top-notch folks over there. Of course there are smart people at Couchbase too, I'd just suggest giving Cloudant some serious consideration.
- tony_landis 13y ago
  Couchbase is based on CouchDB, which I have used. I've commented on it here https://news.ycombinator.com/item?id=6690607 https://news.ycombinator.com/item?id=6690607
  - rubiquity 13y ago
    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. If you want the comparison of CouchDB vs Couchbase from Couchbase directly, you can read that here: http://www.couchbase.com/couchbase-vs-couchdb http://www.couchbase.com/couchbase-vs-couchdb In my opinion, the next closest NoSQL DB to CouchDB would be ElasticSearch.
ninv 13y ago
They picked the wrong product in first place. MongoDB and Couchbase are two different databases.
deleted 13y ago
[deleted]
rubiquity 13y ago
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.
- Djehngo 13y ago
  Whatsapp competitor, they seem to be doing quite well, although given how obnoxious their android app is I don't know how long that will last.
- cbaleanu 13y ago
  Viber allows you to make voice and video calls aswell. In my country, texting is not popular, voice calling is, so Viber is the must have app. As an added bonus, it works flawlessly from overseas as well, so you can call anyone else that's using Viber for free.
  - frik 13y ago
    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.
- skjhn 13y ago
  In what ways do you consider them to be different from the point of view of an architect (other than the different clustering implementations)? They're both document databases. They're both distributed. They're both supposed to scale.
jaihirsch 13y ago
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/01/06/mongodb-legacy-migration/ 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.
shittyanalogy 13y ago
In related news, Viber manages to bootstrap their startup all the way to billions of messages and talking minutes per month with MongoDB. Sounds like Mongo was a great choice and they're just growing up.

65 points by naryad 13y ago

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.

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.
- 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.

vosper 13y ago

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.

jchrisa 13y ago
Here are a few Couchbase users (but there's a lot we can't tell you about.) http://www.couchbase.com/customers http://www.couchbase.com/customers
rdtsc 13y ago
Cloudant also has this mobile sync capability, they just released recently. They are also compatible with CouchDB (which Couchbase I think is not).
- rch 13y ago
  +1 for Cloudant - there are some truly top-notch folks over there. Of course there are smart people at Couchbase too, I'd just suggest giving Cloudant some serious consideration.
tony_landis 13y ago
Couchbase is based on CouchDB, which I have used. I've commented on it here https://news.ycombinator.com/item?id=6690607 https://news.ycombinator.com/item?id=6690607
- rubiquity 13y ago
  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. If you want the comparison of CouchDB vs Couchbase from Couchbase directly, you can read that here: http://www.couchbase.com/couchbase-vs-couchdb http://www.couchbase.com/couchbase-vs-couchdb In my opinion, the next closest NoSQL DB to CouchDB would be ElasticSearch.

ninv 13y ago

They picked the wrong product in first place. MongoDB and Couchbase are two different databases.

deleted 13y ago

[deleted]

rubiquity 13y ago

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.

Djehngo 13y ago
Whatsapp competitor, they seem to be doing quite well, although given how obnoxious their android app is I don't know how long that will last.
cbaleanu 13y ago
Viber allows you to make voice and video calls aswell. In my country, texting is not popular, voice calling is, so Viber is the must have app. As an added bonus, it works flawlessly from overseas as well, so you can call anyone else that's using Viber for free.
- frik 13y ago
  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.
skjhn 13y ago
In what ways do you consider them to be different from the point of view of an architect (other than the different clustering implementations)? They're both document databases. They're both distributed. They're both supposed to scale.

jaihirsch 13y ago

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/01/06/mongodb-legacy-migration/ 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.

shittyanalogy 13y ago

In related news, Viber manages to bootstrap their startup all the way to billions of messages and talking minutes per month with MongoDB. Sounds like Mongo was a great choice and they're just growing up.