Cassandra Performance
datastax.com
Cassandra Performance
1–10 of 76 posts
Re: Cassandra Performance
#2Not trying to take anything away from Cassandra (or any of the other products mentioned), but I would have liked to see the article focus on the actual data presented rather than a somewhat speculative discussion about 2 products that were not evaluated in the referenced study.
Unless I'm missing something.
Re: Cassandra Performance
#3Where's the MongoDB comparison? They mention it but don't see it in their graph
Re: Cassandra Performance
#4> A log-structured engine that avoids overwrites to turn updates into sequential i/o is essential both on hard disks (HDD) and solid-state disks (SSD). On HDD, because the seek penalty is so high; on SSD, to avoid write amplification and disk failure. This is why you see mongodb performance go through the floor as the dataset size exceeds RAM.
The structure of MongoDB's on-disk data has nothing to do with why its performance starts to falter when the dataset size exceeds RAM. It falters because each node mmap(2)s its dataset into MongoDB's process space and relies solely on the kernel's buffer caching algorithm to determine which pages to cache. The buffer cache is general-purpose, shared with every other process running on the node, and isn't finely tuned (or tuneable, for that matter) for database workloads, in which a basic LRU would be too naive. This is why MySQL, for example, doesn't mmap its tablespaces - instead, it's typically configured to manage its own buffer pool, and to avoid double buffering, O_DIRECT semantics are used for disk I/O.
Re: Cassandra Performance
#5I'm not sure what's the point comparing benchmarks this way.
Choosing a database is not only about performance, it's about the type of application you are building, the stage it's in (prototype product doesn't have the same need as a product that has grown over 5 years).
It's also about the people that works on the project. Some projects are better handled in a specific language (ruby/java/php,asp.net, etc.)
For example, using MongoDB on a ruby stack to build a prototype is a pretty good choice. Moving some loads off mongo to redis would be a solution later on. And eventually, the need would arise to migrate your mongoDB stack to Cassandra.
Re: Cassandra Performance
#6Has anybody found / done a benchmark that would compare the scalability of a Cassandra cluster vs an ElasticSearch cluster the latter used as a NoSQL database (with stored fields)?
I am interested with 2 kinds of scalability:
- volume scalability with single concurrent user: average read / write query times vs stored-data and indexes size vs number of EC2 nodes - concurrency scalability with a fixed size database: average read / write query times vs number of concurrent users vs number of EC2 nodes
Re: Cassandra Performance
#7Poor hypertable is never included in nosql benchmarks
Re: Cassandra Performance
#8I'm not sure what's the point comparing benchmarks this way. Choosing a database is not only about performance, it's about the type of application you are building, the stage it's in (prototype product doesn't have the same need as a product that has grown over 5 years). It's also about the people that works on the project. Some projects are better handled in a specific language (ruby/java/php,asp.net, etc.) For exam…
I'm not sure switching to a document model with multiple indexes (MongoDB) to a key/value store (Redis) is something that can be done easily "later on".
Re: Cassandra Performance
#9Cassandra is ugly, hardcore and performant as hell. It's not meant for the casual user, it's really meant to be there for you at scales where MongoDB craps its pants. If you wrap your head around ColumnFamilies, tunable consistency and NetworkTopologySnitch strategies, you get rewarded by a database that can scale on a global level to millions of I/O operations per second. We at Trademob have chosen Cassy as the backbone of our tracking platform and couldn't be happier. It's pretty serious stuff though and nothing for a quick prototype or the first few iterations of a product IMHO.
Re: Cassandra Performance
#10I'm not sure what's the point comparing benchmarks this way. Choosing a database is not only about performance, it's about the type of application you are building, the stage it's in (prototype product doesn't have the same need as a product that has grown over 5 years). It's also about the people that works on the project. Some projects are better handled in a specific language (ruby/java/php,asp.net, etc.) For exam…
I'm not sure switching to a document model with multiple indexes (MongoDB) to a key/value store (Redis) is something that can be done easily "later on".
Well structure evolves over time. Probably the structure would move and you would use redis as a memcache layer (to update counts, notifications, etc). What I'm saying is that databases needs evolves over time.
Comparing in-memory storage with SQL and NoSQL isn't a useful and misses the point.