incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filipe Gonçalves <the.wa.syndr...@gmail.com>
Subject Re: improving cassandra-vs-mongodb-vs-couchdb-vs-redis
Date Wed, 28 Dec 2011 12:37:01 GMT
There really is no generic way of comparing these systems, NoSQL
databases are highly heterogeneous.
The only credible and accurate way of doing a comparison is for a
specific, well defined, use case. Other than that you are always going
to be comparing apples to oranges thus having an crappy (and in that
one, even inaccurate) comparison to work with.
Some engineers (facebook, twitter and netflix among others if I'm not
mistaken) have done some interesting articles describing where and why
their companies use each database, google those for a minimally
accurate perspective of the NoSQL (and SQL in some cases) database
world.

2011/12/28 CharSyam <charsyam@gmail.com>:
> Don't trust NoSQL Benchmark. It's not a lie. but. NoSQL has different
> performance in many different environment.
>
> Do Benchmark with your real environment. and choose it.
>
> Thank you.
>
>
> 2011/12/28 Igor Lino <icampista@gmx.de>
>>
>> You are totally right. I'm far from being an expert on the subject, but
>> the comparison felt inconsistent and incomplete. (I could not express that
>> in my 1st email, not to bias the opinion)
>>
>> Do you know of any similar comparison, which is not biased towards some
>> particular technology or solution?   (so not coming from
>> http://cassandra.apache.org/)
>> I want to understand how superior is Cassandra in its latest release
>> against closer competitors, ideally with the opinion from expert guys.
>>
>>
>> On Wed, Dec 28, 2011 at 12:14 AM, Edward Capriolo <edlinuxguru@gmail.com>
>> wrote:
>>
>>    This is not really a comparison of anything because each NoSQL has its
>> own bullet points like:
>>    Boats
>>      great for traveling on water
>>    Cars
>>      great for traveling on land
>>    So the conclusion I should gather is?
>>    Also as for the Cassandra bullet points, they are really thin (and
>> wrong). Such as:
>>    Cassandra:
>>    Best used: When you write more than you read (logging). If every
>> component of the system must be in Java. ("No one gets fired for choosing
>> Apache's stuff.")
>>    I view that as:
>>    Nonsensical, inaccurate, and anecdotal.
>>    Also I notice on the other side (and not trying to pick on hbase, but)
>>    hbase:
>>    No single point of failure
>>    Random access performance is like MySQL
>>    Hbase has several SPOF's, its random access performance is definitely
>> NOT 'like mysql',
>>    Cassandra ACTUALLY has no SPOF but as they author mentions, he/she does
>> not like Cassandra so that fact was left out.
>>    From what I can see of the writeup, it is obviously inaccurate in
>> numerous places (without even reading the entire thing).
>>    Also when comparing these technologies very subtle differences in
>> design have profound in effects in operation and performance. Thus someone
>> trying to paper over 6 technologies and compare them with a few bullet
>> points is really doing the world an injustice.
>>    On Tue, Dec 27, 2011 at 5:01 PM, Igor Lino <icampista@gmx.de> wrote:
>>
>>        Hi!
>>
>>        I was trying to get an understanding of the real strengths of
>> Cassandra against other competitors. Its actually not that simple and
>> depends a lot on details on the actual requirements.
>>
>>        Reading the following comparison:
>>        http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
>>
>>        It felt like the description of Cassandra painted a limiting
>> picture of its capabilities. Is there any Cassandra expert that could
>> improve that summary? is there any important thing missing? or is there a
>> more fitting common use case for Cassandra than what Mr. Kovacs has given?
>>        (I believe/think that a Cassandra expert can improve that generic
>> description)
>>
>>        Thanks,
>>        Igor
>>
>>
>>
>



-- 
Filipe Gonçalves

Mime
View raw message