incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From alex kamil <>
Subject Re: Help for choice
Date Wed, 24 Feb 2010 13:47:59 GMT

I've found the following analysis very helpful, it compares various noSQL
options and gives pros/cons of RDBMS vs noSQL:
"No Relation: The Mixed Blessings of Non-Relational Databases" by Ian Varley


On Wed, Feb 24, 2010 at 6:06 AM, Francois Orsini

> Chris's answer of MySQL does make a lot of sense, indeed. Based on the data
> you provided
> - 5-6 millions rows is not considered as a very large database.
> - 1,000 row updates per minute (even with 4 indexes) should not be a
> problem for sure. You can actually achieve 1.5-2k updates "per sec" easily
> with MySQL and 2+ indexes.
> - MySQL Master-Slave replication works quite well - sure you can get slaves
> behind but with 5.1 this is even less of a problem (replication is no longer
> single-threaded). In 5.0, you can compensate by using SSD drives on the
> slaves and using prefetch techniques (e.g. google for
> 'mk-slave-prefetch').
> - Be aware that you better have a good case for moving to Cassandra as you
> will be giving up on the declarative & expressive power of SQL.
>   . data model paradigm shift (think in terms of queries (NoSQL) rather
> than relations in the case of SQL)
>   . No free lunch in terms of multi-indexing, complex queries, etc.
>   . Eventual consistency vs strict consistency and the difference in
> performance cost in Cassandra. I suspect you understand this issue if you
> are dealing with slaves falling behind with MySQL ;-)
> - On the other hand, Cassandra is great for:
>   . Very intensive write(s) applications
>   . No single point of failure / automatic fail-over
>   . Load balancing
>   . Great read throughput - keep in mind that with a great set-up, you can
> achieve 10k reads / sec with MySQL.
>   . Horizontal scaling
> Disclaimer: I'm not MySQL biased and not in love with it either, we use
> both Cassandra and MySQL (as in NotOnlySQL) but there is a point where MySQL
> (and sharding) will be too darn challenging and difficult to maintain &
> evolve. The move comes with a price and some trade-offs but just be certain
> you really need to make that jump (or/and use both) based on requirements
> (in the short and long terms).
> On Wed, Feb 24, 2010 at 12:53 AM, Cemal <> wrote:
>> Hi,
>> Maybe I have to tell that we are very eager to evaluate NoSQL approaches
>> and for a simple case we want evaluate and compare each approaches.
>> In our case actually our data has not been denormalized yet and we are
>> suffering from a lot of joins. And because of very much updates in joined
>> tables we have a great performance problems in some situations. Another
>> difficulty we are dealing with is scaling problem. By now we have been using
>> master slaves model but in near future it seems that we will come across a
>> lot of problems.
>> By the way I tried to find an article about use cases, pros and cons of
>> each NoSQL solution but I could not find a detailed explanation about them.
>> Thanks
>> On Wed, Feb 24, 2010 at 10:15 AM, Nathan McCall <>wrote:
>>> The workload you originally described does not sound like a difficult
>>> job for a relational database. Do you have any more information on the
>>> specifics of your access patterns and where you feel that an RDBMS
>>> might fall short?
>>> -Nate

View raw message