Live data from Hacker News

Migrating from MongoDB to Cassandra

fullcontact.com

61–65 of 65 posts

Re: Migrating from MongoDB to Cassandra

#61
post #46

"To buy us time, we ‘sharded’ our MongoDB cluster. At the application layer. We had two MongoDB clusters of hi1.4xlarges, sent all new writes to the new cluster, and read from both..." I'm curious about this. Why were you doing the sharding manually in your application layer? Picking a MongoDB shard key - something like the id of the user record - would produce some fairly consistent write-load distribution across cl…

As explained, it was a stop-gap solution for data storage only, we did not have a problem with write load on SSDs.

We were at the point that MongoDB sharding was just as difficult to deploy as moving to Cassandra, which better fit our goals of availability. MongoDB sharding isn't instant by any means for existing clusters.

Re: Migrating from MongoDB to Cassandra

#62
post #10

Viber, one of the largest over the top messaging apps, recently shared their conversion from Mongo to Couchbase. They ended up requiring less than half of the original servers, and better performance. If you want to see a video of their engineer telling the story, it's available here: http://www.couchbase.com/presentations/couchbase-tlv-2014-co...

Like always: "Use the right tool for the job". I did not think that this was MongoDB(10gen)s fault, they (viber) choose the wrong database type for their needs.

That's really easy to say, so it's important to show your specific reasoning.

Re: Migrating from MongoDB to Cassandra

#63

This article caught my interest as I've been reading into Cassandra. But some previous research had me thinking that Cassandra works best with under a TB/node. Is SQL still better when you have really large nodes (16-32TB) and only really want to scale out for more storage? I'm currently humming along happily with Postgres, but some of the distributed features, and availability of Cassandra look really nice.

We run at about 1TB a node and it works well (high write load things like metrics and telemetry data). But we also use SQL server where appropriate (i.e. transactional account stuff).

I am a fan of using the right tool for the right job providing you have the team to support it.

Re: Migrating from MongoDB to Cassandra

#64

Earlier quoted context omitted.

From TFA: We were a young startup and made a few crucial mistakes. MongoDB was not a mistake. It let us iterate rapidly and scaled reasonably well. A good solution for X scale might not be so good for 10X scale. But by the same token, a 10X scale solution for a 1X scale problem isn't a good idea either.

This is what I haven't understood about criticism of MongoDB. Don't some people have projects that dont need to scale to an incredible degree?

Then why not use a relational database in order to save time?

Re: Migrating from MongoDB to Cassandra

#65
post #57

Yet another shining example of throwing money and time away to work within AWS constraints when bare metal and openstack (1) would have solved it cheaper (2) and arguably faster. 1 (if you insist on cloud provisioning instances, even though it makes little sense if the resources are as strictly dedicated as they are in this case) 2 (VASTLY, over time -- these guys are pissing money away at AWS and I hope their invest…

AWS in general is a waste of time and money for most standard web hosting requirements I think
Post reply on HN