Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from MongoDB to Cassandra

fullcontact.com

Post reply on HN
Print view View original

21–30 of 65 posts

Re: Migrating from MongoDB to Cassandra

#21

Post by chaostheory »

threeseed wrote: post #18
chaostheory wrote: post #4

Earlier quoted context omitted.

Like any other NoSQL datastore, things like MongoDB aren't as general purpose as a RDBMS no matter how the marketing and sales teams make them out to be. Cassandra is no different. People need to read the documentation (say what you will about mongo but 10Gen docs are pretty damn good) more thoroughly before blindly implementing stuff on NoSQL and complaining. (I've been guilty of this in the past.)

For me anyone that uses the term "NoSQL" to group completely different databases simply doesn't understand what they are talking about. Cassandra and MongoDB are completely fine as general purpose databases. With CQL3 Cassandra is just as easy to use as any RDBMS with the advantage of being infinitely more scalable and easier to manage.

> Cassandra and MongoDB are completely fine as general purpose databases.

Whenever I hear this, I feel that the person saying it either doesn't have enough experience or that every problem to them looks like a nail for their particular flavor of NoSQL. That's like saying a street bike is a general purpose bicycle. I'm sure someone out there can make it work on an outdoor offroad trail, but is it ideal?

Cassandra is really awesome at writes but reads are really expensive. Atomicity at the row level only (unless you want that 30% performance hit) and eventually consistency make this not great at real time. CQL3 is an improvement but it's still not as good as ANSI SQL. I still have to do a lot of extra work.

With Mongodb it does really well with tree based data. The second you try to do join queries outside of that doc tree... major performance hit. (Maybe this has changed knowing the speed mongo evolves.) When data is larger than RAM... major performance hit... not so great for something like logging.

Using an RDBMS for everything isn't great, but the pain you suffer is a lot less especially since these days more and more them have some sort of federation or cluster solution. That said, some NoSQL datastores are better for certain applications than an RDBMS, just not for all of them.

Re: Migrating from MongoDB to Cassandra

#22

Post by monkey26 »

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.

Re: Migrating from MongoDB to Cassandra

#23

Post by jdrobins2000 »

threeseed wrote: post #18
chaostheory wrote: post #4

Earlier quoted context omitted.

Like any other NoSQL datastore, things like MongoDB aren't as general purpose as a RDBMS no matter how the marketing and sales teams make them out to be. Cassandra is no different. People need to read the documentation (say what you will about mongo but 10Gen docs are pretty damn good) more thoroughly before blindly implementing stuff on NoSQL and complaining. (I've been guilty of this in the past.)

For me anyone that uses the term "NoSQL" to group completely different databases simply doesn't understand what they are talking about. Cassandra and MongoDB are completely fine as general purpose databases. With CQL3 Cassandra is just as easy to use as any RDBMS with the advantage of being infinitely more scalable and easier to manage.

I agree that Cassandra CAN be used for basically everything a RDBMS can, but to claim it can be used just as easily is a stretch (based on my experience migrating from PostgreSQL to Cassandra). It lacks many administration tools, and for data with complex, non-hierarchical relationships, data modeling is more complicated and you must do any joins yourself. Sure you can get major performance and scalability gains if you use it correctly, but you also give up being fully ACID.

As a developer, using C for all data in any complex application is going to be harder up front than using a RDBMS. From what I have heard and learned about C, though, it is less painful to use C for a highly performant/scalable database than trying to scale most or all RDBMSs. From what I have read, Mongo is also hard to scale.

Re: Migrating from MongoDB to Cassandra

#24

Post by Xorlev »

chaostheory wrote: post #21
threeseed wrote: post #18

Earlier quoted context omitted.

For me anyone that uses the term "NoSQL" to group completely different databases simply doesn't understand what they are talking about. Cassandra and MongoDB are completely fine as general purpose databases. With CQL3 Cassandra is just as easy to use as any RDBMS with the advantage of being infinitely more scalable and easier to manage.

