cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: Help for choice
Date Wed, 24 Feb 2010 11:06:54 GMT
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 <cemalettin.koc@gmail.com> 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 <nate@vervewireless.com>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
>>
>>

Mime
View raw message