> Cassandra and MongoDB are completely fine as general purpose databases. Whenever I hear this, I feel that the person saying it either doesn't have enough experience or that every problem to them looks like a nail for their particular flavor of NoSQL. That's like saying a street bike is a general purpose bicycle. I'm sure someone out there can make it work on an outdoor offroad trail, but is it ideal? Cassandra is r…

Reads definitely aren't cheap, not compared to the hyper-optimized write path. Cassandra reads can however be exploited to make a lot of common time-series reads extremely cheap by amortizing the cost of the read over a lot of returned data (think a clustered row with lots of byte-sorted columns). Not that RDBMSes can't do the same thing, but it's a complex challenge to linearly scale and maintain availability.

Cassandra also exploits SSDs quite well by avoiding write-amplification problems, given that all write IO is sequential only.

I'm a huge fan of both traditional RDBMSes and alternative data stores. The most important rule for touring data stores is to be sure not to bring it into work when it's not appropriate and to evaluate the hell out of any solution before you write a single line of code.

Most of the time, PostgreSQL will do 99.9% of what you need and then some.

Re: Migrating from MongoDB to Cassandra

#26

Post by brown9-2 »

DigitalSea wrote: post #3

When I read posts like this all but confirming MongoDB isn't the great product 10Gen make it out to be, I wonder how the heck MongoDB are still even relevant and then I remind myself of the fact that 10Gen have one of the best marketing and sales teams in the game at the moment. While MongoDB has improved greatly over previous versions, I can't help but feel if 10Gen put as much effort into improving their product as…

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.

Re: Migrating from MongoDB to Cassandra

#27

Post by roycehaynes »

DigitalSea wrote: post #3

When I read posts like this all but confirming MongoDB isn't the great product 10Gen make it out to be, I wonder how the heck MongoDB are still even relevant and then I remind myself of the fact that 10Gen have one of the best marketing and sales teams in the game at the moment. While MongoDB has improved greatly over previous versions, I can't help but feel if 10Gen put as much effort into improving their product as…

I think part of the lesson learned from reading the post is MongoDB is best when you start sharding from the git-go, especially if you know you're going to have pounds of data.

Re: Migrating from MongoDB to Cassandra

#28

Post by Xorlev »

brown9-2 wrote: post #25

Is DynamoDB never a serious option for people in situations like this and already heavily on AWS?

One of the key detractors for us was the 64KB limit.

"The total size of an item, including attribute names and attribute values, cannot exceed 64KB."

While we don't often have values over 64KB, it's possible. We didn't want to have to store profiles separate from their metadata.

Re: Migrating from MongoDB to Cassandra

#29

Post by dopamean »

brown9-2 wrote: post #26
DigitalSea wrote: post #3

When I read posts like this all but confirming MongoDB isn't the great product 10Gen make it out to be, I wonder how the heck MongoDB are still even relevant and then I remind myself of the fact that 10Gen have one of the best marketing and sales teams in the game at the moment. While MongoDB has improved greatly over previous versions, I can't help but feel if 10Gen put as much effort into improving their product as…

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?

Re: Migrating from MongoDB to Cassandra

#30

Post by iamaleksey »

chaostheory wrote: post #21
threeseed wrote: post #18

Earlier quoted context omitted.

For me anyone that uses the term "NoSQL" to group completely different databases simply doesn't understand what they are talking about. Cassandra and MongoDB are completely fine as general purpose databases. With CQL3 Cassandra is just as easy to use as any RDBMS with the advantage of being infinitely more scalable and easier to manage.

> Cassandra and MongoDB are completely fine as general purpose databases. Whenever I hear this, I feel that the person saying it either doesn't have enough experience or that every problem to them looks like a nail for their particular flavor of NoSQL. That's like saying a street bike is a general purpose bicycle. I'm sure someone out there can make it work on an outdoor offroad trail, but is it ideal? Cassandra is r…

> Cassandra is really awesome at writes but reads are really expensive

This is getting old, and is just plain untrue. Reads are more expensive than the extremely cheap writes, but they really aren't expensive.

> Atomicity at the row level only

Partition level, really, in modern terminology (apologies if that's what you meant).

Post reply on HN